Re: 0-RTT Design for HTTP/2

[David Schinazi <[e-mail]>]

Hi,

If there's energy in the community to improve HTTP/2 SETTINGS,
I would personally prefer to direct that energy at also solving the
"not having SETTINGS when sending the first request" problem.
Once potential solution is ALPS [1]. Would it make sense to join
these two efforts to ensure we fix SETTINGS for good?

David

[1] https://tools.ietf.org/html/draft-vvv-tls-alps

On Wed, Dec 16, 2020 at 4:31 AM Ian Swett <[e-mail]> wrote:

> Thanks for writing this up.  I need to talk with others before being sure
> this is something we'd be interested in, but it seems likely.
>
> Before we get to that, one Q on deployability: Does the working group
> think enough of the ecosystem can handle this new EARLY_DATA_SETTINGS
> setting?  If no one sends it, even if they support the functionality, it
> sort of defeats the purpose.
>
> Ian
>
>
>
> On Wed, Dec 16, 2020 at 5:36 AM Cory Benfield <[e-mail]> wrote:
>
>> On Wed, 16 Dec 2020 at 07:15, Martin Thomson <[e-mail]> wrote:
>> >
>> > As part of our adoption call for HTTP/2 (reprise), I opened
>> https://github.com/httpwg/http2-spec/issues/781 regarding the use of TLS
>> early data.
>> >
>> > I thought that it might be worth the time to go through the exercise of
>> defining an extension to h2 that enabled saving of settings across
>> connections.  Here it is:
>> >
>> >
>> https://martinthomson.github.io/h2-0rtt/draft-thomson-httpbis-h2-0rtt.html
>> >
>> > For those who prefer text:
>> https://tools.ietf.org/html/draft-thomson-httpbis-h2-0rtt-00
>> >
>> > Though this is conceptually simple (indicate 1 if you are prepared to
>> remember settings), there are enough fiddly details here that I'm now
>> unsure whether it is worthwhile trying to roll into our revision of HTTP/2.
>>
>> I am somewhat nervous here about how many servers will implement this.
>>
>> Typical OSS server implementations have a somewhat arms-length
>> relationship with their TLS stack. This tends to mean they don't
>> actually know exactly when new session ticket messages were sent.
>> While this is not a hard limitation (OpenSSL has the requisite
>> functions) it's the kind of barrier to entry that could be quite
>> awkward. This may also lead to limitations in how many HTTP/2 stacks
>> go through the effort of implementing the extension.
>>
>> With that said, I'm sure that CDNs and browsers would, and that may be
>> enough.
>>
>> >
>> > I'm interested in what people think about this.  One of the major
>> criticisms of the current arrangement is the time it takes to learn that an
>> extension is available and this could help with that.
>> >
>> > Cheers,
>> > Martin
>> >
>>
>>