Subject: [quicwg/base-drafts] HPACK relies on in-order delivery (#228)

From: Mike Bishop <[email-masked]>
Date: Tue, 24 Jan 2017 21:15:46 -0800

QUIC doesn't make order guarantees between streams.  The options on the table currently are:

- Current (-01) draft puts a sequence number in the frames; HPACK data MUST be handled in order, and will HOL-block.  HPACK is exactly the same as HTTP/2.
- Buck's proposal (draft forthcoming) puts two sequence numbers in the frames and modifies the HPACK encoder to prevent blocking references.  Partially-received HPACK frames must block until fully received.  The new encoder could also be used in HTTP/2, but would require changes to existing code.
- [QPACK](https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack) modifies HPACK to be order-resilient and permit partial frames to be processed, but breaks from the HPACK encoding enough that you'd have at least some separate code paths.

Also agreed to put a "hard-hat warning" in this section of the HTTP draft, to warn readers this is still work-in-progress.

-- 
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/228

---

From: Mike Bishop <[email-masked]>
Date: Wed, 25 Jan 2017 17:23:13 -0800

There appears to be a hard-hat warning already present.

Per discussion during the lunch break yesterday, Buck and I concluded that all schemes on the table achieve consistency if we can guarantee the following things (I'm not certain we can):

- The HTTP layer will never RST a message control stream
- The QUIC layer will never RST a message control stream with any error code other than REFUSED (i.e. guarantee that no frame was delivered to HTTP)
- The HTTP layer will *always* replay *the same HPACK frame* on a different stream if a REFUSED is encountered **or** the HTTP layer can roll back all effects of the frame when a REFUSED stream is encountered.

Note that the last is very different than the semantics of REFUSED in HTTP/2, where the request MAY be retried, but the same original headers will be recompressed with the state of the table at the time of the retry.

-- 
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/228#issuecomment-275284374

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jan 2017 17:55:18 -0800

That last requirement is horrific.  It essentially means that you can't commit any change to the header table without the ability to roll it back.  Maybe we can take a good hard look at stream refusal and whether that could be moved to the HTTP layer somehow.

-- 
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/228#issuecomment-275289252