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

From: Janet P Gunn <[email-masked]>
Date: Thu, 12 Nov 2009 18:54:45 -0500

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) 

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.

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".

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.

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.

Thanks

Janet

[email-masked] wrote on 10/27/2009 10:36:14 AM:

> [image removed] 
> 
> [sip-overload] Expert Review for Overload Control Drafts
> 
> Volker Hilt 
> 
> to:
> 
> [email-masked]
> 
> 10/27/2009 10:36 AM
> 
> Sent by:
> 
> [email-masked]
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Charles Shen <[email-masked]>
Date: Mon, 23 Nov 2009 09:50:04 -0500

Hi Janet, thanks for your review. please see comments inline:

>  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.

> next/previous SIP proxy or SIP server, rather than some representation of

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
>
> 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.

> particular RPH values form these load controls, as required by  Req 13 of

Maybe we can add something like the RPH mechanism takes precedence
over this filtering in the next revision.

Thanks

Charles

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Nov 2009 18:40:22 +0100

You said:

> > 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Shen
> Sent: Monday, November 23, 2009 2:50 PM
> To: Janet P Gunn
> Cc: [email-masked]; Arata Koike; Henning Schulzrinne
> Subject: Re: [sip-overload] Expert Review for Overload Control Drafts
> 
> > First, the approach seems to depend on landline   
> "telephone numbers" 
> > and "Tel URIs".
> >
> 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.
> 
> >
> >  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.
> 
> >
> > 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
> > 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.
> 
> >
> > 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
> >
> >> 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 
> >> We had many people expressing interest in contributing to a SIP 
> >> overload control solution. This is a great chance to do so!
> >>
> >> Thanks,
> >>
> >> Volker
> >>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 23 Nov 2009 13:40:21 -0500

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)" <[email-masked]>
To:
Charles Shen <[email-masked]>, Janet P Gunn/USA/CSC@CSC
Cc:
"[email-masked]" <[email-masked]>, Arata Koike 
<[email-masked]>, Henning Schulzrinne <[email-masked]>
Date:
11/23/2009 12:43 PM
Subject:
RE: [sip-overload] Expert Review for Overload Control Drafts

> 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

---

From: Charles Shen <[email-masked]>
Date: Mon, 23 Nov 2009 14:44:21 -0500

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 <[email-masked]> 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)" <[email-masked]>
> To: Charles Shen <[email-masked]>, Janet P Gunn/USA/CSC@CSC
> Cc: "[email-masked]" <[email-masked]>, Arata Koike <[email-masked]>, Henning Schulzrinne <[email-masked]>
> Date: 11/23/2009 12:43 PM
> Subject: RE: [sip-overload] Expert Review for Overload Control Drafts
> ________________________________
>
>
> You said:
>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 23 Nov 2009 14:56:48 -0500

I agree

[email-masked] 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:
> 
> [email-masked]
> 
> Cc:
> 
> "DRAGE, Keith (Keith)", Henning Schulzrinne, Arata Koike, "sip-
> [email-masked]"
> 
> > 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.
> >
> 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.
> >
> >
> > Cc: "[email-masked]" <[email-masked]>, Arata Koike 
> > 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
> >
> > > > 1- It seems that load control should apply to ALL SIP sessions, 
not
> > > > just