Re: draft-asveren-dispatch-http-overload

[Mark Nottingham <[e-mail]>]

Hi Tolga,

My .02 - 

> On 7 May 2018, at 5:46 am, Asveren, Tolga <[e-mail]> wrote:
> 
> To regroup:
>  
> i- Is there any existing mechanism (503 with Retry-After does not provide a satisfactory solution) which would address the server/application overload problem? AFAICT the answer is “No” (but I am ready to be corrected)

I'm not sure that that 503+Retry-After is inadequate. The text that you reference in 5390 seems to suggest that in SIP, Retry-After "allows a server to tell an upstream element to stop sending traffic for a period of time," thereby causing the problems you refer to. In HTTP, this is not the case; the scope of applicability for Retry-After is only the request that it's associated with. From <https://httpwg.org/specs/rfc7231.html#status.503>:

"The server MAY send a Retry-After header field (Section 7.1.3) to suggest an appropriate amount of time for the client to wait before retrying the request."

So, the server can be selective about the requests it defers, giving a more fine-grained control mechanism. It could be that the semantics of Retry-After might need some refinement (e.g., in an applicability statement for a particular use case, or a protocol extension that adds more information), but it seems like its definition in SIP and HTTP diverge enough to justify caution in making assumptions.

All that said -- what would really help would be a set of use cases that explain how you expect this to be used in HTTP; it's difficult to design or evaluate an extension without them.

Cheers,


>  
> ii- (Assuming that “No” holds good for i-) I am planning to update the draft with explanations about:
> 	• Why 503 with Retry-After is inadequate
> 	• That the intent is not to prevent attacks from malicious users
> 	• The scope is server/application overload
>  
>  
> Any other suggestions/feedback are welcome.
>  
> Thanks,
> Tolga
>  
> From: Asveren, Tolga 
> Sent: Tuesday, May 1, 2018 7:00 AM
> To: 'Julian Reschke' <[e-mail]>; Martin Thomson <[e-mail]>
> Cc: [e-mail]
> Subject: RE: draft-asveren-dispatch-http-overload
>  
> Agreed that it could be server or the application or the resource (at least theoretically and maybe also in practice). This draft is about server/application overload cases. For real-time application use, these need to be addresses in a satisfactory way for enabling better response times once they happen IMHO. 
>  
> So, maybe a new parameter indicating the nature of the overload could be useful. Any thoughts on that?
>  
> And my apologies for not being clear about the terminology causing confusion.
>  
> Thanks,
> Tolga
>  
> From: Julian Reschke <[e-mail]> 
> Sent: Tuesday, May 1, 2018 6:19 AM
> To: Asveren, Tolga <[e-mail]>; Martin Thomson <[e-mail]>
> Cc: [e-mail]
> Subject: Re: draft-asveren-dispatch-http-overload
>  
> NOTICE: This email was received from an EXTERNAL sender
> 
> On 2018-05-01 11:41, Asveren, Tolga wrote:
> > I certainly will include these explanation, and more about a few other 
> > issues, in the next version of the draft. My initial goal was to get 
> > some initial idea/feedback from other folks.
> > 
> > Regarding interpretation of 503: I think it is quite clear, at least 
> > IMHO, based on RFC2616 that it indicates the status of the server in 
> > general not just for a single request:
> > 
> > *10.5.4 503 Service Unavailable*
> > 
> >    The server is currently unable to handle the request due to a
> > 
> >    temporary overloading or maintenance of the server. The implication
> > 
> >    is that this is a temporary condition which will be alleviated after
> > 
> >    some delay. If known, the length of the delay MAY be indicated in a
> > 
> >    Retry-After header. If no Retry-After is given, the client SHOULD
> > 
> >    handle the response as it would for a 500 response.
> > 
> > I also never saw it being interpreted/used on “per request” basis in 
> > practice.
> > ...
> 
> RFC 2616 is irrelevant. RFC 7231 says:
> 
> > The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field (Section 7.1.3) to suggest an appropriate amount of time for the client to wait before retrying the request.
> > 
> > Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection.
> 
> That IMHO leaves the nature of the overload open; it could be the server 
> itself, a specific service, or just one resource.
> 
> Best regards, Julian

--
Mark Nottingham   https://www.mnot.net/