Subject: RE: [SIP] Congestion control

From: Wai Wu <[email-masked]>
Date: Fri, 22 Jun 2001 13:15:54 -0400

"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?"

In my implementation, proxy A still forwards the INVITE message to proxy-B
for UAc. This is so since the UA the UAc is trying to contact might very
well be different from that of UAa. Take the example of proxy-B forwards the
request to two different PSTN gateway, one for local calls and the other for
international calls. The international all gateway might be down but not the
local call gateway. 

Wai

-----Original Message-----
From: Hidefumi Nakamura [mailto:[email-masked]]
Sent: Friday, June 22, 2001 6: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?

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

Please let me know.

Thanks.

---
Hidefumi NAKAMURA
NTT Network Service Systems Laboratories
tel:+81 (422)59 3904; fax:+81 (422)60 4012
---

---

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

This brings up an interesting question, actually. Does "try an alternate
server" mean that the next SRV record entry should be tried? If so, this
needs specification in draft-ietf-sip-srv.

-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

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 2:45 AM
> To: 'Hidefumi Nakamura'; [email-masked]'
> Subject: RE: [SIP] Congestion control
> 
> 
> 
> 
>  
> 
> > Sent: Friday, June 22, 2001 9:17 AM
> Yes. 
> > 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
> 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
> 

_______________________________________________
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: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 26 Jun 2001 17:11:49 +0100

see below

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Jonathan Rosenberg[SMTP:[email-masked]]
> Sent: 	26 June 2001 7:45
> I think the spec would benefit on some additional text on 503 handling.
> Specifically:
> 
> 2. A client receiving a 503 SHOULD attempt to contact an alternate server.
> 
> 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
What if the registrar of the terminating user is congested? Should such an
entity return a 503 if it knows there is no other server?

I believe the requirement "SHOULD contact an alternative server", and a
general requirement to return a 503 are not particularly consistent -
either:

a)	the general requirement to return a 503 results in a MAY contact an
additional server

b)	a 503 should be returned only when it is believed an additional
server exists, and therefore under those circumstances the client SHOULD
contact an additional server.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 18:11:54 -0400

> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 12:12 PM
> To: [email-masked]'; 'Jonathan Rosenberg'

Yes. Similarly, a gateway would return a 503 if it runs out of ports.

> contact an additional server.

Well, there may not be a way for some server X to know whether the upstream
server Y knows an alternative to X. THerefore, its unreasonable to say that
X should only return a 503 if it knows Y might find an alternate. A classic
example is where X is a PSTN gateway, and Y a proxy with a series of phone
routes. In this case, if X is busy, Y can try a different (and perhaps more
expensive) gateway. But, I don't want to have X need to know about the
existence of all other gateways.

Thus, I do not see how the requirements are in conflict.

-Jonathan R.
---

---

From: "Giuseppe De Marco (TEI)" <[email-masked]>
Date: Wed, 27 Jun 2001 09:49:16 +0200

I am not an expert on SIP. But, reading your message, I think that there are two way to solve the problem:
1) By modifyng the proxy A which would changes its state machine if receive a 503 response from other proxy server, so that the next calls form othe UA's will be propley delayd, without proxying calls away;
2) whitout modifyng the proxy, proxy A ignores the information about congestion on others proxies, and repeats its function for every call as it is a first call.

bye

giuseppe de marco

-----Original Message-----
From: Hidefumi Nakamura
To: [email-masked]
Sent: 22/06/01 15.17
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.

do if it receives other INVITE messages for proxyB, say, from UAc,
within

Please let me know.

Thanks.

---
Hidefumi NAKAMURA

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Gordon Ledgard <[email-masked]>
Date: Thu, 28 Jun 2001 11:32:12 -0400

Agreed.

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

Gordon Ledgard wrote:
> Henning wrote -
> >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

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

---

From: Gordon Ledgard <[email-masked]>
Date: Fri, 29 Jun 2001 09:54:31 -0400

Jonathan wrote - 

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

Interesting dilemma. I'd say that if we treated 503's as in case 2,
we would be left searching for a new way to describe individual
hops in the network being busy. If we treat 503's as in case 1,
we handle both situations of the endpoint being busy, or a hop
being busy, and there should be no issue. Then we must interpret
Retry-After on a hop-by-hop case, like you say Jonathan, and
strip them off (or replace the timer) upstream.

I think that works.

Gordon R. Ledgard
IPeria, Inc.
(781) 993-3540