Subject: [Sipping] Re: review of draft-ietf-sipping-overload-reqs-00

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

Thanks for the review, and apologies for the very delinquent response. 
Comments below:

Volker Hilt wrote:
> 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.

Sure, but an overloaded proxy can reject messages too. If the DNS server 
is overloaded and can only handle 20 messages per second, and the SIP 
server can handle 100, if the server is presented with 100 messages per 
second, it will only process 20, and reject the rest. How does this 
differ from a proxy that can only handle 25 messages per second, is 
given 100, and processes 20 while rejecting 80? I think in all useful 
ways, this is the same.

As another analogy, consider the same example but with a database that 
can do 20 messages per second. What happens if the database is on the 
same box, so its an external process but not an external server. Would 
this count as overload then?

OK, what if the database is a separate thread, but can only do 20 
messages per second?

I think all of these are the same; in essence, the CPU/disk/etc of the 
external resource is, logically, part of the element that is processing 
the request, and its capacity counts.

I think what is needed here is to clarify the meaning of overload:

<t>Overload occurs when an element, such as a SIP user agent or proxy,
has insufficient resources to successfully process all of the traffic
it is receiving. Resources include all of the capabilities of the
element used to process a request, including CPU processing, memory,
I/O, or disk resources. It can also include external resources, such
as a database or DNS server, in which case the CPU, processing,
memory, I/O and disk resources of those servers are effectively part
of the logical element processing the request. Overload can occur for
many reasons, including:
</t>

Given this definition, which puts it in terms of goodput, I think its 
clear that external resources count.

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

No - see above. I will clarify here that is both failure and overload of 
the external resource.

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

the words in brackets are extraneous anyway here, so I removed.

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

fixed.

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

fixed

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

I think these are issues with the mechanism, not the requirements. Its 
clear the mechanism needs to be designed to operate differently in these 
two cases. Whether we do that in one doucment or two documents is a 
procedural thing. The requirements are the same.

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

I just responded to Mary's comments on this; I'd prefer to remove this 
section entirely from this document. Rather, the simulation model that 
is utilized should be published along with the simulation results in 
whatever venue that happens (whether its an informational ID or a paper 
or whatever).

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

all fixed.

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

---

From: Volker Hilt <[email-masked]>
Date: Mon, 19 Nov 2007 19:45:27 -0500

Jonathan Rosenberg wrote:
>> * 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 
I agree that overload control should be used whenever a device has 
insufficient resources to process all incoming requests. What the 
limiting resources are is device specific and really shouldn't matter.

I think there are cases, in which a device runs out of a resource but is 
still able to reject requests with a *meaningful* response code. For 
example, a PSTN gateway that runs out of trunk lines should probably use 
488 instead of overload control. In this case, its SIP processor is 
actually not overloaded and it is still able to process SIP messages.

Thus, I think the key point is that a device is endangered of not being 
able to process all incoming requests and might need to drop messages 
otherwise.

Volker