Thank you. That does answer my question. > -----Original Message----- > From: Volker Hilt [mailto:[EMAIL PROTECTED] > 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. > > > And if so, would there be a way to mitigate the oscillation while > > 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. > > > I'm a little concerned about a rule that seems somewhat > vague on this. > > > >> -----Original Message----- > >> From: Volker Hilt [mailto:[EMAIL PROTECTED] > >> 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. > >> > >> http://www.ietf.org/internet-drafts/draft-hilt-sip-correction- > > 503-00.txt > >> Comments, thoughts are highly appreciated. > >> > >> Thanks, > >> > >> Volker > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > [EMAIL PROTECTED] for questions on current sip Use > > [EMAIL PROTECTED] for new developments on the application of sip > > > -- > Volker Hilt Bell Labs / Alcatel-Lucent > phone: +1 732 332 6432 101 Crawfords Corner Rd > email: [EMAIL PROTECTED] Holmdel, NJ 07733 > >
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
