Re: 0-RTT Design for HTTP/2

> On 20 Dec 2020, at 22:43, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Sun, Dec 20, 2020, at 04:18, Willy Tarreau wrote:
> 
>> I see that Cory mentioned the fact that most implementations do not see
>> the TLS layer, I can confirm this. For example in haproxy, h2 works on
>> top of a streaming transport protocol. It can be plain or TLS on top of
>> TCP, UNIX or socketpairs, we don't care. Early data, if any, are retrieved
>> by the TLS layer and are prepended in front of the other data (more or
>> less some details I don't remember regarding the necessary controls to
>> figure whether or not some early data were involved for the request).
>> 
>> Anything more complicated will likely become a showstopper I'm afraid.
> 
> I don't think that you need anything other than an API that allows you to determine whether early data was accepted.
> 
> Ideally, you also have a means of saving data to the session ticket and getting that data back when the connection is resumed.  Then you can save the settings in the ticket and then you don't have to remember on your own. A simple boolean doesn't give you a lot of flexibility in terms of how you deploy this.  With just a boolean you have to commit to discarding session tickets every time your server configuration changes.

With this kind of API to the TLS layer in mind it’s not clear that this proposal is any simpler for a server stack than ALPS: indeed, it might be harder. ALPS requires that implementations define an interface to send and receive out-of-band settings, but that interface is relatively straightforward. Interaction with session tickets is at the very least as complex (an out-of-band system for setting and retrieving settings), but the integration is vastly more complex.

I suspect it also behaves poorly in multi-host configurations in a way ALPS does not.

Neither of these proposals makes me very excited, but I think on balance ALPS is simpler.

Received on Tuesday, 22 December 2020 08:34:18 UTC