Subject: [Sip] Ambiguity, redirection and Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt

From: [email-masked]
Date: Tue, 22 May 2007 17:22:24 -0400

Hi, 

I've had a look at this draft, and have a few questions / concerns.  My 
apologies if this is covered somehow in the overload work (I am not 
following it closely), or if I missed some discussion going by. 

Basically, I think there are some potential problems with ambiguity, and 
also no good way to tell the client where (or if) to go somewhere else for 
service.  Specifically: 

o 500 would become overloaded to mean either "something bad (but 
unspecified) happened" or "go somewhere else (maybe try again later)", but 
it seems impossible to determine which case it is.   The name of this code 
implies only the former. 

o 503 changes its meaning to "I'm overloaded, back off (optionally don't 
try again for some time)".   But this is not the name of this response -- 
it is Service Unavailable.  The trouble is, there are many reasons why 
service may not be available, overload being just one.   (Yes, I know this 
issue is raised as OPEN ISSUE 3  in the draft itself.) 

Proposals: 

1.  Can a new 5xx response code be defined specifically to handle overload 
scenarios, instead of overloading 503 / 500?  This would have the explicit 
semantic of "I'm overloaded, back off (optionally for some time)".   It 
could also have additional info on how the client should handle it (see 
next).  503 would keep its original meaning (go somewhere else), and 500 
would keep its meaning (something bad happened). 

2.  Add a new header, to explicitly list one or more servers to go get 
service from, usable (at least) in 503 and the new 5xx, maybe 500 also. 
With this, 503 could have the additional semantic of "go somewhere else, 
and here's where" (optionally with a time to retry here).   New 5xx could 
have the additional semantic of "I'm overloaded, go here instead" 
(optionally with a time to retry here). 

I can certainly see cases, even in overload handling, where the current 
server may want to explicitly send the client somewhere else, effectively 
redirecting to a different server. This could be either to an explicit 
server (or list of them), or just "go try somewhere else, you figure it 
out".   Also handy for maintenance operations and for load sharing, 
possibly others.  Lack of an explicit way to send clients elsewhere for 
service seems like a weakness overall.  Hopefully, the above (or something 
along those lines) could help both dis-ambiguate, and help by acting as a 
redirection for those cases needing it.  Minimally, it would at least make 
it easier to figure out (in the implementation) what the client is being 
told to do, and would make troubleshooting a whole lot easier. 

I do understand the desire to minimize changes.  But it is also important 
to get the right behaviour, and not create situations open to too much 
interpretation.  Yes, there would be lots of backwards compatibility 
issues, but any change in this stuff will have loads anyway. 

Just throwing some ideas out there to see if the flame throwers come out.  
(Donning my flame-proof suit now .....    ;-) 

Cheers,
Peter Blatherwick

_______________________________________________
Sip mailing list  https://www1.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: Volker Hilt <[email-masked]>
Date: Tue, 22 May 2007 21:37:33 -0400

Peter,

thanks much for the comments!

> also no good way to tell the client where (or if) to go somewhere else 
> for service.  Specifically:
> 
> unspecified) happened" or "go somewhere else (maybe try again later)", 
> but it seems impossible to determine which case it is.   The name of 
> this code implies only the former.  
> 
The changes proposed in the draft should not affect the 500 response 
code. In which respect would there be a change to 500?

> try again for some time)".   But this is not the name of this response 
> -- it is Service Unavailable.  The trouble is, there are many reasons 
> why service may not be available, overload being just one.   (Yes, I 
> know this issue is raised as OPEN ISSUE 3  in the draft itself.)  
> 
503 means that the "server is temporarily unable to process the request 
due to a temporary overloading or maintenance of the server."

It seems that 503 is working reasonably well for maintenance but not for 
overload. So the question is if we can change the overload behavior 
without breaking the maintenance part. I believe that the proposed 
changes 1. - 4. would provide such a change if 503 is used as today for 
maintenance (with Retry-After) and without Retry-After as described for 
proxies under overload.

> Proposals:
> 
> 1.  Can a new 5xx response code be defined specifically to handle 
> overload scenarios, instead of overloading 503 / 500?  This would have 
> the explicit semantic of "I'm overloaded, back off (optionally for some 
> time)".   It could also have additional info on how the client should 
> handle it (see next).  503 would keep its original meaning (go somewhere 
> else), and 500 would keep its meaning (something bad happened).  
> 
I think this would be closer to a new SIP extension for overload 
control, which I think is useful, than to a correction of RFC3261, which 
is the scope of this draft.

> With this, 503 could have the additional semantic of "go somewhere 
> else, and here's where" (optionally with a time to retry here).   New 
> 5xx could have the additional semantic of "I'm overloaded, go here 
> instead" (optionally with a time to retry here).  
> 
> server may want to explicitly send the client somewhere else, 
> effectively redirecting to a different server. This could be either to 
> an explicit server (or list of them), or just "go try somewhere else, 
> you figure it out".   Also handy for maintenance operations and for load 
> sharing, possibly others.  Lack of an explicit way to send clients 
> elsewhere for service seems like a weakness overall.  

I can see that it might be useful in some scenarios to provide these 
kind of hints to the client. But often a client is able to find backup 
servers even without such hints, e.g., through DNS. The client might 
also know of other server the overloaded server wasn't aware of. With a 
redirection list, a server would need to know all its peers that might 
possibly jump in if it is overloaded.

I think that being specific in a response about what went wrong (e.g. 
"I'm overloaded") is useful since it will help the client to react 
properly (e.g. not to resend the request).

> Hopefully, the 
> above (or something along those lines) could help both dis-ambiguate, 
> and help by acting as a redirection for those cases needing it. 
> Minimally, it would at least make it easier to figure out (in the 
> implementation) what the client is being told to do, and would make 
> troubleshooting a whole lot easier.    
> 
> I do understand the desire to minimize changes.  But it is also 
> important to get the right behaviour, and not create situations open to 
> too much interpretation.  Yes, there would be lots of backwards 
> compatibility issues, but any change in this stuff will have loads 
> anyway.  
> 
I agree. However, as mentioned, this draft is not intending to propose a 
SIP extension for overload control.

> Just throwing some ideas out there to see if the flame throwers come 
> out.   (Donning my flame-proof suit now .....    ;-)
> 
This kind of input is highly appreciated! :)

Thanks,

Volker

---

From: [email-masked]
Date: Wed, 23 May 2007 14:48:11 -0400

Hi, 
Thanks for comments back.  See [PB] inline below.   I've snipped a bunch 
to keep the volume to a dull roar. 

> code. In which respect would there be a change to 500?
 
[PB] The change, as I see it, is that 503 would no longer be used to 
send a client elsewhere, or cause the client to think it should go, 
in fact would make the client think it should NOT go.  So, 500 would 
need to take on that meaning. 

[PB] The bits that triggered me thinking this way are:
ISSUE 3, sec 4, 
  "... Should all non-overload failures be changed to 500 (Server 
   Internal Error)?  It would, e.g., enable a proxy [or client] to 
   try alternate servers for all non-overload failure cases."
and sec 6.1
  "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   NOT attempt to forward the request to an alternate server. ..."

> due to a temporary overloading or maintenance of the server."

[PB] Current draft text is
  "... server is temporarily unable to process the request due to a
   temporary overloading ..."

> maintenance (with Retry-After) and without Retry-After as described for 

[PB] But, for maintenance and similar cases, you may actually want the 
client to go elsewhere for service.  Text in the draft would prohibit 
this from happening, see sec 6.1
  "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   NOT attempt to forward the request to an alternate server. ..." 
Hence the proposal to make the desired redirect-like behaviour explicit 
somehow. 

> is the scope of this draft.

[PB] Could be, or maybe not -- not really my call.  Just a thought.  But 
if such a thing were to be done in overload work, it would effectively 
be undoing this draft, would it not? 

>> you figure it out".   [snip] 
>> 

[PB] Certainly agree, it would be advantageous to be able to inform the 
client "go find somewhere else", but also think in other circumstances 
(notably clustered servers) it would be advantageous to be explicit 
"go here".  I expect if we were to go for a new header (or similar), 
we could probably find some way to accommodate both meanings. 

> properly (e.g. not to resend the request).

[PB] Certainly agree here too.  In fact, if we could find some way to 
provide just that hint in 503 (reason = overload vs maintenance, vs 
load sharing ... ), then we could distinguish the cases.  This would 
eliminate, or at least make less strong, the proposal for a new 5xx. 
Still think the redirect-like "go here" header would be good though. 

[snip]

>> too much interpretation.  [snip]
>> 

> SIP extension for overload control.

[PB] One problem being, the changes in this draft do focus on overload, 
yet the more general overload work does not focus on any of the other 
scenarios. 

-- Peter

---

From: Volker Hilt <[email-masked]>
Date: Wed, 23 May 2007 18:59:05 -0400

> need to take on that meaning.  
I don't think that the draft implies this change in semantics for 500s 
(and it certainly wasn't the intention). Even today, a client can always 
go somewhere else after a 500 if it has discovered an alternate server.

I do think that there is an important point regarding the use for 
maintenance (see below).

>    temporary overloading ..."
The current draft covers overload only and does not address the 
maintenance aspect of 503. This is certainly something that needs to be 
addressed in the draft.

One of the troubles of the maintenance and overload uses is that they 
have different requirements. For maintenance, it makes sense for a 
client to resend the request, which it should not do under overload. For 
this reason, if 503 is used for both cases, a client need to be able to 
tell what it is supposed to do.

> Hence the proposal to make the desired redirect-like behaviour explicit
Yes, I certainly agree.

> be undoing this draft, would it not?
I wouldn't think so. I think getting the use of 503 under overload right 
is important and provides a basic/local way for a server to handle 
overload. It seems somewhat orthogonal to a SIP extension for overload 
control.

> eliminate, or at least make less strong, the proposal for a new 5xx.  

I fully agree - and maybe there IS a case for a new response code.

> yet the more general overload work does not focus on any of the other
Generally, I think an overload control mechanism should focus on 
overload control and not try to cover as much as possible. But it 
certainly should not break anything that works today.

Volker