Subject: RE: [SIP] Congestion control

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 05:27:45 -0400

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, June 28, 2001 11:19 AM
> To: Gordon Ledgard
> Cc: Jonathan Rosenberg; 'Hidefumi Nakamura'; [email-masked]'
> Subject: Re: [SIP] Congestion control
> 
> 
> 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.

I agree definitely as well that we want to avoid special cases. It ocurred
to me later that there aren't really problems with a 503 without
Retry-After, and that normal response processing will work. The issue with
#3 only arises when Retry-After is present, and in this case, normal
response processing may not do the right thing depending on the
interpretation of Retry-After.

Why? My interpretation of 503 w/o Retry-After is that the server is
reporting that it can't handle THIS transaction. It says nothing about any
others for any future time. So, a client that gets a 503 tries a different
server. A proxy which forked, and received 503 on all branches, is in a
situation where, for this transaction, it truly cannot process it, and so
forwarding the 503 upstream is the right thing to do.

Retry-After is a different story. Consider the case of UAC A, that sends an
INVITE to local outbound proxy B, which proxies that to proxy C. Proxy C is
running on an old 8088 with 32k of RAM. So, when it gets the INVITE, it
returns a 503 with a Retry-After of 1 day. This is forwarded by B to A. Now,
how should A interpret this response?

1. don't send any requests to proxy B for 1 day
2. don't send any requests to the user in the request URI of the original
INVITE for 1 day

If the interpretation is 1 - meaning that a retry-after in a 503 means that
the SERVER is busy - I would argue that forwarding the 503 with that
retry-after header in tact is the wrong thing to do. The right behavior
would probably be for the proxy to strip the Retry-After in the 503 before
forwarding it upstream. In other words, if 503 has a hop-by-hop semantic,
indicating to the previous server the state of the server generating the
503, then 503 with a Retry-After should never be forwarded upstream, since
its telling the previous server the state of a server two hops down, which
is not the interpretation of the 503.

If the interpretation is 2 - meaning that Retry-After in a 503 means that
the server can't handle requests for that resource, forwarding the
Retry-After upstream is just fine.

Now, we inherited 503 from HTTP, where I believe it truly did mean that the
SERVER was busy. However, the problem we are encountering with this
interpretation this wasn't an issue for http, since only origin servers ever
generated these things, and it was only origin servers that were ever the
busy elements. With proxies playing a larger role, it gets complex.

So, we have a dilemma. The interpretation of 503 meaning "the server that
sent you this is busy" is a very useful one for failover and load
distribution, but has this nasty problem with the Retry-After. The
interpretation of 503 as "the resource in the URI cannot be reached because
a server along the way is busy" is not very useful, but more compatible with
the response processing operations in proxies.

So, I think we do have an issue here that requires the spec to clearly
define the semantic of 503, and then we need to deal with any implications
of that.

-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: Sat, 30 Jun 2001 11:10:31 -0400

> interpretation of Retry-After.

In general, I doubt that 503 with Retry-After will be used frequently,
whatever the precise definition. In almost all cases, overloads will be
temporary and unpredictable, so inserting Retry-After automatically is
going to be difficult. Given that UAs are not likely to automatically
retry and probably shouldn't unless the interval is very short (you
don't really want your phone to automatically and autonomously redial at
2 am the next morning, when the server is free again), the use for call
gapping is probably marginal.

Thus, given its limited applicability, anything that complicates the use
of 503/Retry-After is going to make sure that nobody implements it.

> forwarding the 503 upstream is the right thing to do.

Which gets interesting if it randomly picks one, as the Retry-After will
be a random selection among the branches. It is not even clear what the
right behavior should be here, since one could argue that it should be
the longest interval (to make sure I can reach the user at all forks) or
the shortest (first chance to succeed).

> define the semantic of 503, and then we need to deal with any implications

With reasonable load-balancing, 503/Retry-After should only occur if the
system is down for maintenance. 503 without Retry-After can occur due to
temporary load spikes. If somebody can keep a server up during
maintenance so that it can still say "503", it would be a better
implementation to have it redirect calls blindly to a fellow server.
Hardly more complicated.

Given the merging issue, I would suggest that taking the minimum
Retry-After value is probably the most information-conserving approach.
This would only occur if all servers failed with either 503 or some
higher 5xx code. Since other 5xx codes could conceivably also use the
Retry-After header, this seems like a generic mechanism. However, I
would treat the Retry-After value as a hint, indicating some notion of
the likelihood of success for future requests, rather than an outright
prohibition against sending a request earlier. In other words, if I see
a response to retry after a day, I won't be too surprised if it still
doesn't work two hours later (and may avoid calling tech support). If I
really need to make the call, this won't and shouldn't deter me.

In any event, a server should probably be able to do just about anything
with the Retry-After header (drop it, pick minimum value, pick random
503 response to forward), given its hint nature.