SETTINGS synchronization

At IETF 103, we talked about the current state of SETTINGS in HTTP/3.  HTTP/2 has a total ordering among frames, so things that you send after declaring your settings are definitively interpreted under the new regime.  With SETTINGS ACK, you can know at what point in your peer's (totally-ordered) return data your settings took effect.  In QUIC, this doesn't work because there is no total order.

We currently require peers to wait for the other side's settings to be known before sending data.  That provides similar certainty that what you receive is based on your declared settings, but potentially induces head-of-line blocking.  There was discussion on issue #1846<https://github.com/quicwg/base-drafts/issues/1846> on ways to either reduce the head-of-line blocking here or take advantage of it to get full offer-select semantics.

I posted a PR<https://github.com/quicwg/base-drafts/pull/2038> last week that attempts to resolve this.  The basic principles are:

  *   The default value of each setting should always be acceptable to the remote endpoint (i.e. minimal)
  *   Only send what you know the peer is willing to consume

This results in each setting having a default value and that value being used until SETTINGS is received, as in HTTP/2.  Unlike in HTTP/2, we've previously decided that there are no reductions, so the default has to be the minimum for all settings.  Each side can either start sending immediately, but assuming a severely constrained peer; or wait for SETTINGS to arrive (as previously required) to discover how it might act more efficiently.  In other words, it's now a local decision whether to block or not, rather than a protocol requirement.

Absent objections, I intend to merge this soon, but I wanted to flag it for the list since we had the discussion in Bangkok.

Thanks!
-Mike