Subject: Re: [quicwg/base-drafts] allow PRIORITY frames referring to placeholders exceeding `SETTING_NUM_PLACEHOLDERS` (#2761)

From: Kazuho Oku <[email-masked]>
Date: Mon, 03 Jun 2019 20:44:37 -0700

@ghedo 
> TBH at this point I'd rather spend time exploring the discussion about limiting or even removing placeholders as we talked about in London (including talking with HTTPbis) rather than try to hack around all of these problems.

It is my view that we should continue refining the prioritization scheme of HTTP/3, though I would not argue for suppressing any other discussion.

The concern of redesigning the prioritization scheme is that the standardization process might get delayed. We do not have a working group consensus on what the goal of the design would be. Compared to that, making changes to lessen the divergence from the prioritization scheme of HTTP/2 _is_ in line with the charter, it is a goal that does not move, and we know how to reintroduce the exclusive bit (see #2754). This PR is a small change that we _might_ adopt alongside other changes that lessen the divergence.

-- 
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/2761#issuecomment-498509101

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 03 Jun 2019 20:45:00 -0700

@LPardue 
> However, to support your argument, it may be better to ignore all priority tree requests rather than fail e.g. half of them. And because the server doesn't know how many placeholders the client wants, it can never guess how many would be enough, ever.

Yeah. I think that the anticipation behind this PR is that a server would either support no placeholders at all, or be capable of handling enough number of placeholders. FWIW, Firefox uses 4 "placeholders" in HTTP/2. I do not think that there would be a reason for a HTTP/3 with support for placeholders to support something below 4.

Maybe we should change the recommendation of SETTINGS_NUM_PLACEHOLDERS that state "this value SHOULD be set to a non-zero value by servers" to  "this value SHOULD be set to a value equal to or greater than four" or something alike.

-- 
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/2761#issuecomment-498509146

---

From: Robin Marx <[email-masked]>
Date: Wed, 05 Jun 2019 09:18:57 +0000 (UTC)

> Yeah. I think that the anticipation behind this PR is that a server would either support no placeholders at all, or be capable of handling enough number of placeholders. FWIW, Firefox uses 4 "place…

@kazuho do you have a source for this? afaik, it uses 6...

I agree that current browser approaches do not require many placeholders, but as also included in Ian's presentation in London, if you want to simulate something like @patmeenan's scheme with placeholders, you need 4 placeholders per priority-level (of which that scheme uses a default of 3, so 12 placeholders minimum total). 

I share's @ghedo's views that making this an advisory SETTING would not mean much in practice if not coupled with a minimum amount of placeholders servers MUST support. I'm more for requiring at least X placeholders (X > 32 in my opinion).

-- 
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/2761#issuecomment-499006288

---

From: Robin Marx <[email-masked]>
Date: Wed, 05 Jun 2019 02:24:49 -0700

rmarx commented on this pull request.

> @@ -1202,9 +1202,17 @@ The following situations are examples of invalid PRIORITY frames:
 A PRIORITY frame with Empty bits not set to zero MAY be treated as a connection
 error of type HTTP_MALFORMED_FRAME.
 
-A PRIORITY frame that references a non-existent Push ID, a Placeholder ID
-greater than the server's limit, or a Stream ID the client is not yet permitted
-to open MUST be treated as a connection error of type HTTP_LIMIT_EXCEEDED.
+A PRIORITY frame that references a non-existent Push ID, or a Stream ID the
+client is not yet permitted to open MUST be treated as a connection error of
+type HTTP_LIMIT_EXCEEDED.
+
+A PRIORITY frame MAY reference a Placeholder ID that is equal to or greater than
+the server's advertised value of the `SETTINGS_NUM_PLACEHOLDERS` settings.  When
+receiving a PRIORITY frame with its prioritized element set to such a
+placeholder, the server SHOULD discard the frame without making any change to
+the priority tree.  When receiving a PRIORITY frame with its element dependency
+set to such a placeholder, the server SHOULD update the priority tree with the
+root of the tree being the dependency instead.

With regards to #2690, should the default be the orphan or the root? Root makes a bit more sense, since this element is clearly something the client wants to explicitly prioritize. On the other hand, this is a bit dirty, since with the orphan placeholder, nothing else gets explicitly added to the root anymore. 

-- 
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/2761#pullrequestreview-245895750

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Jun 2019 17:41:02 -0700

@kazuho pushed 1 commit.

8328485360efb2574037919ee2e4dc8499f7217b  recommend >=32 placeholders

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/4579ada05eba97b83e8eb9833ea013b70d30cc10..8328485360efb2574037919ee2e4dc8499f7217b

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Jun 2019 17:51:02 -0700

@rmarx Thank you for the comments. I see several folks argue for having lower bound for SETTINGS_NUM_PLACEHOLDERS; I've updated the PR to say "at least 32".

It is still a SHOULD rather than a MUST, based on the perception that changing it to a MUST just incentivizes the servers to lie about it's capability, which reduces the usefulness of SETTINGS_NUM_PLACEHOLDERS.

-- 
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/2761#issuecomment-499307975

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Jun 2019 17:57:46 -0700

kazuho commented on this pull request.

I agree that this is debatable.

The reason I've chosen "root" as the starting point of this PR is because it is the behavior defined in HTTP/2; I think we should try to retain similarity if possible (unless / until we decide to adopt a very different design). Note that orphan placeholder is still useful regardless of this; the placeholder minimizes the negative impact when PRIORITY frames on the control stream gets lost.

Hopefully, this point becomes a less of an issue once we recommend some sensible minimum for SETTINGS_NUM_PLACEHOLDERS; essentially guiding servers to support either none or at least 32 (or something alike).

-- 
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/2761#discussion_r290988659

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Jun 2019 16:27:10 -0700

MikeBishop commented on this pull request.

> @@ -613,17 +613,17 @@ tree could be discarded safely. Clients could potentially reference closed
 streams long after the server had discarded state, leading to disparate views of
 the prioritization the client had attempted to express.
 
-In HTTP/3, a number of placeholders are explicitly permitted by the server using
-the `SETTINGS_NUM_PLACEHOLDERS` setting. Because the server commits to
-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, placeholders are given their own number space that spans between zero
+and 2^62-1.  By using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the range of placeholder IDs it is committing to maintain state,

"advertises the number of placeholder IDs for which it is committing to maintain state."

> @@ -613,17 +613,17 @@ tree could be discarded safely. Clients could potentially reference closed
 streams long after the server had discarded state, leading to disparate views of
 the prioritization the client had attempted to express.
 
-In HTTP/3, a number of placeholders are explicitly permitted by the server using
-the `SETTINGS_NUM_PLACEHOLDERS` setting. Because the server commits to
-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, placeholders are given their own number space that spans between zero
+and 2^62-1.  By using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the range of placeholder IDs it is committing to maintain state,
+which is between zero and one less than the value of this setting.  Clients can
+use the placeholders within this range with the confidence that the server will

"can use placeholders with an ID less than the value of this setting with...."

```suggestion
A PRIORITY frame that references a non-existent Push ID or a Stream ID the
```

I feel like the orphan makes more sense -- just because the client is assigning *a* priority doesn't imply that it's assigning a *high* priority.  The implication would be that clients should build the priority tree with higher-priority placeholders having a lower placeholder ID.  At some point, the placeholder IDs cross the threshold of what the server supports, and everything in that tree region devolves to "after everything else."  That seems like a reasonable degradation path.

-- 
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/2761#pullrequestreview-246859283

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Jun 2019 20:29:13 -0700

@kazuho pushed 1 commit.

c3794196ac57c29f4d3861cca47193443f0affe8  Update draft-ietf-quic-http.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/8328485360efb2574037919ee2e4dc8499f7217b..c3794196ac57c29f4d3861cca47193443f0affe8

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Jun 2019 20:37:08 -0700

@kazuho pushed 1 commit.

6b8b4577c9bf6e5cde2eff0df40c672a64b87631  apply editorial suggestions from @MikeBishop as well as reorganizing the paragraph.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/c3794196ac57c29f4d3861cca47193443f0affe8..6b8b4577c9bf6e5cde2eff0df40c672a64b87631

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Jun 2019 20:39:14 -0700

Thank you for the suggestions. I've applied this proposed change (with the omission of "IDs") as well as the one below in 6b8b457, at the same time reordering the sentences so that they flow 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/2761#discussion_r291443387

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Jun 2019 22:48:06 -0700

> The implication would be that clients should build the priority tree with higher-priority placeholders having a lower placeholder ID.

This sounds like a good way of thinking. I agree that providing such a guidance is a better than having no guidance at all.

OTOH, That creates a dependency on #2690. @MikeBishop, should we wait for the merger of #2690 before updating the text?

-- 
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/2761#discussion_r291459107

---

From: Mike Bishop <[email-masked]>
Date: Fri, 07 Jun 2019 14:19:59 -0700

There's an [easy solution](https://github.com/quicwg/base-drafts/commit/053044d622bc6854474ee88d018a2ec88f7480dd) to that.

-- 
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/2761#discussion_r291758290

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 09 Jun 2019 07:44:50 -0700

@kazuho pushed 1 commit.

af71abd469ba548828203b4039276f25cd297680  Merge branch 'master' into kazuho/placeholder-id-above-advertised-value-isnt-an-error

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/6b8b4577c9bf6e5cde2eff0df40c672a64b87631..af71abd469ba548828203b4039276f25cd297680

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 09 Jun 2019 07:47:10 -0700

@kazuho pushed 1 commit.

18c83034e7578c31d48d949fcfbf2e1c09b05227  missing dependency is substituted by a orphan placeholder (instead of root)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/af71abd469ba548828203b4039276f25cd297680..18c83034e7578c31d48d949fcfbf2e1c09b05227

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 09 Jun 2019 07:48:54 -0700

I am impressed! 18c8303 changes the dependency to the orphan placeholder.

-- 
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/2761#discussion_r291839181

---

From: ianswett <[email-masked]>
Date: Mon, 10 Jun 2019 11:55:21 -0700

ianswett commented on this pull request.

> @@ -1335,8 +1343,8 @@ The following settings are defined in HTTP/3:
   : The default value is unlimited.  See {{header-formatting}} for usage.
 
   SETTINGS_NUM_PLACEHOLDERS (0x9):
-  : The default value is 0.  However, this value SHOULD be set to a non-zero
-    value by servers.  See {{placeholders}} for usage.
+  : The default value is 0.  However, servers SHOULD set this value to 32 or

Wow, 32 is a large number.  If we keep exclusive prioritization, then Chrome will probably continue to use that, and Firefox doesn't use this many, so why such a high limit?

-- 
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/2761#pullrequestreview-247784063

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jun 2019 17:20:01 -0700

martinthomson commented on this pull request.

Just because we use 6 now, doesn't mean that we'll keep that scheme.  We're currently looking at ways to improve prioritization and placeholders are seen as being very useful in doing that.  It's very early yet, but it might be that more are found to be useful.

And 32 isn't a big number.  You need quite a few more zeros to qualify, I'd think.

-- 
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/2761#discussion_r292237988

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 10 Jun 2019 18:04:20 -0700

FWIW, I do not care much, because the amount of state required by each placeholder is much less than that required by each HTTP stream (which includes send buffers). We recommend servers supporting at least 100 concurrent HTTP streams, so 32 placeholders can be a SHOULD.

That said, I think I might prefer choosing a number that is a divisor of 100 (e.g., 20, 25).

-- 
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/2761#discussion_r292244634

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Jun 2019 10:53:17 -0700

Powers of two seem more natural in a protocol, but I am similarly uncaring about the specific number.

-- 
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/2761#discussion_r292585142

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Jun 2019 10:55:17 -0700

MikeBishop approved this pull request.

> @@ -633,18 +633,18 @@ tree could be discarded safely. Clients could potentially reference closed
 
-In HTTP/3, a number of placeholders are explicitly permitted by the server using
-the `SETTINGS_NUM_PLACEHOLDERS` setting. Because the server commits to
-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, by using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the number of client-controlled placeholders it is committing to

"placeholders for which it is committing to maintain state." or "placeholders it is committing to maintain."

-- 
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/2761#pullrequestreview-248342094

---

From: ianswett <[email-masked]>
Date: Wed, 12 Jun 2019 14:42:37 -0700

As I've stated elsewhere, I'm not a fan of this because I'd like placeholders to be optional and be able to enforce this, in an effort to keep H3 as close to H2 codewise.

-- 
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/2761#issuecomment-501465834

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 14:46:07 -0700

@ianswett 
> As I've stated elsewhere, I'm not a fan of this because I'd like placeholders to be optional and be able to enforce this, in an effort to keep H3 as close to H2 codewise.

Could you please elaborate a bit more? While I can see why you argue for "placeholders to be optional and be able to enforce this," I do not see why doing so makes H2 and H3 closer.

H2 allows client to create placeholders without regard to what server actually does, and this is about bringing back that behavior.

-- 
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/2761#issuecomment-501466861

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 14:50:50 -0700

@kazuho pushed 1 commit.

752df0df9803efc9948590b9dcc11d7b875ed220  add "for which", as suggested by @MikeBishop

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/18c83034e7578c31d48d949fcfbf2e1c09b05227..752df0df9803efc9948590b9dcc11d7b875ed220

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 14:51:32 -0700

:+1: done in 752df0df.

-- 
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/2761#discussion_r293132602

---

From: Robin Marx <[email-masked]>
Date: Wed, 12 Jun 2019 14:59:17 -0700

I also suggested 32 because the "power of two" feeling. Otoh, I was thinking about Patrick Meenan's setup, which requires 4 placeholders per priority level in the current scheme, allowing for 8 priority levels if the minimum number of placeholders is 32. 8 is more than e.g., the 5 chrome is using at the moment, but seems like a good number (see also SPDY priority levels).

I just want to prevent us setting this to a too low a number (e.g., 10), since that would counteract the purpose of setting a lower bound imo.

-- 
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/2761#discussion_r293135104

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Jun 2019 19:48:06 -0700

While I think it makes more sense to define a number that is defined in relation to the number of concurrent requests we suggest to support, I do not think that the current value of 100 is correct (see #2787).

Considering that, I am fine with seeing this PR merged with 32 being the advice, and revisiting the advisory value if necessary.

-- 
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/2761#discussion_r293187776

---

From: ianswett <[email-masked]>
Date: Thu, 13 Jun 2019 06:00:41 -0700

>From a functionality perspective, I agree this brings H3 inline with H2, but it uses a new mechanism to achieve functional parity.  As we've discussed, a new mechanism seems necessary in H3, but it is new nonetheless.

-- 
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/2761#issuecomment-501692420

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Jun 2019 17:35:10 -0700

@ianswett 
> From a functionality perspective, I agree this brings H3 inline with H2, but it uses a new mechanism to achieve functional parity. As we've discussed, a new mechanism seems necessary in H3, but it…

Yeah. Granted that placeholders are new in HTTP/3 and therefore they _can_ be enforced as optional, I do not see why they need to be.

I think our experience in HTTP/2 tells us that clients can specify different weights for requests so that the bandwidths would be distributed based on the weights when the server does not support placeholders at all. I'd assume that most if not all clients would use that same tree if we enforce them to not use placeholders when SETTINGS_NUM_PLACEHOLDERS is set to zero.

To rephrase, I do not think there would be a benefit in terms of performance by having this enforcement, for the majority of our use case.

Compared to that, the complexity being introduced by the enforcement is a burden. Not only because it requires clients to build different priority tree based on the server's settings, but because the client needs to wait for the server's SETTINGS to arrive before it can decide the type of the priority tree to use. For the server, the complexity is the same regardless of the approach; it's either throwing away PRIORITY frames that refer to out-of-bound placeholders or sending connection errors.

Therefore, while placeholders can be considered optional, I do not think it justifies the servers enforcing the limit.

PS. Or is your problem that SETTING_NUM_PLACEHOLDERS to zero is not RECOMMENDED? If so, I think we could change to the recommendation from "at least 32" to "zero or at least 32". As stated above, setting I do not think setting it to zero would be an issue. It set to some wired small value (like 3, which is below the number of placeholders Firefox uses) is the case where we'd see performance issues.

-- 
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/2761#issuecomment-501926285

---

From: ianswett <[email-masked]>
Date: Fri, 14 Jun 2019 08:03:57 -0700

Certainly if you said zero or at least 32, that would make placeholders more optional, so I'd have a preference for that.

-- 
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/2761#issuecomment-502144216

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Jun 2019 08:38:37 -0700

But when it's set to zero, clients no longer have the H2-style option of easy zombie streams to fulfill the roll.  Sure, Firefox could have Chrome's behavior as a fallback option for servers that say zero, but I don't see that as necessarily being a good thing for the spec to RECOMMEND.

In my opinion, "RECOMMENDED to be 32, allowed to be zero" communicates the right incentives.

-- 
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/2761#issuecomment-502157626

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Jun 2019 22:16:09 -0700

@kazuho pushed 1 commit.

d07c072fb23534264fb170fb2bc7fc3b15bf99b4  SHOULD at least 32, acknowledge that some might support zero

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/752df0df9803efc9948590b9dcc11d7b875ed220..d07c072fb23534264fb170fb2bc7fc3b15bf99b4

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Jun 2019 22:17:02 -0700

@MikeBishop @ianswett d07c072 goes the middle round. WDYT?

-- 
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/2761#issuecomment-502950717

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 07:19:29 -0700

That works for me.

-- 
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/2761#issuecomment-503156691

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 18 Jun 2019 16:41:03 -0700

@kazuho pushed 1 commit.

b60a6c5740133ba0f8ca708edf3dbcf62631097c  fix grammar (credit to @rmarx)

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Jun 2019 10:36:15 -0700

Not an issue, just an observation.  #2690 added text saying that the client can neither reprioritize *nor refer* to the orphan placeholder.  With this change, we've made it really easy to refer to the orphan placeholder -- any large-numbered placeholder does.  (And if you misfire and pick a placeholder that actually could exist, if you've never prioritized it, its parent will be the orphan placeholder, so same thing.)

-- 
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/2761#issuecomment-503658141

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Jun 2019 10:39:07 -0700

Never mind -- either I imagined it, or it's already changed by this PR.  Either way, it's fine.

-- 
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/2761#issuecomment-503659166

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 16:52:31 -0700

> @@ -633,18 +633,22 @@ tree could be discarded safely. Clients could potentially reference closed
 
-In HTTP/3, a number of placeholders are explicitly permitted by the server using
-the `SETTINGS_NUM_PLACEHOLDERS` setting. Because the server commits to
-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, by using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the number of client-controlled placeholders for which it is
+committing to maintain state.  Client-controlled placeholders are given their
+own number space that spans between zero and 2^62-1.  Clients can use the
+client-controlled placeholders with an ID less than the value of this setting
+with the confidence that the server will not have discarded the state.  The
+orphan placeholder cannot be prioritized or referenced by the client.
+
+Servers are RECOMMENDED to support at least 32 placeholders.  Those that do not

```suggestion
Servers SHOULD support at least 32 placeholders.  Those that do not
```

> @@ -633,18 +633,22 @@ tree could be discarded safely. Clients could potentially reference closed
 
-In HTTP/3, a number of placeholders are explicitly permitted by the server using
-the `SETTINGS_NUM_PLACEHOLDERS` setting. Because the server commits to
-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, by using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the number of client-controlled placeholders for which it is
+committing to maintain state.  Client-controlled placeholders are given their
+own number space that spans between zero and 2^62-1.  Clients can use the
+client-controlled placeholders with an ID less than the value of this setting
+with the confidence that the server will not have discarded the state.  The

```suggestion
with the confidence that the server will discarded associated state.  The
```

Question, if we have PlaceholderN->RequestN->root in a tree and RequestN has long since been discarded; is this considered "discarding the state"?

-maintaining these placeholders in the prioritization tree, clients can use them
-with confidence that the server will not have discarded the state. Clients MUST
-NOT send the `SETTINGS_NUM_PLACEHOLDERS` setting; receipt of this setting by a
-server MUST be treated as a connection error of type
+In HTTP/3, by using the `SETTINGS_NUM_PLACEHOLDERS` setting, the server
+advertises the number of client-controlled placeholders for which it is
+committing to maintain state.  Client-controlled placeholders are given their
+own number space that spans between zero and 2^62-1.  Clients can use the
+client-controlled placeholders with an ID less than the value of this setting
+with the confidence that the server will not have discarded the state.  The
+orphan placeholder cannot be prioritized or referenced by the client.
+
+Servers are RECOMMENDED to support at least 32 placeholders.  Those that do not
+SHOULD refrain from supporting placeholders at all, setting
+`SETTINGS_NUM_PLACEHOLDERS` to zero.

I find this weird.  I would strike the second sentence entirely and consider replacing it with justification for 32.

> @@ -1224,9 +1228,17 @@ The following situations are examples of invalid PRIORITY frames:
 
+A PRIORITY frame that references a non-existent Push ID or a Stream ID the

```suggestion
placeholder, the server MAY discard the frame without making any change to
```
Note that the setting is loosely defined, as is the size of the priority tree.  A server might allow placeholders above its limit.

> @@ -1224,9 +1228,17 @@ The following situations are examples of invalid PRIORITY frames:
 
+A PRIORITY frame that references a non-existent Push ID or a Stream ID the

```suggestion
set to a discarded placeholder, the server SHOULD update the priority tree with the
```

Note that this isn't any different than referring to a long-expired request.

-- 
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/2761#pullrequestreview-254323999

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 21:20:32 -0700

@kazuho pushed 1 commit.

06f0e8a3062174a00024ff6663d69fd1209f682a  Update draft-ietf-quic-http.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/b60a6c5740133ba0f8ca708edf3dbcf62631097c..06f0e8a3062174a00024ff6663d69fd1209f682a

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 21:26:40 -0700

If the text is unclear, maybe we should change it to something like "with the confidence that the server will retain state"? Note that the sentence is about ID being *less* than SETTINGS_NUM_PLACEHOLDERS.

> Question, if we have PlaceholderN->RequestN->root in a tree and RequestN has long since been discarded; is this considered "discarding the state"?

No. "State" here means the existence of the placeholder and the relationship with it's children.

-- 
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/2761#discussion_r297479702

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 21:30:29 -0700

This is the outcome of the discussion (see above). The intent is:
* recommend providing at least 32 placeholders
* acknowledge that 0 is a sensible value when that not possible

The rational is to make it possible for a client to create a priority tree that works reasonably well, assuming that it uses no more than 32 placeholders in these two conditions.

-- 
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/2761#discussion_r297480249

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 21:34:04 -0700

I think I prefer "SHOULD."

Having SHOULD here, along with the recommendation that the server would support at least 32 placeholders (or zero), gives a client the chance to build a prioritization tree that works well.

Changing this to MAY makes that difficult. Consider the case where the client uses a Firefox-like priority tree a server advertises SETTINGS_NUM_PLACEHOLDERS of zero but in fact supports one. Having one placeholder being active while dependencies of other placeholders being assigned to root causes a nightmare.

-- 
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/2761#discussion_r297480749

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 21:36:15 -0700

I am not sure if "discard" is the correct word, because placeholders are never discarded. They simply exist (or do not).

How about "nonexistent"?

-- 
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/2761#discussion_r297481049

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Jun 2019 00:56:38 -0700

Then say "that the server will not have disposed of the priority of the placeholder".

Yes, I understand that, but two chained SHOULD statements is hard to follow.

Mostly, I just don't agree with the conclusion of that discussion.  If I want to provide 24, that is perfectly fine, and it might be enough for most clients.  Pushing me toward advertising zero doesn't help at all.  

So I don't agree with the idea that pushing people toward 0 is needed.  They can make that decision on their own.  And it's the default, so there is plenty of encouragement already.

An implementation that wants placeholders will have to implement some number of strategies for priority.  If they get the number of placeholders they want, cool.  If not, then they have to find another strategy.

SHOULD makes no sense.  It says that there is an interoperability requirement to put those nodes in the orphan bucket.  What does anyone gain from this?  The client is prioritizing without regard for server limits, but if the server can build a valid tree, why not let it?

Sure.

-- 
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/2761#discussion_r297526521

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Jun 2019 10:08:12 -0700

@ianswett was the main proponent for the "or bust" portion of this recommendation, I believe.  Want to defend the 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/2761#discussion_r297774512

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 27 Jun 2019 21:54:01 -0700

@kazuho pushed 1 commit.

47abc99e3b3673adf9d6f543ecbea5ff3b515300  editorial suggestion by @martinthomson

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2761/files/06f0e8a3062174a00024ff6663d69fd1209f682a..47abc99e3b3673adf9d6f543ecbea5ff3b515300

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 27 Jun 2019 21:54:38 -0700

Thank you for the suggestion. Applied in 47abc99 (changing "of the placeholder" to "of these placeholders").

-- 
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/2761#discussion_r298452542

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 27 Jun 2019 22:26:06 -0700

This certainly depends on acknowledging that servers can set SETTINGS_NUM_PLACEHOLDERS to zero.

If we look at HTTP/2 implementations, it is my understanding that browsers tend to give higher weight values to resources of higher precedence, regardless of their position in the prioritization tree. This works somewhat reasonably as a fallback when connecting to a server that respects the weights only, because resources of higher precedence would be given more bandwidths that those of lower precedence.

Recommending (or acknowledging) that SETTINGS_NUM_PLACEHOLDERS to be 0 or at least 32 allows a client implementation to consider only two ways of server prioritizing the responses: one being the server respecting the tree build by the client, the other being the tree squeezed and only the weight values being respected.

IMO knowing that the servers are likely to view the prioritization information in either of these two ways is highly preferable for enabling a client to use one design for the prioritization tree it builds _regardless of the value of SETTINGS_NUM_PLACEHOLDERS_, which is IMO the primary goal of this PR.

-- 
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/2761#discussion_r298456876