- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 12 May 2017 10:21:16 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Willy Tarreau <w@1wt.eu>, Kazuho Oku <kazuhooku@gmail.com>, Mark Nottingham <mnot@mnot.net>, Erik Nygren <erik@nygren.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Ponec, Miroslav" <mponec@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>
> Am 12.05.2017 um 07:38 schrieb Martin Thomson <martin.thomson@gmail.com>: > > On 12 May 2017 at 15:28, Willy Tarreau <w@1wt.eu> wrote: >> And we're back to the original point : if we do this for all requests, >> we're just doing 1-RTT 100% of the time in the end. > > Two reasons why it isn't, or might not be: > > 1.The suggestion was that you would identify a subset of requests that > get passed on. That might be GET, HEAD and OPTIONS if you want to be > conservative. I am more and more thinking that we need no safe-set definition. It seems that clients and servers will have specific ideas about what to send and what to accept in early data. What a client wants to send early, might not be what the server is willing to process right away. Servers can always chose to not enable early data at all, or, in case of doubt about the data, wait for the handshake to complete. At least in h2 it seems to be clear how to do that, is there a way for http/1.1 to do the same? Is there maybe a generic TLS1.3 way to do that? If we can define a way for TLS receivers to wait for the handshake, then there is no need to expect failure from early data, except servers not following this strategy or being reconfigured between sessions. Or? -Stefan > 2. The data has arrived in less than 1-RTT. That you don't act on it > later doesn't mean that you haven't at least saved on the time it > takes to move those bytes. The downside being that your handshake > completion now sits behind a longer line of bytes that are all subject > to loss and therefore head of line blocking.
Received on Friday, 12 May 2017 08:21:50 UTC