Subject: HPACK and Header sequence #s

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Jan 2017 22:07:33 -0800

Subject: QUIC and HTTP headers

S 4.2.1 of the HTTP draft says:

   QUIC streams provide in-order delivery of data sent on those streams,
   but there are no guarantees about order of delivery between streams.
   To achieve in-order delivery of HEADERS frames in QUIC, the HPACK-
   bearing frames contain a counter which can be used to ensure in-order
   processing.  Data (request/response bodies) which arrive out of order
   are buffered until the corresponding HEADERS arrive.

   This does introduce head-of-line blocking: if the packet containing
   HEADERS for stream N is lost or reordered then the HEADERS for stream
   N+4 cannot be processed until it has been retransmitted successfully,
   even though the HEADERS for stream N+4 may have arrived.

As I understand it, you are (effectively) requiring a single stream of
data for all the headers. It's not clear to me why it's useful in this
case to have the headers on distinct streams from each other as this
just seems like it introduces another opportunity for HOL blocking
that is harder to fix at the QUIC transport layer because it requires
a kind of smarts that is different from that to reduce HOL blocking
between packets on the same stream unless the transport either looks
into the frames or follows some heuristic about first in
first out...

-Ekr

---

From: Alan Frindell <[email-masked]>
Date: Mon, 23 Jan 2017 07:17:00 +0000

>    into the frames or follows some heuristic about first in

I agree.  If QUIC is going to use HPACK, I would prefer all frames containing header data to be on the connection control stream.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 23 Jan 2017 04:00:01 -0500

the assumption is we will move towards something like qpack
https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack-01

On Mon, Jan 23, 2017 at 2:17 AM, Alan Frindell <[email-masked]> wrote:

> I agree.  If QUIC is going to use HPACK, I would prefer all frames
> containing header data to be on the connection control stream.
>
>
>
>
>
>
>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Jan 2017 17:25:49 +0000

Yes – the sequence numbers are a stopgap to keep HPACK working while we transition away from -00’s muxed-connection-on-stream-3.

Sent from my Windows 10 phone

From: Patrick McManus<mailto:[email-masked]>
Sent: Monday, January 23, 2017 1:00 AM
To: Alan Frindell<mailto:[email-masked]>
Cc: Eric Rescorla<mailto:[email-masked]>; IETF QUIC WG<mailto:[email-masked]>
Subject: Re: HPACK and Header sequence #s

the assumption is we will move towards something like qpack https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack-01