Draft:  draft-ietf-sipping-overload-reqs-00.txt
Reviewer: Asveren, Tolga [tasveren@sonusnet.com]
Review Date: 5/6/2007
Review Deadline: 5/21/2007
Status: WGLC 

Summary: This draft is on the right track but has open issues, described in the review. 


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

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.

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

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