Subject: RE: [SIP] Congestion control

From: Gordon Ledgard <[email-masked]>
Date: Thu, 28 Jun 2001 10:02:57 -0400

Henning wrote -

>> 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).

>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.

I think item three is supposed to touch down on elements like load
balancers,
or failover control units. Picture an invite landing on a unit that
balances between several other servers, or better yet, say there was
some kind of fanout such that each node had a set of possibilities for
routing. When a 503 is returned, you are correct that the receiver of the
503 cannot know for how long the congestion will last in the sender, but
it may have to assume. A machine which is balancing requests will need
an algorithm inside it that says something to the effect of, "if a server
returns a 503 to me, I need to back off and wait X until I try again."
The choice of "X" may even need to be empirical, or calculated in an
active network to arrive at a resonable number, since the balancer cannot
know the recovery time of all the servers it might be connected to.

But the main point of item three is that the balancer's algorithm must
also have logic that says, in effect, "When I have tried all routes going
out of me, and have received 503's (or equivalents) from all of them,
I must assume that I am, and will remain, congested myself for some
period of time. So rather that keep hunting for routes out of myself
tell the caller to find another route."

Anyway... that's how I interpret it.

Gordon Ledgard

_______________________________________________
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 G. Schulzrinne" <[email-masked]>
Date: Thu, 28 Jun 2001 11:19:13 -0400

The point I was trying to make is that I see no reason to treat 503 as a
special case. I would like to avoid lots of rules and regulations for
each response code, for things that are essentially implementation
issues. We do have the Retry-After header if the server wants to pace
requests by a client, e.g., for some kind of mass calling event where it
knows that things are hopeless for the next hour. However, none of this
belongs in the spec.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs