Subject: Re: [Sipping] Combined overload control draft

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 17:44:26 -0500

Overall, this is very good. I think it is pretty much on target to what 
we need, and is more or less what I had in mind.

Some comments of course.

Firstly, I think we only want to address the hop-by-hop mechanism. I 
don't think we can do the e2e.

Secondly, I don't see a need to report load. I think we are much better 
off by specifying a throttle value, and defining a normative algorithm 
that gets executed on the upstream server. You have tried to avoid a 
normative algorithm. However I think its essential. Knowledge of what 
the upstream behavior will be is key to deciding how to transform 
knowledge of load into a set of parameters to include in the response. 
Much like TCP specifies AIMD on the upstream elements, we need something 
like that.

I like the way you fade out the load estimates. One issue you need to 
address is that a client will get lots of load values from the same 
downstream server (one in each response). So does it keep the most 
recent? How do you define most recent? You need to address that.

I'm not sure I agree with using 503 with upstream elements that don't 
support it. This introduces the possibility of making things worse 
because of the known problems with 503. I'd prefer a new response code 
or something. Another piece of this is whether an element needs to 
implement some kind of fairness algorithm so that it doesn't give 
disproportionate work to upstream elements which don't throttle.

Thats also the main security consideration you need to address - what if 
an upstream element doesn't obey the throttle instructions.

-Jonathan R.

Volker Hilt wrote:

> We have submitted a new overload control draft that combines the two 
> existing overload drafts: draft-hilt-sipping-hopbyhop-overload-00 and 
> draft-malas-sipping-congestion-header-01.
> 
> In addition to combining the existing drafts, the new draft has been 
> completely revised to accommodate comments and feedback received and it 
> has a new section that discusses design considerations and introduces a 
> control model for SIP overload control.
> 
> Volker
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D ACTION:draft-hilt-sipping-overload-00.txt
> From:
> [email-masked]
> Date:
> Tue, 17 Oct 2006 15:50:01 -0400
> To:
> [email-masked]
> 
> To:
> [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Session Initiation Protocol (SIP) Overload Control
> 	Author(s)	: V. Hilt, et al.
> 	Filename	: draft-hilt-sipping-overload-00.txt
> 	Pages		: 23
> 	Date		: 2006-10-17
> 	
>    Overload occurs in Session Initiation Protocol (SIP) networks when
>    SIP servers have insufficient resources to handle all SIP messages
>    they receive.  Even though the SIP protocol provides a limited
>    overload control mechanism through its 503 response code, SIP servers
>    are still vulnerable to overload.  This specification defines a new
>    SIP overload control mechanism that protects SIP servers against
>    overload.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hilt-sipping-overload-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-hilt-sipping-overload-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-hilt-sipping-overload-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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: Thu, 02 Nov 2006 15:02:26 -0500

Jonathan,

thanks for the comments.

> don't think we can do the e2e.
I agree!!

> Secondly, I don't see a need to report load. 

I think reporting the load is useful if it is done in *addition* to a 
throttle value. This is essentially the model three in the draft. 
Overload control is done via the throttle value, however, the load value 
provides extra information that helps a proxy to find underutilized 
servers (e.g. to retarget a request).

> I think we are much better 
I completely agree that we need to define a normative behavior for the 
throttle value on the upstream server for exactly the reasons you state.

I think the hard part is to find out what works best as throttle value. 
A percentage value (e.g. reject/redirect 10% of the traffic) is easy to 
calculate in the downstream server and easy to use in the upstream 
server. The problem is that the value needs to be constantly adjusted if 
load varies. For example, if a downstream proxy sets a throttle value of 
10% but the load increases by 20%, the downstream proxy will see an 
increase of 10% instead of a decrease.

An alternative is to use an absolute request rate (e.g. 100 requests per 
second). The problem here is that the algorithm in the downstream entity 
now has to assign a given request rate to each of its upstream server. 
Thus, it needs to know its upstream servers and split its processing 
capacity across them. It needs to re-evaluate this rate as the load 
varies and upstream servers appear/disappear and needs to avoid the 
starvation of servers or the assignment of too high capacities.

> recent? How do you define most recent? You need to address that.
True. We may need a timestamp/sequence number. Will add that to the next 
rev.

> disproportionate work to upstream elements which don't throttle.
I'm not sure how a new response code would help elements that don't 
support the extension since these nodes would probably not understand 
the new response code as well. Would this be like sending e.g. a 500 for 
each request?

> an upstream element doesn't obey the throttle instructions.
That's true. Need to add that to the next rev. Depending on the throttle 
value we choose, it might be difficult to find out if the upstream 
server obeys or not. If a percentage value is used, how does the 
downstream server know if the upstream server actually follows the 
throttle instruction? It is easier to do for a fixed rate.

Thanks,

Volker

>> completely revised to accommodate comments and feedback received and 
>> it has a new section that discusses design considerations and 
>> introduces a control model for SIP overload control.
>>
>> Volker
>>
>>
>>
>> the message. You can also visit 
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>> subscription settings.
>>
>> logging in, type "cd internet-drafts" and then "get 
>> draft-hilt-sipping-overload-00.txt".
>>
>> http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>