Re: 0-RTT Design for HTTP/2

[Martin Thomson <[e-mail]>]

On Sun, Dec 20, 2020, at 06:36, Ian Swett wrote:
> If I only had to send the SETTING client to server, I think that might 
> be deployable in the near future, though Chrome would have to run more 
> widespread tests.  I'm actually more concerned about the fact that the 
> server has to send the SETTING(which makes complete sense, given what 
> you're trying to accomplish).  It's impractical to wait for receipt of 
> the client SETTING before sending the server one, and the client 
> ecosystem is much slower to upgrade, unfortunately.

My original write-up only had the server send the setting.  It certainly works that way.  You get most of the functionality.

If the client says nothing, the server can't condition its treatment on an indication of support from the client.  The consequence being that the server can't rely on the client respecting lower limits.  That's not a big loss though; even fairly low limits would be hard to exceed in the limited space available, either due to max_early_data or CWND limits.

> Given this, ALPS looks better from a deployability perspective.  To my 
> knowledge, there are no known issues deploying new TLS 1.3 extensions.  
> Given the lack of interest in a new h2 ALPN, I'm suggesting ALPS 
> include a GREASE recommendation, so if one deploys ALPS, it's also an 
> indication it's a fully compliant h2 implementation.

I suspect that that is not going to be an easy stipulation.  As others have observed, people update their TLS stacks independent of their h2 implementation.