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

[Janet P Gunn <[e-mail]>]

I agree

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.

[e-mail] wrote on 11/23/2009 02:44:21 PM:

> [image removed] 
> 
> Re: [sip-overload] Expert Review for Overload Control Drafts
> 
> Charles Shen 
> 
> to:
> 
> Janet P Gunn
> 
> 11/23/2009 02:44 PM
> 
> Sent by:
> 
> [e-mail]
> 
> Cc:
> 
> "DRAGE, Keith (Keith)", Henning Schulzrinne, Arata Koike, "sip-
> [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
> > >
> >