- From: Asveren, Tolga <tasveren@rbbn.com>
- Date: Mon, 14 May 2018 09:51:44 +0000
- To: Mark Nottingham <mnot@mnot.net>
- CC: "Julian F. Reschke" <julian.reschke@gmx.de>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CY4PR03MB31606580E9F9A8BA7DA981DEA59C0@CY4PR03MB3160.namprd03.prod.outlook.com>
Hi Mark,
Thanks for the reply.
Quoting the full text from RFC7231 Section 6.6.3:
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<https://tools.ietf.org/html/rfc7231#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.
I agree that 503 with Retry-After may pertain to a specific request, to the server overload or to the application overload condition (actually the last two are probably the same as far as their impact/interpretation on the client is concerned IMHO). The problem I have is for server/application overload case. This is an issue mainly for environments where the client is not an end-device, e.g. browser, but a network entity. The relationship between a Session Processing Entity and Signature Server is an example of that (and there are many more in practice and it just keeps growing) :
+----------------+
| |
| Signature |
| Server |
| |
| |
+----------------+
^ |
| |
POST 200
(JSON body (JSON body
with claims) with signature
X | generated based on claims
| and private key)
X | |
| |
X Many end-devices | V
generating many +----------------+
X new session requests | |
| Session |
X -new session-->| Processing |--new session-->
request | Entity |request with signature
X | |
+----------------+
Why does the HTTP client being a network entity matter from overload perspective? The answer is the volume of traffic exchanged between client and server. In such a case, the need is not for a “per request” indicator but for one which would pertain to all subsequent requests to be sent to the server.
I think what you state as “ a protocol extension that adds more information” is what I am trying to achieve with this draft.
Thanks,
Tolga
From: Mark Nottingham <mnot@mnot.net>
Sent: Monday, May 14, 2018 3:36 AM
To: Asveren, Tolga <tasveren@rbbn.com>
Cc: Julian F. Reschke <julian.reschke@gmx.de>; Martin Thomson <martin.thomson@gmail.com>; ietf-http-wg@w3.org
Subject: Re: draft-asveren-dispatch-http-overload
________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________
Hi Tolga,
My .02 -
> On 7 May 2018, at 5:46 am, Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>> 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' <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>>; Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
> Cc: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>
> 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 <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>>
> Sent: Tuesday, May 1, 2018 6:19 AM
> To: Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>>; Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
> Cc: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>
> 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/
Received on Monday, 14 May 2018 09:52:16 UTC