Subject: RE: [SIP] Congestion control

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 02:45:03 -0400

> -----Original Message-----
> From: Hidefumi Nakamura [mailto:[email-masked]]
> Sent: Friday, June 22, 2001 9:17 AM
> To: [email-masked]
> Subject: [SIP] Congestion control
> 
> 
> Hi. all,
> 
> I have a couple of questions about the suitable way to let 
> the user agents/
> proxy-servers know the congestion of sip-proxy(stateful) or 
> location server, 
> and the suitable action after the notification.
> 
> As long as I review the sip document (rfc2543bis-03), I think
> the most suitable way is to return a "503 service unavailable" message
> with "Retry-after" field.  Is is correct understanding?

Yes. 

> 
> The other question is of the case when the INVITE request comes via
> several (stateful) proxy servers.  That is, INVITE comes through
> 
> UAa --> proxy A --> proxy B --> UAb
> 
> and proxy B is in congestion.
> 
> In this case, proxy B will return a "503" message to UserAgent-a (UAa)
> via proxy A if my understanding of the first question is 
> correct.  

Well, proxy A may or may not forward that upstream. The best behavior for
proxy A is to try some alternate, and only if all downstream servers are
unavailable should it return a 503 upstream.

> UAa
> will postpone to send a message to proxy A, but what should "proxy A"
> do if it receives other INVITE messages for proxyB, say, from 
> UAc, within
> the period indicated in "retry-after" field?
> Should proxy-A send "503" to UAc or transfer the INVITE message
> to proxy-B even if proxy-A already has the information that proxy-B
> is in congestion?

Proxy-A should try somewhere else, and only return a 503 upstream if nothing
is available.

I think the spec would benefit on some additional text on 503 handling.
Specifically:

1. 503 is the appropriate response to indicate congestion or any other
resource constraints that make a server temporarily congested.

2. A client receiving a 503 SHOULD attempt to contact an alternate server.

3. A server should generate and/or forward a 503 upstream only if all
requests that would reach the server cannot be serviced. This means that the
server itself is congested, or every possible next-hop it can route to is
congested (which is fairly unlikely but can happen in certain
configurations).

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.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: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Jun 2001 06:38:47 -0700

> congested (which is fairly unlikely but can happen in certain

Just in case, as I'm not sure I'm interpreting item 3 correctly:

A 503 is a statement of why the current request failed. "Past
performance is not a guarantee of future results", or some such. Thus, a
503 does not indicate that "all requests that *would* reach the server
cannot be serviced", only that the current request couldn't be serviced
due to overload. This doesn't mean that another request sent in the next
millisecond would also fail.

503 would only be returned by a forking proxy if that's the "best"
response. If one downstream server returns a 517 (imaginary) and another
a 503, a 503 is returned. Thus, it is not necessary that *all* next-hops
return 503 for a 503 to be returned. Normally, the proxy would retry
alternate servers on a fork that returned a 503, so it does mean that at
least one branch is unreachable due to congestion and that others
returned "worse" error codes.