Re: [quicwg/base-drafts] SETTINGS synchronization (#75)

[Mike Bishop <[e-mail]>]

I think I have a solution, but it's a little ugly.  Upon receipt of a SETTINGS frame, every stream will be either already closed, open, or still idle.  The sender of the SETTINGS frame needs to know, for each stream, which state applied so it can enforce the new settings appropriately.

If the receiver sends:

- On stream 3, a SETTINGS_ACK frame containing the highest open stream number in each direction (tells the sender which streams weren't open yet and have the new settings from the start)
- On every open (control) stream, an empty SETTINGS_ACK frame as a time marker

The sender of the SETTINGS frame can then require that it receive the master ACK *and* that every stream below the highest-open either closes or ACKs before the timeout expires. This is resilient to reordering between the streams, but will unfortunately require spitting out as many frames as you have open streams, making the request for an ACK potentially expensive.

> **Corner case:** If the frames opening streams have been reordered, the receiver of the SETTINGS frame might find itself required to ACK on a stream that, from its perspective, is still idle.  Permit it to open a stream in the "wrong direction," or does it need to wait until the frame has been received?  It can anticipate that the frame is already in flight, so this wouldn't appear to be an ordering violation to the other peer.

On the plus side, #80 makes the ACK optional (i.e. sender-requested) rather than requiring it for every SETTINGS frame, so we're hopefully going to do this less often.  Only a few settings actually require a timing synchronization point (mostly flow control, which is gone, and HPACK).

More elegant solutions eagerly solicited.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/75#issuecomment-266508254