Draft: draft-ietf-sipping-overload-reqs-00
Reviewer: Volker Hilt
Review Date: May 21, 2007
Review Deadline: May 21, 2007
Status: WGLC

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.

Detailed comments:

* Section 2, sentence: "It can also include external resources, such as 
a database or DNS server"
I think it would be better to remove this sentence. Overload should only 
occur if a server is unable to process all messages it receives. Not 
being able to fulfill messages (e.g. because a server has lost its 
connection to the location database) does not put a proxy in overload 
since the proxy can still reject messages.

* Section 2, dependency failures:
Similar to above. It should be stated that dependency failures only lead 
to overload if they degrade the message processing capacity of a server 
(e.g. because the server has lots of processes waiting for a response 
from DNS).

* REQ 2:
Same as above. Remove sentence in brackets or replace database example 
with e.g. a hard disk failure.

* REQ 8:
Last part of sentence "... sent to another element suffering from 
greater levels of load." should be replace with "... sent to another 
element that is also under overload."
I think the purpose of this requirement is to prevent a proxy from 
sending a message that has been rejected due to overload to another 
overloaded proxy. It is irrelevant whether the other proxy is more or 
less overloaded than the one that has rejected the message.

* REQ 9:
Last part of sentence "... an element that is less overloaded." should 
be replaced with "... an element that is not in overload state."
Same reason as above.

* REQ 10 and 11:
The two scenarios described in 10 and 11 have quite different 
characteristics and may require different mechanisms. Not sure if this 
needs to be reflected in the requirements. However, a mechanism should 
be acceptable if it satisfies only one of the two requirements (assuming 
there is another mechanism that covers the other case).

* Section 6:
This section should be changed to reflect the model adopted by the 
overload design team. This will help others to replicate the simulation 
results of the design team.

The following highlights a few differences between the design team model 
and the model in the draft:
- 6.1 Modeling the Network
   + Figure 4: the design team topology is based on a star-like 
structure with (Nep=5) edge proxies and (Nhp=2) core proxies instead of 
a tree structure. This change should be reflected in figure 4.
   + Page 14, last three paragraphs: the design team did not 
specifically model the network (apart from assuming reliable message 
delivery between nodes). The queue based model described in the three 
paragraphs should be replaced by a model that delivers messages from one 
node to the input buffer of another node.

- 6.2 Modeling of User Agents
   + It could be added that INVITE transactions are modeled as 
INV/183/200/ACK e2e with a 100 trying from each hop. PRACKs and BYEs are 
not included in the simulation.

- 6.3 Modeling of Proxies
   + Figure 5 and first paragraph: the design team model uses a single 
queue followed by a processing element (i.e. not a two stage model). It 
is assumed that the queue has depth (D=500) messages. The processing 
element can process request and responses at a rate of (MU=500) messages 
per second and can reject requests with a 503 at a rate of (MU2=3000) 
messages per second.


Nits:

* page 4, last paragraph, 4 sentence: "over" is missing: Furthermore, 
during *over*load, the overall capacity...

* page 6, last paragraph, 3 sentence: "ever" is missing: How*ever*, a 
single request from the client,...

* page 9, section 4.3, 4 sentence: of -> off: A server can turn *off* 
all traffic towards it,...

* page 10: REQ 1, 1 sentence: "server" is missing: ... applications) of 
a SIP *server* at reasonable levels ...