Re: [Sipping] Combined overload control draft

[Volker Hilt <[e-mail]>]

Jonathan,

thanks for the comments.

> Firstly, I think we only want to address the hop-by-hop mechanism. I 
> 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 
> 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 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.

> 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.
> 
True. We may need a timestamp/sequence number. Will add that to the next 
rev.

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

> Thats also the main security consideration you need to address - what if 
> 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


> 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:
>> [e-mail]
>> Date:
>> Tue, 17 Oct 2006 15:50:01 -0400
>> To:
>> [e-mail]
>>
>> To:
>> [e-mail]
>>
>>
>> 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 
>> [e-mail] 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:
>>     [e-mail].
>> 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
>> [e-mail]
>> 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 [e-mail] for questions on current sip
>> Use [e-mail] for new developments of core SIP
> 



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