Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package

From: <[email-masked]>
Date: Wed, 1 Aug 2012 14:56:33 +0000

Hi Charles,

"Route" may be a bit misleading as the matching should be performed on the identity or address obtained after applying RFC3263 procedures to the first value of the route header or to the R-URI rather than on the contents the route header as such.

BC

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Charles Shen
> Envoyé : lundi 30 juillet 2012 05:07
> À : CHATRAS Bruno RD-CORE
> Cc : Salvatore Loreto; [email-masked]; Volker Hilt; Henning
> Schulzrinne; Arata Koike
> Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-
> package
> 
> Hi Bruno, sorry for the delayed response!
> 
> I've updated the local number grouping text. For the multi-path
> filtering policy problem, since it will affect texts in multiple
> sections, I'd like to discuss a bit more in terms of the solution.
> 
> Assuming the following scenario,
> 
>                                      P3A
> alice@p1 --- P1 --- P2 -- /       \ --- P4 --- bob@p4
>                                     \      /
>                                      P3B
> 
> where P2 can reach bob through either P3A or P3B, the call identity in
> the existing policy does not distinguish the calls to bob@p4 through
> P3A from those through P3B. Therefore it would be good for the load
> control
> policy to include not only the call destination (e.g., bob@p4 in
> this case), but also through which path the call is routed.
> 
> One possible solution could be to add a new sub-element called
> <route> under the existing <call-identity> schema. In the simple case,
> the new <route> element can be of the same type as the <identity>
> element in [RFC4745]. The contents of the <route> element holds what
> you call target SIP entities.
> 
> Using the same example above, server P1 may receive a policy
> containing the new element as below:
> 
> <call-identity>
>     <sip>
>         <to>
>             <one id="sip:[email-masked]">
>         </to>
>         <route>
>             <many domain="p2.example.com">
>             <many domain="p3a.example.com">
>             <many domain="p4.example.com">
>         </route>
>     </sip>
> </call-identity>
> 
> 
> Similarly server P2 may receive a policy containing the new element as
> below:
> 
> <call-identity>
>     <sip>
>         <to>
>             <one id="sip:[email-masked]">
>         </to>
>         <route>
>             <many domain="p3a.example.com">
>             <many domain="p4.example.com">
>         </route>
>     </sip>
> </call-identity>
> 
> 
> Then the call filtering can match both the call destination and the
> path (assuming either a SIP Route header is included, or a next hop
> SIP server is chosen dynamically).
> 
> There is still a small problem though - if the new <route> element is
> defined as one of <identity> element in RFC4745, then the <many>
> sub-elements under it are not ordered, while here we seem to need an
> ordered list (as in the list of SIP Route headers). Therefore, we
> might have to define new rules for the <route> element to make its
> sub-elements ordered.
> 
> Any thoughts?
> 
> Charles
> 
> 
> 
> 
> 
> On Tue, Jul 17, 2012 at 1:07 PM,  <[email-masked]> wrote:
> > Hi Charles,
> >
> > See below.
> >
> >> -----Message d'origine-----
> >> De : [email-masked] [mailto:[email-masked]] De
> la
> >> part de Charles Shen
> >> Envoyé : mardi 17 juillet 2012 18:37
> >> À : CHATRAS Bruno RD-CORE
> >> Cc : Salvatore Loreto; [email-masked]; Volker Hilt; Henning
> >> Schulzrinne; Arata Koike
> >> Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-
> >> package
> >>
> >> Hi Bruno, thank you so much for the detailed review and comments!
> I've
> >> addressed 8 out of the total 10, except the following two which I'd
> >> appreciate more clarification.
> >>
> >> > 2) Section 5.8, line 525-528
> >> >
> >> > The current text suggests that incoming requests are filtered
> >> irrespective of their actual destination. The subscriber should
> rather
> >> apply filters on requests that are outgoing to the pre-overloaded
> >> destination. One solution would be to rephrase the following text:
> >> >
> >> > "A subscriber receiving the notification first installs these rules
> >> and then filter incoming requests to enforce actions on appropriate
> >> requests, for example, limiting the sending rate of call requests
> >> destined for a specific SIP entity."
> >> >
> >> > With
> >> >
> >> > "A subscriber receiving the notification first installs these rules
> >> and then filter outgoing requests towards the notifier to enforce
> >> actions on appropriate requests, for example, limiting the sending
> rate
> >> of call requests destined for a specific SIP entity."
> >> >
> >> > This would however not permit the use of external state agents as
> >> described in section 5.12. Therefore it seems that a "target sip
> entity"
> >> parameter should be added to overload control documents.
> >> >
> >>
> >> I think I might have not understood your point. The requests are
> >> filtered based on the call identities, which can convey information
> >> including the call destination. Could you elaborate what this "target
> >> sip entity" is exactly for?
> > [BC]
> >
> > Let's take two examples that I think are not covered by the current
> wording.
> >
> > 1) Example 1
> >
> > Call configuration: A is connected so SP1, B is connected to SP2. SP1
> and SP2 are connected via SP3. SP3 is connected to an Application Server
> (AS). Under normal load conditions, a call from A to B is routed along
> the following path: A-SP1-SP3-AS-SP2-B. The AS provides a non-essential
> service and can be bypassed in case of overload.
> >
> > Now let's assume that AS is overloaded and sends to SP3 a filter
> requesting that 50% of INVITE messages be dropped, regardless of the
> contents of the from/to/PAI/R-URI.
> >
> > According to the current wording, SP3 will indeed filter 50% of the
> INVITE requests while they could be routed to B via SP2.
> >
> > 2) Example 2
> >
> > Call Configuration: An 800 translation service is installed on two
> Application Servers AS-1 and AS-2. A is connected to SP1 and calls 800
> 1234 4529, which is translated by AS-1 and AS-2 into a regular E164
> number, depending on e.g. the caller's location. SP1 forwards INVITE
> requests with R-URI = "800 number" to AS-1 or AS-2 based on a load
> balancing strategy.
> >
> > As calls to 800 1234 4529 creates a pre-overload condition in AS-1,
> AS-1 sends to SP-1 a filter requesting that 50% of calls towards 800
> 1234 4529 be rejected.
> >
> > According to the current wording, SP3 will apply the filter on
> incoming INVITE requests, irrespective of whether they are intended to
> be sent to AS1 or AS2.
> >
> > ==> It seems that these use cases could be solved by applying the
> filters to outgoing requests (not incoming requests) that are to be
> routed to the AS that sent these filters. This means that the SP has to
> store the AS address together with the received filters or this address
> has to be included explicitly as a new filter criteria.
> >
> >>
> >>
> >> > 5) Section 6.3.1, local number grouping:
> >> >
> >> > The proposed solution for local numbers is not suitable. For
> example,
> >> if the phone-context for short service numbers in a country is the
> >> country code, the solution does not permit to define a filter that
> >> excludes all E.164 numbers in that country but retain all short
> service
> >> numbers. I think we should either define another solution or state
> that
> >> grouping of local numbers is not supported or state that grouping of
> >> local numbers only works under specific assumptions on the use of
> phone-
> >> context values.
> >> >
> >>
> >> How about adding the following text?
> >>
> >> It should be noted that the method of grouping local numbers as
> >> defined in this document does not support all cases. For example, if
> >> the phone-context for short service numbers in a country is the
> >> country code, this solution does not permit to define a filter that
> >> excludes all E.164 numbers in that country but retain all short
> >> service numbers. A complete solution for local number grouping
> >> requires a separate method outside the scope of this document.
> > [BC]
> >
> > Looks OK for me.
> >
> >
> >>
> >>
> >> Thanks!
> >>
> >> Charles
> >>
> >>
> >> On Wed, Jul 11, 2012 at 3:33 AM,  <[email-masked]> wrote:
> >> > Hi!
> >> >
> >> > Here are my comments about this I-D.
> >> >
> >> > 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph 5
> >> (i.e. after line 360) and modifies the first two sentences as follows:
> >> >
> >> > "In the above case, the network entity where load filtering policy
> is
> >> first introduced is the SIP server providing access to the resource
> that
> >> creates the overload condition. In other cases, the network entry
> point
> >> of load filtering policy could also be an entity that hosts this
> >> resource. "
> >> >
> >> > 2) Section 5.8, line 525-528
> >> >
> >> > The current text suggests that incoming requests are filtered
> >> irrespective of their actual destination. The subscriber should
> rather
> >> apply filters on requests that are outgoing to the pre-overloaded
> >> destination. One solution would be to rephrase the following text:
> >> >
> >> > "A subscriber receiving the notification first installs these rules
> >> and then filter incoming requests to enforce actions on appropriate
> >> requests, for example, limiting the sending rate of call requests
> >> destined for a specific SIP entity."
> >> >
> >> > With
> >> >
> >> > "A subscriber receiving the notification first installs these rules
> >> and then filter outgoing requests towards the notifier to enforce
> >> actions on appropriate requests, for example, limiting the sending
> rate
> >> of call requests destined for a specific SIP entity."
> >> >
> >> > This would however not permit the use of external state agents as
> >> described in section 5.12. Therefore it seems that a "target sip
> entity"
> >> parameter should be added to overload control documents.
> >> >
> >> > 3) Section 5.8, add the following text (adapted from draft-ietf-
> soc-
> >> overload-control) after line 537:
> >> >
> >> > "When enforcing actions on requests matching the filters,
> subscribers
> >> SHOULD honor the local policy for prioritizing SIP requests such as
> >> policies based on the content of the Resource-Priority header (RPH,
> >> RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> >> indicate high priority requests that should be  preserved as much as
> >> possible during overload.  The RPH contents can also indicate a low-
> >> priority request that is eligible to be dropped during times of
> overload.
> >> Other indicators, such as the SOS URN [RFC5031] indicating an
> emergency
> >> request, may also be used for prioritization."
> >> >
> >> > 4) Section 6.3.1, matching identities: After line 699, add the
> >> following text:
> >> >
> >> > "Before evaluating call-identity conditions, the subscriber shall
> >> convert URIs received in SIP header fields in canonical form as per
> RFC
> >> 3261, except that the phone-context parameter shall not be removed,
> if
> >> present."
> >> >
> >> > 5) Section 6.3.1, local number grouping:
> >> >
> >> > The proposed solution for local numbers is not suitable. For
> example,
> >> if the phone-context for short service numbers in a country is the
> >> country code, the solution does not permit to define a filter that
> >> excludes all E.164 numbers in that country but retain all short
> service
> >> numbers. I think we should either define another solution or state
> that
> >> grouping of local numbers is not supported or state that grouping of
> >> local numbers only works under specific assumptions on the use of
> phone-
> >> context values.
> >> >
> >> > 6) Section 6.3.1, line 746 - 753, remove the last but one sentence
> and
> >> reword the rest of the text accordingly. Reason: The use of local
> number
> >> 'tel' URI in the R-URI and To header field is not rare. In several
> >> countries, short numbers are used quite extensively to access special
> >> services.
> >> >
> >> > "Second, use of the local number 'tel' URI in practice is expected
> to
> >> be rare."
> >> >
> >> > 7) Clause 6.3.3, after line 800, add:
> >> >
> >> > "SUBSCRIBE requests are not filtered if the event-type header field
> >> indicates the event package defined in this document."
> >> >
> >> > 8) Section 7, line 985 - 990: replace "call type" with "call
> identity
> >> type" (3 times)
> >> >
> >> > 9) Section 8.1
> >> >
> >> > Line 1048, add "except in specific cases when the Intelligent
> Network
> >> architecture is used [AINGR].
> >> >
> >> > Line 1060, remove the last part of the first sentence starting with
> >> "and the number of prefix to be matched.": ITU IN specifications
> allow
> >> for dynamic sets.
> >> >
> >> > Line 1068, remove the last part of the first sentence staring with
> >> "with a fixed set.": Reason: ITU IN specifications allow for dynamic
> >> sets.
> >> >
> >> > 10)          Miscellaneous points
> >> > Section 1, line 106, replace RFC3265 with RFC3261
> >> > Section 4.1, line 231, replace "proxy" with "node" (this text
> should
> >> apply to any type of SIP entity)
> >> > Section 4.3, line 265, replace "proxy" with "node" (this text
> should
> >> apply to any type of SIP entity)
> >> > Section 4.3, Line 341, replace "singling" with "signaling"
> >> > Section 4.3, Line 342, replace "all signaling relationship in
> Figure 1
> >> is" with "all signaling relationships in Figure 1 are"
> >> > Section 5.6, Line 503, add "request" after "SUBSCRIBE"
> >> > Section 5.11, Line 585, remove "is"
> >> > Section 6.5, Line 851, replace "vliad" with "valid"
> >> >
> >> > Bruno
> >> >
> >> >
> >> >> -----Message d'origine-----
> >> >> De : [email-masked] [mailto:sip-overload-
> >> [email-masked]]
> >> >> De la part de Salvatore Loreto
> >> >> Envoyé : lundi 2 juillet 2012 21:09
> >> >> À : [email-masked]
> >> >> Cc : Volker Hilt
> >> >> Objet : [sip-overload] WGLC: draft-ietf-soc-oload-control-event-
> >> package
> >> >>
> >> >> [as chair]
> >> >>
> >> >> based on the mailing list discussion and the one we had during the
> >> last
> >> >> SoC f2f meeting in Paris,
> >> >> the chairs think the draft-ietf-soc-oload-control-event-package is
> >> ready
> >> >> for the WGLC.
> >> >>
> >> >> Today we are starting a two-week working group last call.
> >> >> This call ends on Wednesday, July 16th.
> >> >>
> >> >> the last version of the document can be retrieved here:
> >> >> http://tools.ietf.org/html/draft-ietf-soc-load-control-event-
> package-
> >> 03
> >> >>
> >> >>
> >> >> reviews and comments are really appreciate and requested from all
> the
> >> >> participants
> >> >>
> >> >>
> >> >> cheers
> >> >> /Sal
> >> >>
> >> >> --
> >> >> Salvatore Loreto, PhD
> >> >> www.sloreto.com
> >> >>
> >> >> _______________________________________________
> >> >> sip-overload mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/sip-overload
> >> >
> >> >
> >>
> ________________________________________________________________________
> >> _________________________________________________
> >> >
> >> > Ce message et ses pieces jointes peuvent contenir des informations
> >> confidentielles ou privilegiees et ne doivent donc
> >> > pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez
> >> recu ce message par erreur, veuillez le signaler
> >> > a l'expediteur et le detruire ainsi que les pieces jointes. Les
> >> messages electroniques etant susceptibles d'alteration,
> >> > France Telecom - Orange decline toute responsabilite si ce message
> a
> >> ete altere, deforme ou falsifie. Merci.
> >> >
> >> > This message and its attachments may contain confidential or
> >> privileged information that may be protected by law;
> >> > they should not be distributed, used or copied without
> authorisation.
> >> > If you have received this email in error, please notify the sender
> and
> >> delete this message and its attachments.
> >> > As emails may be altered, France Telecom - Orange is not liable for
> >> messages that have been modified, changed or falsified.
> >> > Thank you.
> >> >
> >> > _______________________________________________
> >> > sip-overload mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/sip-overload
> >
> >
> ________________________________________________________________________
> _________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> > France Telecom - Orange decline toute responsabilite si ce message a
> ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> > Thank you.
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.