SETTINGS synchronization

[MikeBishop]

In HTTP/2, SETTINGS provokes an empty SETTINGS frame with the ACK flag sent. In the EXTENDED_SETTINGS proposal, there's a separately-defined SETTINGS_ACK frame. Either way, there's a way to know when changes have been applied.

If we need this in QUIC, with no defined ordering between bytes on different streams, we would need to ACK on every still-open stream. (Ick.) But of course, we also can't know which streams were already closed or not yet open at the time the SETTINGS frame was received, so we can't enforce that on the receiver.

Do we need a SETTINGS epoch in every HTTP frame? (Ick.) Or simplify and say that SETTINGS just aren't ACKed over QUIC?

[MikeBishop]

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.

[MikeBishop]

Closed by #84.

[mnot]

To be clear - this has been superceded by #181. SETTINGS_ACK is no more.