Subject: RE: [Sipping] Overload error codes

From: "Kiyanda, Bernard" <[email-masked]>
Date: Mon, 8 Jan 2007 11:21:48 -0500

I agree that an overloading response code would make for a clear transaction completion. In the case of a proxy "failing over" to some server/load balancing list and still unsuccessfully completing the transaction (e.g. mix of overload rsp and 5xx), would the proxy response to the initiating UA remain a 503 rsp?

Bernard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 08, 2007 10:40 AM
To: [email-masked]
Subject: [Sipping] Overload error codes

While we're at it, I think we need to define another error code.  503
means "this element is overloaded" and is supposed to have hop-by-hop
semantics.  In particular, a proxy that receives a 503 from downstream
should not send a 503 upstream, for fear of preventing upstream
elements from sending it any further traffic.

But we need a way of signalling to a UAC that its request failed due
to overload *somewhere*, much like the "reorder" signal in the PSTN.

This becomes increasingly important as proxy systems get more
sophisticated and start incorporating "failover" processing -- a
request sent on one path that has overloaded should be sent to a
failover path, but most other failures should not be.

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 8 Jan 2007 11:41:15 -0500

Isn't that where we started this discussion?

Janet

"Kiyanda, Bernard" <[email-masked]> wrote on 01/08/2007 11:21:48 AM:

> I agree that an overloading response code would make for a clear
> transaction completion. In the case of a proxy "failing over" to
> some server/load balancing list and still unsuccessfully completing
> the transaction (e.g. mix of overload rsp and 5xx), would the proxy
> response to the initiating UA remain a 503 rsp?
>
> Bernard
>

---

From: [email-masked]
Date: Mon, 8 Jan 2007 12:50:49 -0500

From: "Kiyanda, Bernard" <[email-masked]>

The discussion shows that by default the answer is no.  But I think
that in some special cases, such as when *all possible* downstream
paths from the proxy are overloaded, a 503 response upstream would be
reasonable, as all possible incoming traffic is affected.  This sort
of situation would be rare in servers on the wider Internet, but in
some closed systems, it might be a reasonable response.

Dale

---

From: [email-masked]
Date: Mon, 8 Jan 2007 12:54:04 -0500

From: Janet P Gunn <[email-masked]>

That might be, but I haven't seen a resolution to the response code
problem.

If an element adopts a more sophisticated overload control system, I
can envision that it might never return 503's, as it is careful to use
responses and signalling that more clearly describe its condition.
But in any case where load control or overloading is possible, we need
a "request could not be completed due to overload" response at the
end-to-end level, and RFC 3261 makes it clear that 503 is not that.

Dale

---

From: Volker Hilt <[email-masked]>
Date: Mon, 08 Jan 2007 16:15:42 -0500

If a proxy that has received a 503 response is not overloaded and knows 
it can still service requests, it should not forward the 503. Instead it 
will typically create a 500 response for the request. A problem with 
this is that a proxy that is further upstream usually does not know that 
the 500 was created because of a 503 (or any other overload indication 
to be defined) by a downstream proxy. This information might be helpful 
if the upstream proxy has an alternative path it can try to reach the 
target.

This problem seems to apply in general to all cases in which a proxy 
generates an error and not the final recipient. In all those cases, 
there might be an alternative path to the target. Since there are 
different reasons why a proxy could fail besides overload, I'm not sure 
if this is really a problem that is specific to overload control or if 
this is another issue.

Volker

---

From: [email-masked]
Date: Mon, 8 Jan 2007 17:26:41 -0500

From: Volker Hilt <[email-masked]>

Yes, that's true.  But most failure responses we now have can be
classified as "coming from the UA" vs. "coming from intermediate
systems".  E.g., 486 vs. 404.  Since we're now discussing overload,
I'd like to get its response codes clearly classified.

Dale

---

From: Volker Hilt <[email-masked]>
Date: Tue, 09 Jan 2007 17:21:19 -0500

> I'd like to get its response codes clearly classified.
I think overload can occur in the UAS and in an intermediate system. So 
I don't think a new overload response code would really fall into one of 
the categories "coming from the UA" or "coming from intermediate 
systems". However, I agree that it may still make sense to make it 
explicit that a request has been rejected because of overload instead of 
using the more generic 500 response. An alternative to a new response 
code could be the use of a warning header in a 500 response.

Volker