Subject: Re: [Sipping] Further Information from the sipping "Overload Design Team Status" needed

From: Volker Hilt <[email-masked]>
Date: Wed, 02 Jan 2008 12:23:16 -0500

Moran, Timothy L. wrote:
> Greetings,
> 
> I have been out of the IETF loop for a few years – so please bear with me.
> 
> Draft “Requirements for Management of Overload in the Session 
> Initiation” discusses the need for a SIP overload control mechanism due 
> to (it would seem) limitations of the 503 “Service Unavailable” 
> response. Drafts from hilt and chadli are responses to the requirements 
> draft. However, the presentation “Overload Design Team Status” provides 
> simulation results of using different overload algorithms to dictate 
> when a 503 response with the Retry-After is sent.
> 
> Questions:
> 
> 1.      Is there backup text to the Overload Team’s presentation?
> 
> 2.      Is the 503 with Retry-After an option or has it been truly 
> eliminated? If so, why is the team evaluation algorithms for sending the 
> 503 ???
> 
Individuals in the design team have proposed different algorithms. The 
different proposals are currently under investigation. The ones that 
were presented on the last IETF meeting were indeed based on using 503 
with Retry-After. The Retry-After period here is measured in 
milliseconds, which is a difference to the current 503.

> 3.      It would appear (e.g. draft-hilt sections 3.7) that a feedback 
> mechanism is needed to convey overload from a receiving SIP entity to a 
> sending SIP entity. Two proposals are a SIP response header and a Notify 
> (in response to a subscription). How (logically) different are these 
> mechanisms from a 503? 

One of the main differences is that 503 turns traffic completely off and 
back on on. When this is done a fine enough granularity (e.g., shutting 
traffic off for a few hundred milliseconds before turning it back on), 
it seems possible to lower the incoming traffic to the desired amount.

A feedback provides a given rate-limit or loss-rate to the sending 
entity. The sending entity can use this feedback to lower traffic to the 
desired amount.

Overall, it seems that feedback would allow the sending entity more 
freedom in choosing the messages to discard and require less 
communication since feedback, once set, can be used for over a longer 
period of time.

> Having asked this, I seem to recall that a 503 
> response should not be relayed by a proxy for fear of misinterpretation 
> of which entity is overloaded. Is this a SIP design issue or an 
> implementation issue? That is, what’s so unique about a 503 response vs. 
> other responses???
> 
Yes, that's how 503 is defined.

Volker

> 4.      Finally, for an RPH labeled request – what assurance is there 
> that the overloaded server can process enough of the message to read the 
> RPH field and honor the priority? None???
> 
> BR,
> 
> Tim M.
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

_______________________________________________
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