Subject: Re: [quicwg/base-drafts] QPACK Blocking Setting (#1143)

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Apr 2018 07:51:21 -0700

martinthomson requested changes on this pull request.

Here's a question: if -http depends on -qcram, I think that we need to define configuration parameters in -qcram and explain how the settings are used to set these parameters in -http.  Right now the drafts are tightly coupled.

> @@ -100,10 +100,13 @@ which might not yet have been processed by the recipient.  Such references
 are called "vulnerable," because the loss of a different packet can keep
 the reference from being usable.
 
-The encoder can choose on a per-header-block basis whether to favor higher
+The decoder can signal that it is willing to process vulnerable references by

I still don't like the term "vulnerable references" here.  The point is that the decoder is willing to block on incomplete or in-progress header table updates or not.  "Vulnerable" as a concept isn't helpful, especially here.

> @@ -786,7 +786,10 @@ The following settings are defined in HTTP/QUIC:
   : An integer with a maximum value of 2^30 - 1.
 
   SETTINGS_MAX_HEADER_LIST_SIZE (0x6):
-  : An integer with a maximum value of 2^30 - 1
+  : An integer with a maximum value of 2^30 - 1.
+
+  SETTINGS_BLOCKING_HEADER_REFERENCES (0x7):
+  : An integer with a maximum value of 2^16 - 1.

These need defaults.

> @@ -115,6 +118,9 @@ state which the peer might not have received yet, the BLOCKING flag MUST be
 set.  If the peer does not yet have the appropriate state, such blocks
 might not be processed on arrival.
 
+An encoder MUST NOT have more header blocks outstanding with the BLOCKING flag
+set than the value of SETTINGS_BLOCKING_HEADER_REFERENCES at any time.

So what does a decoder do if it has to block more times than it said it was willing to?  You should also note that an encoder might violate this agreement but not be detected in doing so.

-- 
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/1143#pullrequestreview-114819959

---

From: Mike Bishop <[email-masked]>
Date: Tue, 24 Apr 2018 17:13:33 +0000 (UTC)

Perhaps the settings should be in QPACK instead.  I was keeping it that way because that's what HTTP/2 did, but we're breaking with precedent other places we feel like we've learned better now, so... perhaps.  However, that looks to have enough ripple effects on the HTTP doc that I'd prefer to do that in a separate PR.  This is now #1323.

-- 
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/1143#issuecomment-384010271

---

From: Mike Bishop <[email-masked]>
Date: Tue, 24 Apr 2018 17:28:44 +0000 (UTC)

@MikeBishop pushed 1 commit.

cd60101  Martin's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1143/files/bf0c29b488587b9ca6acfb6da3751fb0ab33cef1..cd601013cd5f8fd61ca00add3c01e2c7279145b3

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 25 Apr 2018 08:09:35 -0700

While "vulnerable" is not perfect (@martinthomson pointed this out somewhere, but I cannot find it now), "blocking" is worse.  This is because it is not always clear whether the reference a) may become blocked or b) is already blocked.  "Vulnerable" conveyed the intended meaning -- the _potential_ to become blocked -- better.

-- 
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/1143#issuecomment-384322286

---

From: afrind <[email-masked]>
Date: Wed, 25 Apr 2018 17:29:38 -0700

I agree with @dtikhonov that blocking is worse.  It's neither blocking nor vulnerable, but vulnerable-to-HoL-blocking.  I say change it back for now and defer coming up with a better term for another issue.

-- 
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/1143#issuecomment-384474806

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Apr 2018 16:40:38 +0000 (UTC)

de572d8  Blocking v. Vulnerable

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1143/files/cd601013cd5f8fd61ca00add3c01e2c7279145b3..de572d8257ca028c62a1781452ff1e40a94313d0

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Apr 2018 10:03:21 -0700

Here's another stab at it -- references are "vulnerable" if the encoder sends them without knowing that the decoder has the entries.  They're "blocking" if they arrive at the decoder and it actually doesn't.  Because each vulnerable reference *could be* blocking, the encoder needs to keep its number of vulnerable references below the number of blocking references the decoder will tolerate.

-- 
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/1143#issuecomment-384715845

---

From: afrind <[email-masked]>
Date: Thu, 26 Apr 2018 12:58:12 -0700

afrind commented on this pull request.

> @@ -95,15 +95,26 @@ reintroduced by HPACK when the loss includes a HEADERS frame.
 
 ## Avoiding Head-of-Line Blocking in HTTP/QUIC {#overview-hol-avoidance}
 
-In the example above, the second stream contained a reference to data
-which might not yet have been processed by the recipient.  Such references
-are called "vulnerable," because the loss of a different packet can keep
-the reference from being usable.
-
-The encoder can choose on a per-header-block basis whether to favor higher
+In the example above, the header block on the second stream contained a
+reference to data which might not yet have been processed by the recipient. Such
+references are called "vulnerable," because the loss of a different packet can
+keep the reference from being usable.  If the reference cannot be immediately
+processed on receipt, the reference is considered "blocking."

It's more blocked than blocking (the missing one is blocking)?

> @@ -494,7 +505,9 @@ Indexed-Duplicate representation instead (see {{indexed-duplicate}}).
 
 For header blocks encoded in non-blocking mode, the encoder needs to forego
 indexed representations that refer to table updates which have not yet been
-acknowledged with {{feedback}}.
+acknowledged with {{feedback}}.  Since all table updates are processed in
+sequence on the control stream, an index into the dynamic table is sufficient to
+track which entries have been processed.

change processed to acknowledged to match the previous sentence?

-- 
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/1143#pullrequestreview-115725220

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Apr 2018 20:46:38 +0000 (UTC)

e606615  blocking => blocked

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1143/files/348c47389aca2db52aa5951c40479ffa6ee8245e..e606615b8e83cd8ece74c959541b46119f138898

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Apr 2018 20:48:25 +0000 (UTC)

6009451  ack'd

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1143/files/e606615b8e83cd8ece74c959541b46119f138898..6009451998bebc33aaf9e6c1ac0737539b801fdc

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Apr 2018 20:54:31 +0000 (UTC)

7b81097  Merge remote-tracking branch 'origin/master' into qcram_blocking

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1143/files/6009451998bebc33aaf9e6c1ac0737539b801fdc..7b81097b0c2446b291b2a8bc7763f848b17377aa

---

From: afrind <[email-masked]>
Date: Thu, 26 Apr 2018 16:55:24 -0700

The setting is still called BLOCKING_HEADER_REFERENCES, but the text now talks about blocked streams.  Should we update this as well?  SETTINGS_MAX_STREAMS_BLOCKED_ON_HEADERS is kind of a mouthful.

-- 
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/1143#issuecomment-384822897