Re: [sip-overload] Expert Review for Overload Control Drafts

[Charles Shen <[e-mail]>]

I agree too that appropriate treatment of the RPH (not simply an
exclusive exemption) needs to be defined. But I am not sure whether
the detailing of such treatment is in the scope of the event package
document. We might want a somewhat unified RPH treatment to be
applicable to the general overload handling scenarios, regardless of
how the overload information is conveyed.

Note that the related draft, draft-hilt-sipping-overload-07 currently
has the following description.

****
4.1.  Message Prioritization

   During an overload condition, a SIP server needs to prioritize
   messages and select messages that need to be rejected or redirected.
   The selection is largely a matter of local policy.

   A SIP server SHOULD honor the Resource-Priority header field as
   defined in RFC4412 [RFC4412] if it is present in a SIP request.  The
   Resource-Priority header field enables a proxy to identify high-
   priority requests, such as emergency service requests, and preserve
   them as much as possible during times of overload.
****





Thanks

Charles



On Mon, Nov 23, 2009 at 1:40 PM, Janet P Gunn <[e-mail]> wrote:
>
> I agree,
>
> We don't need a blanket "exemption for anything with RPH".  We need the ability (using configuration) to exempt SIP messages with particular RPH values from particular aspects of the network controls.
>
> To go back to the SS7 world, we do NOT want GETS calls (equivalent to RPH namespaces ets and wps) to be exempt from "100% cancel-to" (which typically is associated with equipment failure), but we DO (in general) want them exempt from "x% cancel-to" for X not equal 100.
>
> There may very well also  be cases where you want a network control to apply specifically to a particular RPH namespace, as in the RPH for 911-type emergency calls.
>
> What we need is for the overload mechanism to have the ability to distinguish, and give different treatment to, messages with specific RPH values.
>
> Janet
>
> This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
>
>
> From: "DRAGE, Keith (Keith)" <[e-mail]>
> To: Charles Shen <[e-mail]>, Janet P Gunn/USA/CSC@CSC
> Cc: "[e-mail]" <[e-mail]>, Arata Koike <[e-mail]>, Henning Schulzrinne <[e-mail]>
> Date: 11/23/2009 12:43 PM
> Subject: RE: [sip-overload] Expert Review for Overload Control Drafts
> ________________________________
>
>
> You said:
>
> > > Finally, your approach make no mention of exempting SIP
> > requests with
> > > particular RPH values form these load controls, as required
> > by  Req 13
> > > of
> > >  RFC 5390.
> >
> > Maybe we can add something like the RPH mechanism takes
> > precedence over this filtering in the next revision.
> >
>
> I not sure it is entirely a matter of exempting, or precedence invalidating the filtering.
>
> Surely if for example if I have an RPH for emergency calls (proposed), it is possible to locally overload the network with just emergency calls, and therefore we need the overload mechanism to operate in some manner.
>
> Further calls with RPH do not necessarily remove the ability for other calls to be made entirely, merely guarantee that a certain percentage of the traffic is reserved for priority calls (for example).
>
> What we surely need is for the overload algorithms to apply, but to take into account the RPH in performing their activity.
>
> regards
>
> Keith
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Charles Shen
> > Sent: Monday, November 23, 2009 2:50 PM
> > To: Janet P Gunn
> > Cc: [e-mail]; Arata Koike; Henning Schulzrinne
> > Subject: Re: [sip-overload] Expert Review for Overload Control Drafts
> >
> > Hi Janet, thanks for your review. please see comments inline:
> >
> > On Thu, Nov 12, 2009 at 6:54 PM, Janet P Gunn <[e-mail]> wrote:
> > >
> > >
> > > With regard to
> > > A Session Initiation Protocol (SIP) Load Control Event Package
> > > draft-shen-sipping-load-control-event-package-03.txt
> > > I have concerns about a number of the basic premises.
> > >
> > > First, the approach seems to depend on landline
> > "telephone numbers"
> > > and "Tel URIs".
> > >
> > > 1- It seems that load control should apply to ALL SIP sessions, not
> > > just
> > >  voice calls with an associated phone  number (or even a Tel URI)
> >
> > It is a clear goal of this draft *not* to limit on "telephone
> > numbers", but to support SIP URIs, *including* Tel URIs that
> > could be associated to phone numbers. Therefore, as the
> > document suggests, the call identity to be filtered is based
> > on the SIP <from>, <to> header etc., and the examples in the
> > document also include SIP URIs and domain names. Please let
> > me know if you have suggestions to clarify it further.
> >
> > >
> > > 2-It is no longer reasonable to assume a mapping between
> > "telephone number"
> > > and "location" or a particular SIP  proxy.  A mobile phone could be
> > > anywhere- the number is not at all related to which SIP
> > proxy it is  using.
> > >  And even number portability for landline phones makes it a less
> > > useful mapping.
> >
> > Here the typical overload destination would more likely be a
> > call center than a mobile phone. I don't know how exactly
> > number portability would matter, as long as they are
> > forwarded to the correct proxy ... correct me if I were wrong.
> >
> > >
> > > 3- It might be more practical to invoke the load controls
> > based on the
> > > next/previous SIP proxy or SIP server, rather than some
> > representation
> > > of the "phone number".
> > >
> >
> > comments as in 1.
> >
> > > Second, the approach propagates the load controls from one
> > SIP Proxy
> > > to the adjacent ones.  The first example given  is an
> > "acceptable call
> > > rate"  to a TV program "hotline".  The SIP proxy then
> > "allocates" the
> > > acceptable call rate  among its neighbors. I think that propagating
> > > the load controls across multiple proxies is likely to create more
> > > problems than it solves
> > >
> > > 1- It is highly unlikely that the actual call rate is uniformly, or
> > > even predictably, distributed among the  neighbors.  This
> > means that
> > > it is highly likely that some of the neighbors will have a
> > bigger call
> > > rate to the TV
> > >  hot line, meaning they will block calls, while others will
> > have lower
> > > volume, and will not need to block calls.  The  call rate at the TV
> > > hotline will then be below the "acceptable call rate", and
> > there will
> > > be many calls that were unnecessarily blocked.  This concern also
> > > applies to the second example given.
> >
> > The example shows how the event package, with appropriate
> > input values, could be used. The input values to the event
> > package are outputs of a specific overload algorithm, which
> > may be distributed or centralized, or hybrid. As mentioned,
> > the overload algorithm itself is out of scope of this event
> > package document. But if the algorithm produces a dynamic
> > rate output, there is no reason why the rate distribution by
> > the event package could not be dynamic. I can clarify this in
> > the next revision.
> >
> > >
> > > Finally, your approach make no mention of exempting SIP
> > requests with
> > > particular RPH values form these load controls, as required
> > by  Req 13
> > > of
> > >  RFC 5390.
> >
> > Maybe we can add something like the RPH mechanism takes
> > precedence over this filtering in the next revision.
> >
> > Thanks
> >
> > Charles
> >
> >
> > >
> > > Thanks
> > >
> > > Janet
> > >
> > > [e-mail] wrote on 10/27/2009 10:36:14 AM:
> > >
> > >> [image removed]
> > >>
> > >> [sip-overload] Expert Review for Overload Control Drafts
> > >>
> > >> Volker Hilt
> > >>
> > >> to:
> > >>
> > >> [e-mail]
> > >>
> > >> 10/27/2009 10:36 AM
> > >>
> > >> Sent by:
> > >>
> > >> [e-mail]
> > >>
> > >> All,
> > >>
> > >> We are looking for experts who can do a review for the
> > following two
> > >> drafts:
> > >>
> > >>
> > >
> > http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-07.txt
> > >>
> > >> http://tools.ietf.org/html/draft-shen-sipping-load-control-event-
> > >> package-03.txt
> > >>
> > >> Please send me a quick note if you are interested and
> > available to do
> > >> a review for one of these drafts (or both of them). Please
> > post the
> > >> review on this mailing list.
> > >>
> > >> We had many people expressing interest in contributing to a SIP
> > >> overload control solution. This is a great chance to do so!
> > >>
> > >> Thanks,
> > >>
> > >> Volker
> > >>
> > >> _______________________________________________
> > >> sip-overload mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/sip-overload
> > >
> > > _______________________________________________
> > > sip-overload mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sip-overload
> > >
> > >
> > _______________________________________________
> > sip-overload mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sip-overload
> >
>