Subject: [quicwg/base-drafts] Tracking of header blocks for reset streams (#1371)

From: Martin Thomson <[email-masked]>
Date: Tue, 22 May 2018 06:22:58 -0700

There isn't much advice in hq or qpack about tracking of header blocks, and it's one of the hardest parts to implement.  The nastiest bit is dealing with reset streams.  If a stream is reset, then all the header blocks are no longer blocked, and none of the table entries they reference need to be tracked.

However..., tracking can only stop once the peer has received the reset, otherwise the peer might read the pre-reset data and block, increasing the number of blocked streams.  So we need to know when the peer stops caring, either because they sent STOP_SENDING or received RST_STREAM.  But we don't have a signal for this.  The header block acknowledgment only applies to a single header block, not the entire stream.

It's also a timely reminder that APIs need to surface when an inbound stream is stopped (STOP_SENDING) or reset (RST_STREAM).  In either case, an HTTP receiver would need to send whatever signal we're missing here.

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

---

From: afrind <[email-masked]>
Date: Tue, 22 May 2018 10:04:41 -0700

Yes I raised this earlier (which @MikeBishop filed as #1176).  That got closed by making the consequence of the race condition a stream error rather than a connection error, since the race is likely to be quite rare.  eg: the encoder can reset all its state when it sends the RST_STREAM, rather than when it is acknowledged.  I think when we added the setting for number of blocked streams we re-introduced the connection level error.  I wasn't really thrilled with that solution but I'm not thrilled by adding an application level stream-reset-ack either. 

Assuming we have to do this, do you think this should be an HTTP frame sent on the control stream or a QPACK instruction sent on the decoder 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/1371#issuecomment-391067065

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 May 2018 19:12:22 +0000 (UTC)

When I'd sketched it out before, I was envisioning a flag on the decoder's ACK that effectively says "one header block / all header blocks".  When a stream was reset, it would ack all header blocks on that stream to indicate it was no longer tracking them.

However, that gets a little less obvious with #1370, since this is no longer really an acknowledgement, it's a "don't care about."  In that case, I might cast it as a separate instruction.

-- 
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/1371#issuecomment-391107714

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 May 2018 18:03:10 -0700

A separate instruction seems best given the differences.  The encoding is better that way too.  Then you can use a one-bit instruction for the common "ack a single header" instruction and two each for the "ack insertions" and "stream destroyed" instructions.

-- 
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/1371#issuecomment-391554544