- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 8 Aug 2017 07:41:00 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: David Benjamin <davidben@chromium.org>, Benjamin Kaduk <bkaduk@akamai.com>, Victor Vasiliev <vasilvv@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, draft-thomson-http-replay@ietf.org
On Tue, Aug 08, 2017 at 02:39:13PM +1000, Martin Thomson wrote: > On 8 August 2017 at 08:07, David Benjamin <davidben@chromium.org> wrote: > > If the server is really overloaded, it can send HTTP 503. But I'm guessing > > 503 triggers a sharper client back-off than you like in this scenario. > > Perhaps you're only sort-of-overloaded and retrying at 1-RTT is fine? As you > > say, a sort-of-overloaded server could reject 0-RTT at the TLS level > > instead. Though perhaps you have GET /cheap_thing that you are still willing > > to respond to. > > I think that the advice we give there is that if you *might* send a > different response from different nodes, then 503 isn't right and 4NN > (Too Early) is better, even if it means less backing off. > > You could probably make a case that returning 503 is consistent - it > depends on server state that is independent of whether the request is > replayed. With that said, I think we could suggest that a client should possibly stop using 0-RTT for a while with a server exhibiting 5xx responses or connection resets, because this means the server is unreliable or possibly overloaded and 0-RTT may participate to increase this load if the server has to respond 4NN a lot (ie it is required to process twice the amount of requests). Willy
Received on Tuesday, 8 August 2017 05:41:37 UTC