Subject: HTTP/QUIC: Two SETTINGS PRs

From: Mike Bishop <[email-masked]>
Date: Wed, 14 Dec 2016 20:20:36 +0000

I have two open pull requests I'd like to draw folks' attention to, in hopes of getting more review than just Martin - thoughtful though his comments always are.

https://github.com/quicwg/base-drafts/pull/80 merges the HTTP WG draft (full disclosure:  by me) creating a SETTINGS-frame alternative called EXTENDED_SETTINGS.  In this pull request, the SETTINGS frame is fully replaced by the proposed EXTENDED_SETTINGS functionality and existing settings values are redefined into the new space.  The notable differences are:

*       Rather than being a fixed 32-bit length, settings are TLV records with interpretation defined custom to the setting.  Includes option to declare the value as zero-length and use an embedded flag as a Boolean value, since many settings are strictly yes/no.  Reduces length of a setting in most cases, and permits greater flexibility if a setting needs to communicate something more complex (e.g. a list of values).

*       Ack is requested or not on a per-SETTINGS-frame basis, since many settings don't actually need acknowledgement.  If an ACK is requested, the ACK tells the sender which settings in the frame were recognized and which were unknown/ignored.  That can potentially do away with bidirectional settings that merely acknowledge mutual support for an extension - client can set the value to "true" and requests ACK, server indicates comprehension, done.  (Note that while this is useful information, it's also a fingerprinting vector we should note in Security Considerations.)
This pull request explicitly doesn't solve the synchronization problem that SETTINGS has with regard to QUIC, which is that you can't tell when in each stream the new settings take effect, since there's no intra-stream ordering in QUIC.  (Tracked by https://github.com/quicwg/base-drafts/issues/75.)

https://github.com/quicwg/base-drafts/pull/84 builds on the previous request and attempts to address that problem, though the same technique could be applied to an HTTP/2-style SETTINGS frame.  It requires, not a single SETTINGS_ACK, but a collection of them:

*       One on stream 3 which indicates the highest non-idle locally-initiated and peer-initiated stream IDs

*       One on every message control stream that was open when the SETTINGS frame was received.
With the first, the sender of the SETTINGS knows all streams that have the new settings from the start; every other stream must either close (still under the old settings) or carry a SETTINGS_ACK frame (accepting the new settings) within the timeout.  There's a race condition where a stream's opening frame is still in flight when the SETTINGS is received, and I attempt to address that as well, but Martin's comments suggest it might not be fully covered yet.

Anyone see things here to panic about, or should I merge them?

---

From: Patrick McManus <[email-masked]>
Date: Thu, 15 Dec 2016 16:49:50 -0500

> Anyone see things here to panic about, or should I merge them?

ship it! as you said, this is basically a "hold for update of 7540" item..

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 16 Dec 2016 09:50:55 +0100

> Am 14.12.2016 um 21:20 schrieb Mike Bishop <[email-masked]>:
> 
> I have two open pull requests I’d like to draw folks’ attention to, in hopes of getting more review than just Martin – thoughtful though his comments always are.
>  
> ·       Rather than being a fixed 32-bit length, settings are TLV records with interpretation defined custom to the setting.  Includes option to declare the value as zero-length and use an embedded flag as a Boolean value, since many settings are strictly yes/no.  Reduces length of a setting in most cases, and permits greater flexibility if a setting needs to communicate something more complex (e.g. a list of values).
> ·       Ack is requested or not on a per-SETTINGS-frame basis, since many settings don’t actually need acknowledgement.  If an ACK is requested, the ACK tells the sender which settings in the frame were recognized and which were unknown/ignored.  That can potentially do away with bidirectional settings that merely acknowledge mutual support for an extension – client can set the value to “true” and requests ACK, server indicates comprehension, done.  (Note that while this is useful information, it’s also a fingerprinting vector we should note in Security Considerations.)
> This pull request explicitly doesn’t solve the synchronization problem that SETTINGS has with regard to QUIC, which is that you can’t tell when in each stream the new settings take effect, since there’s no intra-stream ordering in QUIC.  (Tracked by https://github.com/quicwg/base-drafts/issues/75.)

> ·       One on stream 3 which indicates the highest non-idle locally-initiated and peer-initiated stream IDs
> ·       One on every message control stream that was open when the SETTINGS frame was received.
> With the first, the sender of the SETTINGS knows all streams that have the new settings from the start; every other stream must either close (still under the old settings) or carry a SETTINGS_ACK frame (accepting the new settings) within the timeout.  There’s a race condition where a stream’s opening frame is still in flight when the SETTINGS is received, and I attempt to address that as well, but Martin’s comments suggest it might not be fully covered yet.
>  

+1, on both from me.