Subject: ack for insertion in QPACK

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 25 Jan 2017 14:23:05 +0900 (JST)

Hi,

What will happen if we change the currect QPACK as follows:

- Insertions also require acks.
- An encoder can use acked-indces only.
- If a non-acked entry exists for a name-value, the encoder
  encodes the entire of name-value without using its index.

Does this make QPACK HoL-free?

--Kazu

---

From: Patrick McManus <[email-masked]>
Date: Wed, 25 Jan 2017 14:32:51 +0900

certainly an implementation could choose your algorithm.. but a primary use
case (and benefit) of HPACK is sending O(100) requests in the first round
trip - and that scheme would defeat that (via cwnd).. requests tend to come
in batches and removing the redundancy in the batch without rtt is a useful
property.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 25 Jan 2017 09:07:21 +0000

That’s essentially what Buck’s proposal boils down to, I think – you can insert, but you can’t reference until you know it’s been seen.  A previous version of QPACK also had acks on inserts, but that meant double the ack-handling logic.  (And I didn’t block references before the ack, since that’s something an encoder can choose to do or not, trading off lack-of-HOLB versus compression efficiency.)

From: QUIC [mailto:[email-masked]] On Behalf Of Patrick McManus
Sent: Tuesday, January 24, 2017 9:33 PM
To: Kazu Yamamoto <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: ack for insertion in QPACK

certainly an implementation could choose your algorithm.. but a primary use case (and benefit) of HPACK is sending O(100) requests in the first round trip - and that scheme would defeat that (via cwnd).. requests tend to come in batches and removing the redundancy in the batch without rtt is a useful property.

On Wed, Jan 25, 2017 at 2:23 PM, Kazu Yamamoto <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

--Kazu

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 26 Jan 2017 03:07:11 +0000

How about this algorithm?

=== Changes to HTTP App ===

Open a single stream for each GET/POST/HEAD/… (client stream) or PUSH (server stream).  No separation for headers and body.

Benefits: simplification of HTTP model (just one stream) and no need to read unneeded headers (HTTP app can just reset the streams it does not need).

=== Changes to QPACK subsystem ===

Instead of tracking use count per dynamic table index, QPACK encoder is to track streams that used this index.
In particular, track two bitmaps per index:

·         streams that used the index only in the initial headers (initial_streams), and

·         streams that used the index in trailer headers (and possibly in the initial streams): (trailer_streams)
Periodically, clear bits of from the bitmaps as streams are closed.

When a QPACK encoder wishes to DELETE a stream, it sends a Delete_Request(index, initial_streams, trailer_streams) on the Control Channel (3).

The QPACK decoder (receiver of this Delete_Request) will execute the “delete” and send DeleteAck(index) to the Control Channel (3), when:

·         All initial_streams have read their initial headers (or reset before that), and

·         All trailer_streams have closed (i.e. read their trailer headers or reset before that).

Upon the receipt of the DeleteAck message, QPACK encoder is free to reuse the index.

-          Igor

From: Mike Bishop [mailto:[email-masked]]
Sent: Wednesday, January 25, 2017 6:07 PM
To: Patrick McManus <[email-masked]>; Kazu Yamamoto <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: RE: ack for insertion in QPACK

From: QUIC [mailto:[email-masked]] On Behalf Of Patrick McManus
Sent: Tuesday, January 24, 2017 9:33 PM
To: Kazu Yamamoto <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: ack for insertion in QPACK

--Kazu