Subject: [quicwg/base-drafts] Integrate QCRAM (#1117)

From: Mike Bishop <[email-masked]>
Date: Sat, 17 Feb 2018 09:03:50 -0800

Fixes #228, at long last!

This does two major things, and then I think we're ready to iterate on any changes we'd like to make to QCRAM itself:

- Moves the "Changes to HTTP/QUIC" section from QCRAM and applies them to the HTTP/QUIC spec
- Removes the restriction that HPACK's table size is zero
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1117

-- Commit Summary --

  * Lift QCRAM frame changes into HTTP/QUIC
  * Remove HPACK0

-- File Changes --

    M draft-ietf-quic-http.md (91)
    M draft-ietf-quic-qcram.md (44)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1117.patch
https://github.com/quicwg/base-drafts/pull/1117.diff

-- 
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/pull/1117

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Feb 2018 19:21:22 -0800

martinthomson approved this pull request.

So as a copy-paste implementation of what is in the draft, this is fine.  As actual changes, these are not good for the reasons already stated.  I think that you should merge this then fix it.

> @@ -323,18 +344,9 @@ abort a response in progress as a result of receiving a solicited RST_STREAM.
 
 ### Header Compression
 
-HTTP/QUIC uses HPACK header compression as described in {{!RFC7541}}. HPACK was
-designed for HTTP/2 with the assumption of in-order delivery such as that
-provided by TCP. A sequence of encoded header blocks must arrive (and be
-decoded) at an endpoint in the same order in which they were encoded. This
-ensures that the dynamic state at the two endpoints remains in sync.
-
-QUIC streams provide in-order delivery of data sent on those streams, but there
-are no guarantees about order of delivery between streams. QUIC anticipates
-moving to a modified version of HPACK without this assumption.  In the meantime,
-by fixing the size of the dynamic table at zero, HPACK can be used in an
-unordered environment.
-
+HTTP/QUIC uses QCRAM header compression as described in [QCRAM], a variation of
+HPACK which allows the flexibility to avoid header-compression-induced HoL

head-of-line

-A HEADERS frame with any flags set MUST be treated as a connection error of type
-HTTP_MALFORMED_FRAME.
+BLOCKING (0x01):
+: Indicates the stream might need to wait for dependent headers before
+  processing.  If 0, the frame can be processed immediately upon receipt.

As I said in my review, this is completely unnecessary.  Though you might like to say that this is a port that it faithful to the current QCRAM draft, that's not a theology I think we need to subscribe to.

> @@ -905,6 +926,32 @@ using an Immediate Close (see {{QUIC-TRANSPORT}}).  An endpoint that completes a
 graceful shutdown SHOULD use the QUIC APPLICATION_CLOSE frame with the
 HTTP_NO_ERROR code.
 
+### HEADER_ACK {#frame-header-ack}
+
+The HEADER_ACK frame (type=0x8) is sent from the decoder to the encoder on the

"the decoder" and "the encoder" are not clear from context any more.  I think that you mean decoder of header blocks and encoder of header blocks, or some term you might want to devise.

> +might reference that block are vulnerable to HoL blocking, and to prevent
+eviction races.  See [QCRAM] for more details on the use of this information.
+
+The HEADER_ACK frame indicates the stream on which the header block was
+processed by encoding the Stream ID as a variable-length integer. The same
+Stream ID can be identified multiple times, as multiple header-containing blocks
+can be sent on a single stream in the case of intermediate responses, trailers,
+pushed requests, etc. as well as on the Control Streams.  Since header frames on
+each stream are received and processed in order, this gives the encoder precise
+feedback on which header blocks within a stream have been fully processed.
+
+~~~~~~~~~~
+  0   1   2   3   4   5   6   7
++---+---+---+---+---+---+---+---+
+|        Stream ID [i]          |
++---+---------------------------+

Weird formatting here.

> @@ -905,6 +926,32 @@ using an Immediate Close (see {{QUIC-TRANSPORT}}).  An endpoint that completes a
 graceful shutdown SHOULD use the QUIC APPLICATION_CLOSE frame with the
 HTTP_NO_ERROR code.
 
+### HEADER_ACK {#frame-header-ack}
+
+The HEADER_ACK frame (type=0x8) is sent from the decoder to the encoder on the
+Control Stream when the decoder has fully processed a header block.  It is used
+by the encoder to determine whether subsequent indexed representations that
+might reference that block are vulnerable to HoL blocking, and to prevent

head-of-line

-- 
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/pull/1117#pullrequestreview-97433996

---

From: afrind <[email-masked]>
Date: Tue, 20 Feb 2018 09:22:39 -0800

This looks OK to me.

-- 
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/pull/1117#issuecomment-367051869

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Feb 2018 21:45:17 +0000 (UTC)

@MikeBishop pushed 1 commit.

479d6e8  HoL => head-of-line

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1117/files/39eae80ba48bea0d10f5ef637627b63a1c0123cf..479d6e860e264d010cc9f53ae8b263abce324776

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Feb 2018 21:46:29 +0000 (UTC)

MikeBishop commented on this pull request.

I see this in the same vein as "merge, then fix" -- even if we know the drafts need to change, I want whatever's in the repo at a given commit to be coherent.  When we change QCRAM to not use this, it'll disappear from HTTP, and hopefully quickly.

However, a PR to remove it from both would be very welcome.  ;-)

-- 
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/pull/1117#discussion_r169470308

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Feb 2018 21:52:07 +0000 (UTC)

@MikeBishop pushed 2 commits.

b82b83a  encoder/decoder context
4dc8710  Figure formatting

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1117/files/479d6e860e264d010cc9f53ae8b263abce324776..4dc87105bcaf3fc7054ab88016751eca4bae0cb9

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Feb 2018 21:53:31 +0000 (UTC)

Merged #1117.

-- 
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/pull/1117#event-1483453851