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

From: <[email-masked]>
Date: Tue, 15 Dec 2009 15:57:19 -0000

Hi Charles, All,

Here are some comments on the draft:

1) Section 1, para 1, typo "sever"

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.

4) Section 5.8 para 3. typo "previoulsy"

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?

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.

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?

Hope this helps

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

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 29 Dec 2009 17:24:57 -0500

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?

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.

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.

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
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload