Subject: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt]

From: Volker Hilt <[email-masked]>
Date: Thu, 17 May 2007 13:11:13 -0400

Below is a draft that proposes a correction to the definition of 503 
(Service Unavailable) responses in RFC 3261. The goal of this draft is 
to avoid some of the problems that have been identified with 503, 
however, it does not attempt to provide a full blown overload control 
solution.

http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-00.txt

Comments, thoughts are highly appreciated.

Thanks,

Volker

Subject: I-D ACTION:draft-hilt-sip-correction-503-00.txt
From: [email-masked]
To: [email-masked]
Date: Mon, 14 May 2007 15:50:02 -0400
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Essential Correction to the Session Initiation Protocol (SIP) 503 (Service Unavailable) Response
	Author(s)	: V. Hilt
	Filename	: draft-hilt-sip-correction-503-00.txt
	Pages		: 9
	Date		: 2007-5-14
	
   Overload occurs in the Session Initiation Protocol (SIP) when SIP
   servers have insufficient resources to process all SIP messages they
   receive.  The SIP protocol specified in RFC 3261 provides the 503
   (Service Unavailable) response code as a remedy for servers under
   overload.  However, the current definition of 503 (Service
   Unavailable) has problems and can in fact amplify an overload
   condition.  This document proposes an essential correction to RFC
   3261 that avoids these problems and helps SIP servers to better cope
   with overload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-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-sip-correction-503-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-sip-correction-503-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
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 18 May 2007 10:35:23 -0500

Volker,

Can I explain why you believe that for "small" servers (supporting < 20
clients) you believe
that the retry after is problematic? I don't think it's that clear from
the draft.

And if so, would there be a way to mitigate the oscillation while
allowing the Retry-After?

I'm a little concerned about a rule that seems somewhat vague on this. 

> -----Original Message-----
> From: Volker Hilt [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2007 10:11
> To: sip
> Subject: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt]
> 
> Below is a draft that proposes a correction to the definition 
> of 503 (Service Unavailable) responses in RFC 3261. The goal 
> of this draft is to avoid some of the problems that have been 
> identified with 503, however, it does not attempt to provide 
> a full blown overload control solution.
>

---

From: Volker Hilt <[email-masked]>
Date: Mon, 21 May 2007 17:19:37 -0400

Francois,
> that the retry after is problematic? I don't think it's that clear from
The problem of 503 with Retry-After is described in greater detail in 
Sections 4.1 and 4.3 of draft-ietf-sipping-overload-reqs-00. In short, 
503 with Retry-After may lead to the oscillation of traffic a server 
receives and the shifting of load between servers.

> allowing the Retry-After?
The proposed changes 5. and 6. would still allow a Retry-After header, 
although it would be restricted to a single request.

An alternative to proposed change 1. (i.e. to not recommend the use of 
Retry-After in 503) could be use a Retry-After value based on 
milliseconds. This would provide a more fine grained control to 
overloaded proxies and may avoid some of the problems the current header 
has. It would work for servers irrespective of the number of clients. 
However, it would change the semantics of the Retry-After value.

Overall, the goal of this draft is not to introduce a new overload 
control mechanism (which certainly should avoid traffic oscillations) 
but rather to see how far we can get with modest changes to the existing 
spec.

-- 
Volker Hilt                      Bell Labs / Alcatel-Lucent
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 21 May 2007 20:07:55 -0500

Thank you. That does answer my question. 

> Sent: Monday, May 21, 2007 14:20
> To: Audet, Francois (SC100:3055)
> Cc: sip
> Subject: Re: [Sip] [Fwd: I-D 
> ACTION:draft-hilt-sip-correction-503-00.txt]
> 
> Francois,
> > 
> > Can I explain why you believe that for "small" servers 
> (supporting < 
> > 20
> > clients) you believe
> > that the retry after is problematic? I don't think it's that clear 
> > from the draft.
> > 
> The problem of 503 with Retry-After is described in greater 
> detail in Sections 4.1 and 4.3 of 
> draft-ietf-sipping-overload-reqs-00. In short,
> 503 with Retry-After may lead to the oscillation of traffic a 
> server receives and the shifting of load between servers.
> 
> The proposed changes 5. and 6. would still allow a 
> Retry-After header, although it would be restricted to a 
> single request.
> 
> An alternative to proposed change 1. (i.e. to not recommend 
> the use of Retry-After in 503) could be use a Retry-After 
> value based on milliseconds. This would provide a more fine 
> grained control to overloaded proxies and may avoid some of 
> the problems the current header has. It would work for 
> servers irrespective of the number of clients. 
> Overall, the goal of this draft is not to introduce a new 
> overload control mechanism (which certainly should avoid 
> traffic oscillations) but rather to see how far we can get 
> with modest changes to the existing spec.
> 
> >> Subject: [Sip] [Fwd: I-D 
> ACTION:draft-hilt-sip-correction-503-00.txt]
> >>
> >> (Service Unavailable) responses in RFC 3261. The goal of 
> this draft 
> >> is to avoid some of the problems that have been identified 
> with 503, 
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> 
> --