Subject: [quicwg/base-drafts] Provide better guidance about acknowledgments (#1126)

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Feb 2018 19:10:45 -0800

Tracking which header blocks are unacknowledged is a little tricky.  Each stream can have multiple blocks outstanding and each needs acknowledgment (in order).  An encoder needs to track the tuple of request identifier (which might also be a stream identifier) and which header block is referred to.  A server might send a large number of header blocks on the same stream if it sends PUSH_PROMISE frames.

If only the request identifier is used, then an acknowledgment for one header block might be mistaken as acknowledging a different header block that was sent on the same stream.

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

---

From: afrind <[email-masked]>
Date: Wed, 21 Feb 2018 09:49:06 -0800

The decoder has to process and acknowledge the header blocks on a given stream in order, so the encoder only need maintain a queue per stream of the outstanding header blocks.  Each ack on the stream is necessarily for the block at the head of the queue.

-- 
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/1126#issuecomment-367411177

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Feb 2018 15:38:38 -0800

Interesting, you maintain a queue for each stream.   I put the tracking on the header table entries...  If you track header blocks you have to follow the mapping from the header block to the table entry, which seemed like more work.

Yes, you don't need to signal any more than the stream/request identifier, but tracking is different.

-- 
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/1126#issuecomment-367515986

---

From: afrind <[email-masked]>
Date: Thu, 22 Feb 2018 17:47:09 +0000 (UTC)

The encoder doesn't actually need to maintain the header blocks themselves, but the set of table indexes which were referenced by that block.  Even if you tracked this per-header entry, I assume you could also have a queue of request identifiers per entry, and remove the first matching entry, but I worry about this approach taking more memory. 

The 'Safe evictions' section of the draft describes some of the approaches.  Do you think this is where we should add clarification?

-- 
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/1126#issuecomment-367762793

---

From: Mike Bishop <[email-masked]>
Date: Sun, 25 Feb 2018 14:59:14 +0000 (UTC)

I was using:

- Per-stream queue of lists of table indices
- Simple refcount on table entries
- When you get an ack, dequeue a list and decrement the refcount on each indicated table entry
- When a stream is reset, drain the queue and decrement all the refcounts

In order to facilitate this, I use an absolute index into the table internally.

-- 
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/1126#issuecomment-368316021

---

From: afrind <[email-masked]>
Date: Mon, 26 Feb 2018 17:01:52 +0000 (UTC)

I think I am doing something similar.  Should we add text to the draft indicating this is a possible or recommended approach?

-- 
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/1126#issuecomment-368572202

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Feb 2018 10:58:50 -0800

Yes, I think we need an outline of how an encoder could track the necessary state.  If an implementation comes up with something better (either simpler or more efficient), good on them.

-- 
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/1126#issuecomment-368610008