[EMAIL PROTECTED] wrote:
>> 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.
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).
[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 ..."
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.
> 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.
Yes, I certainly agree.
>> 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?
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.
> 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.
I fully agree - and maybe there IS a case for a new response code.
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.
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
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
