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

[Charles Shen <[e-mail]>]

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

On Fri, Feb 5, 2010 at 6:08 AM,  <[e-mail]> wrote:
> 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)
>

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


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

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

>
> Best regards
> Geoff
>
> Geoff Hunt
> BT Design
>
> Tel: [phone]
> Email: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On
>>Behalf Of Charles Shen
>>Sent: 04 February 2010 20:33
>>To: Hunt,RG,Geoff,DLW R
>>Cc: [e-mail]; Henning Schulzrinne
>>Subject: Re: [sip-overload] Comments on draft-shen-sipping-load-control-
>>event-package-03
>>
>>Hi Geoff: thanks for the review, sorry for the late response. please
>>see inline.
>>
>>> On Tue, Dec 15, 2009 at 10:57 AM,  <[e-mail]> 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: [phone]
>>> Email: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sip-overload
>>>
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload
>