Re: [Sipping] Combined overload control draft

[Jonathan Rosenberg <[e-mail]>]

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:
> [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

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP