Subject: [Sipping] Re: Comments for draft-ietf-sipping-overload-reqs-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2007 00:54:42 -0500

Thanks for the comments and apologies for the profoundly tardy reply. 
Responses below:

Asveren, Tolga wrote:
> After going over draft-sipping-overload-reqs-00.txt, I have the
> following comments:
> 
> 1) I think 503 could be used a little bit more efficiently than
> explained in 4.1 Load Amplification. One doesn't need to wait till the
> node is completely congested to generate a 503 response. This would
> enable the node to generate 503 in a relatively timely manner to
> minimize retransmissions. Depending on the criteria to detect local
> congestion, e.g. applying a queuing discipline etc.., one could also
> decide whether congestion is to happen soon. Obviously, all such
> decisions will be more an educated guess because there is no prior
> knowledge about incoming traffic volume in the future (except
> statistical data maybe) but I would think, any receiver driven
> congestion avoidance mechanism is likely to rely on such a mechanism
> (for example a mechanism using an event package).

This doesn't change this problem; it just causes you to start the 
process of sending the 503s a bit earlier, before congestion gets bad. 
But if the input load still exceeds the server capacity of S1..S3, you 
will end up with this problem.

> 
> 2) The problem explained with Figure3 seems actually be related with the
> fact that the existing 503 response mechanism does allow to signal
> congestion only for the local node, i.e. it doesn't help much to provide
> congestion information about the destinations, for which relaying is
> provided. It could be an idea to point this out explicitly. I don't know
> whether this is a capability we are looking for, but if so, this may be
> added to the requirements list.

There was discussion earlier on about whether we wanted a hop-by-hop 
mechanism or something that could signal a load from an element to 
neighbors several hops upstream. There was general agreement not to 
pursue such a mutli-hop mechanism since its really complicated. That 
said, your point is right that one of the reasons for the problem is 
that there isn't targeted load information. I will point that out.

> 
> 3) It may be clearer to rename 4.2 to something reflecting that there is
> a problem with scope of 503 not being clear (Will there be some effort
> to clarify this for 503?) 

Well, the PROBLEM is still underutilization. The cause is the scope 
being unclear. These sections titles each describe the problem.

> 
> 4) For the sake of completeness, mentioning about relying on TCP/SCTP
> receiver window size (and about its shortcomings/drawbacks) could be
> useful. (I know this is not a SIP mechanism per se, but is still another
> way of getting some idea about a peer's congestion status).

Sure - its a solution possibility. But the point of the draft is to 
point out the deficiencies in the SIP specification, not to describe the 
pros/cons of potential solutions.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP