[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] Combined overload control draft



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:
Internet-Drafts at ietf.org
Date:
Tue, 17 Oct 2006 15:50:01 -0400
To:
i-d-announce at ietf.org

To:
i-d-announce at ietf.org


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 i-d-announce-request at ietf.org 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:
	mailserv at ietf.org.
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
I-D-Announce at ietf.org
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP

-- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen at cisco.com 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP