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

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

>> 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. 
>> 
> The changes proposed in the draft should not affect the 500 response 
> 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. ..."

>> 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.) 
>> 
> 503 means that the "server is temporarily unable to process the request 
> 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 ..."

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

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

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

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

>> 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".   [snip] 
>> 
> 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. 

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

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

[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]
>> 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.  [snip]
>> 
> I agree. However, as mentioned, this draft is not intending to propose a 

> 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