Subject: Re: [sip-overload] Comments on draft-shen-sipping-load-control-event-package-03

From: Charles Shen <[email-masked]>
Date: Thu, 4 Feb 2010 15:32:50 -0500

Hi Geoff: thanks for the review, sorry for the late response. please
see inline.

> On Tue, Dec 15, 2009 at 10:57 AM,  <[email-masked]> wrote:
> Hi Charles, All,
>
> Here are some comments on the draft:
>
> 1) Section 1, para 1, typo "sever"

will correct

>
> 2) Section 4.1 Case 1 text " CPa1 then allocates the received total
> acceptable rate among its neighbors". Whilst CPa1 should not send more
> than the requested rate to EPa1, it is probably not sensible to
> "allocate" the total acceptable rate among its upstream neighbours,
> because this will (almost) guarantee it will send less than the
> requested rate to EPa1, because it is very likely that some sources will
> not offer the rate they are permitted to send. CPa1 might divide up some
> number larger than the total acceptable rate, to guarantee that it is
> able send the requested total acceptable rate to EPa1. Otherwise
> customer service will be worse than necessary (more calls than necessary
> will be rejected) and total network load will be exaggerated by
> unnecessary repeat attempt behaviour.
>
> 3) Section 5.7 para 2 text " then the total rate limit for the specific
> downstream SIP entity in the three NOTIFY messages sent to those three
> upstream neighbors must not exceed  100 requests per second." This is a
> similar comment to the comment above about section 4.1. It would be
> better to communicate permitted rates which *do* exceed 100 in total to
> upstream neighbours, and explicitly to limit downstream traffic to 100
> at the local server. Otherwise the network will almost certainly be
> under-utilised, which is damaging to customer service.

The point of possible under-utilization with the simplified example is
recognized. Since it is difficult to give any specific (right) value
of over-commitment either, and the value computation mechanism itself
is considered out-of-scope of the event package, the next update will
clarify this.

> 4) Section 5.8 para 3. typo "previoulsy"

will correct.

>
> 5) Section 6.3.1 para 2 last sentence, text "result is combined using
> logical OR". Just to clarify: does this interpretation allow joint
> control of traffic to a list of destinations (such as a televoting
> destination range) such that control does not have the effect of
> equalising traffic to the individual destinations?

Not sure whether I understand. Could you please elaborate a bit about
the scenario you are referring to?

>
> 6) Section 6.4 para 1, text " takes any one of the three sub-elements
> <rate>, <percent>, and <win>" It's very hard to see how either <percent>
> or <win> could make any sense for a statically-configured filtering type
> of control, given the uncertainty in offered traffic level and in
> downstream server responsiveness.
>

Indeed at this stage it may be the safest to use the <rate> sub-element.

> 7) Section 6.4 para 2, text "The default value is "Drop" .  " Will
> "drop" lead to retransmission by upstream elements, in networks using
> unreliable transport? If so this seems undesirable, by increasing load
> on the local device. Also 503 will allow upstream elements to re-try
> elsewhere which seems pointless or damaging in this type of control -
> would it be better to require sending 500?
>

This makes sense. (although sending rejection costs non-negligible
additional cycles too)

> Hope this helps

Yes, thanks!

Charles

>
> Geoff
>
> Geoff Hunt
> BT Design
>
> Tel: 01473 651704
> Email: [email-masked]
> Web: www.bt.com
> This email contains BT information, which may be privileged or
> confidential.
> It is meant only for the individual(s) or entity named above. If you are
> not the intended
> recipient, note that disclosing, copying, distributing or using this
> information
> is prohibited. If you have received this email in error, please let me
> know immediately
> on the email address above. Thank you.
> We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
>
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: Charles Shen <[email-masked]>
Date: Thu, 4 Feb 2010 15:44:06 -0500

On Tue, Dec 29, 2009 at 5:24 PM, Janet P Gunn <[email-masked]> wrote:
>
> I completely agree with point number two.  When you are invoking a control
> analogous to "cancel to- call gapping", there is absolutely no assurance
> that the sources of the load to the specific destination will be evenly
> distributed among the neighbors.  If you are going to propagate a "cancel
> to-call gapping"load control, the sensible thing would be to give EVERY
> neighbor the full permitted rate. (note that this is a problem with the
> example, and not necessarily with the underlying mechanism)
>
> In case II of section 4.1, I  sincerely doubt that CPb2, EPb3 and EPb4
> "configure themselves"  They will be manually configured under the guidance
> of the same people who have determined that "outgoing calls are more
> important than incoming calls". That is just semantics'.  But I am having
> difficulty following how (or why) this is propagated to other servers beyond
> the direct neighbors.  CPb1 and CPa2 can be instructed to reduce the rate at
> which they send calls to CPb2.   But how is CPa1 (or any of the EPax)  to
> know which calls it needs to suppress?
>

 "configure themselves" may not be a good wording, but the
configuration could be based on a result of an algorithm executed on
the node, or as you suggested, manual configuration. You might have a
tightly controlled intra-domain scenario where you can propagate the
computation upstream, or you might not. As responded to Geoff's
original message, the computation algorithm is orthogonal to the event
package itself, and will be clarified in the next update.

> To follow on the same theme. in section 4.2, I understand how you can limit
> SIP messages based on "callee number" (aka destination URI).  but I fail to
> see how a "wildcard domain based filter" can identify SIP messages destined
> for CPb2.
>

wildcard domain based filter assumes that a SIP proxy (e.g., a
corporate proxy) is responsible for a specific domain (e.g, the
corporate domain), and then you use the domain name without specifying
the exact username, to filter all calls to the domain.

> I also agree with comments 3 and 6.  There is a good reason why "percent
> blocking" has largely been replaced with "call gapping" (aka rate based)
> load controls in the circuit switched world, and the same logic applies
> here.

yes, rate-based would be the most appropriate comparing with the other options.

Thanks

Charles

>
> Janet
>
>
> [email-masked] wrote on 12/15/2009 10:57:19 AM:
>
>> <[email-masked]>
>> Sent by: [email-masked]
>>
>> 12/15/2009 10:57 AM
>>
>> To
>>
>> <[email-masked]>, <[email-masked]>
>>
>> cc
>>
>> Subject
>>
>> [sip-overload] Comments on
>> draft-shen-sipping-load-control-event-package-03
>>
>> Hi Charles, All,
>>

---

From: <[email-masked]>
Date: Fri, 5 Feb 2010 11:08:20 -0000

Hi Charles, All,

Responding to Charles' request for clarification of the scenario behind my comment about section 6.3.1 para 2 of the draft. 

In the UK, some television companies put on "talent competitions" raising money from large numbers of telephone calls made by the audience to premium rate lines, to register popular votes for the competitors. I believe you've had similar TV programmes in the US, such as "American Idol". In the UK, these competitions give rise to some of the largest calling rates seen on the UK telephone network, and on SIP networks which interconnect with it, although the voting period is typically quite short (maybe a few tens of minutes). So control of this type of event is a likely application of your package. In the UK, votes for different competitors are registered by dialling different telephone numbers, usually in a compact range such as a 10-number block. More generally the telephone numbers which are destinations for the vote could be a set, defined (for example) by a list. [I don't know whether similar TV programmes in the US register votes in the same way.]

The surge of calls to voting numbers typically must be controlled, but application of *multiple* rate-based controls (for example with equal rates) to *individual* numbers within the voting range (one control per destination number) would tend to set the per-number rates of calls received at the vote-recording equipment to the controlled rates. This would clearly be unacceptable because the ratios of popular votes for each competitor are important for the TV programme's application. So a control at a network node, if applied, should be a *single* control which treats calls to the set of voting destination numbers *jointly*, such that the probability of rejecting a call at the control is independent of the call's destination number within the controlled set of numbers - thus voting ratios are preserved in the stream of calls admitted by the control.

In other circumstances the *intention* might instead be to apply multiple rate-based controls, one to each destination in a list.

My comment was intended to ask whether your syntactical scheme meets both these requirements

(a) a requirement to apply a single joint control to traffic towards a set of destination numbers, expressed either as a list of numbers or a list of "user@host" addresses, or as a leading substring of a telephone number (for example, lists in 10-number blocks)

and

(b) a requirement to apply several individual controls, each controlling traffic towards one member of a set of numbers, expressed either as a list of numbers or a list of "user@host" addresses, or (possibly less likely in this case) as a leading substring of a telephone number (for example, lists in 10-number blocks). [Of course it would be acceptable to meet this requirement with multiple <call-identity> elements]

Best regards
Geoff

Geoff Hunt
BT Design

Tel: 01473 651704
Email: [email-masked]
Web: www.bt.com 
This email contains BT information, which may be privileged or confidential.
It is meant only for the individual(s) or entity named above. If you are not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you have received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Charles Shen
>Sent: 04 February 2010 20:33
>To: Hunt,RG,Geoff,DLW R
>Cc: [email-masked]; Henning Schulzrinne
>Subject: Re: [sip-overload] Comments on draft-shen-sipping-load-control-
>event-package-03
>

---

From: Charles Shen <[email-masked]>
Date: Tue, 9 Feb 2010 21:37:25 -0500

Hi Geoff, thanks for the detailed and interesting description. Please see inline

> (a) a requirement to apply a single joint control to traffic towards a set of destination numbers, expressed either as a list of numbers or a list of "user@host" addresses, or as a leading substrin…

I think this is achieved by using a single <call-identity> and <to>
element, with multiple <one>  sub-elements containing the individual
destination numbers or "user@host" addresses, or with a <many>
sub-element containing the leading string (prefix) of a telephone
number. Since the individual destinations are interpreted as logical
"OR", the associated <action> will be applied to the whole pool of the
numbers in the <call-identity> element, and I think that satisfies
this requirement (a).

> (b) a requirement to apply several individual controls, each controlling traffic towards one member of a set of numbers, expressed either as a list of numbers or a list of "user@host" addresses, or…

Yes, as you mentioned, the simplest method to satisfy requirement (b)
is to use multiple <call-identity>  elements, each associated with its
action (which may or may not be the same for all the numbers in the
<call-identity> element)

Thanks

Charles