Subject: [quicwg/base-drafts] Move QPACK control instructions to dedicated streams (#1238)

From: afrind <[email-masked]>
Date: Mon, 19 Mar 2018 06:28:17 -0700

1. Give QPACK encoders and decoders their own unidirectional streams (hardcoded to 6,7,10,11 for now)
2. Define simple framing for encoder stream
3. Move HEADER_ACK from HTTP over QUIC frame to QPACK instruction
4. Introduce Table State Synchronize instruction

Fixes #1120 and #1121
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Move QPACK control instructions to dedicated streams

-- File Changes --

    M draft-ietf-quic-http.md (47)
    M draft-ietf-quic-qpack.md (76)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1238.patch
https://github.com/quicwg/base-drafts/pull/1238.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/1238

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Mar 2018 14:08:33 +0000 (UTC)

Rather than hard-code, I would *greatly* prefer that this used a stream header.

-- 
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/1238#issuecomment-374224155

---

From: afrind <[email-masked]>
Date: Mon, 19 Mar 2018 16:06:37 -0700

Can you explain the basis of your preference?  A client has no other unidirectional streams defined in HTTP over QUIC, and a server must process/acknowledge at least one header block before opening any push streams.  It is further very unlikely the server would open a push stream without first encoding a header block that inserts at least one header to the dynamic table.  So in practice it's going to work out to these streams anyways.

How do you see the encode/decode streams as materially different from the control stream, which is hardcoded?

Aside: it occurs to me that a server could compress a PUSH_PROMISE a lot better if it compressed against the client's table, which of course doesn't work ;)

-- 
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/1238#issuecomment-374415888

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Mar 2018 10:39:56 +0000 (UTC)

Looks reasonable.  The source of the stream header is, I think, the discussion in #910 about eliminating references to particular stream IDs in the application layer.  You can make a QUIC interface that depends only on receiving a stream and reading the bytes to figure out what to do with it, rather than needing to open / listen on *particular* streams by ID.

I think that model is important for things that could crop up mid-connection, but I don't feel as strongly about the header for streams that are unique and persistent.

-- 
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/1238#issuecomment-374550793

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Mar 2018 11:26:14 +0000 (UTC)

BTW, I think you might have meant #1122 rather than #1120.  #1120 is another PR that has already been merged.

-- 
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/1238#issuecomment-374563515