RE: 0-RTT Design for HTTP/2

[Mike Bishop <[e-mail]>]

Thanks for working on this, Martin.  A few thoughts:

*	There initially seems to be limited value in the client sending this
setting:

*	In a 1-RTT connection, the server does nothing with the client's
value - it has committed to store settings in the tickets and does so once
it has sent the setting.  The only value appears to be that it might disable
the feature and somewhat reduce ticket sizes if the client doesn't support
the feature.
*	In a 0-RTT connection, the server likely can't condition acceptance
of Early Data on the client sending this commitment, since the commitment is
itself contained in the Early Data.  Servers decide whether to accept or not
based purely on the ticket and their own state.

You later discuss that a server might not offer Early Data support in
tickets at all to clients which don't send the setting; this is a reasonable
argument and probably worth moving earlier.

*	The spec doesn't directly address this, but it carries the
implication that the client might prefer an older ticket where the server
committed to remembering values over a later ticket where the server does
not so commit.  That's worth calling out, that the TLS stack will need a way
not only to store settings alongside tickets, but a way to establish a
preference between old and new tickets on a connection.
*	4.1:  I presume you mean settings, instead of extensions
*	This is missing discussion of the interaction with the SETTINGS
frame(s) which arrive subsequently.  A few things that need to be covered,
coming from hashing this out in both HTTP/3 and QUIC TPs:

*	If a setting has a remembered non-default value, but is not
mentioned in the server's SETTINGS frame, what happens when the first
SETTINGS frame is received?
*	What settings apply when the client has received the server's
Finished, but has not yet received the server's SETTINGS frame?
*	Is the client required to remember settings values that it does not
support?  How does this interact with having added support for those
settings between the old session and the new one?

 

I have some thoughts on the relationship between this draft and ALPS, but I
think I need to re-read ALPS again before I go into that.

 

-----Original Message-----
From: Martin Thomson <[e-mail]> 
Sent: Wednesday, December 16, 2020 2:12 AM
To: [e-mail]
Subject: 0-RTT Design for HTTP/2

 

As part of our adoption call for HTTP/2 (reprise), I opened
<https://github.com/httpwg/http2-spec/issues/781>
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>
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>
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'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