Subject: [quicwg/base-drafts] NUM_PLACEHOLDERS MUST NOT be zero (#2753)

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 20:52:02 -0700

Currently, the text says:
```
The default value is 0. However, this value SHOULD be set to a non-zero value by servers.
```

I think we should change the default to unlimited or to some sensible number, and also introduce a minimum permitted number.

Prioritization is not something a client can enforce, therefore servers that prefer to ignore or mishandle placeholders can just ignore / mishandle them, as well as other information for prioritization (e.g. weights and dependencies).

To rephrase, communicating the capability of handling just one of the features of prioritization has marginal benefit compared to the complexity it introduces to the client side (e.g., the need to use different prioritization approach depending on if the server supports placeholders).

Or, if it is the case that we do not expect browsers to no longer use placeholders but are keeping it for proxies, we should remove "SHOULD", because that is a minor use case that has not seen actual use in HTTP/2.

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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 23 May 2019 02:31:52 -0700

The recommended value was 16 a few draft versions ago.  There should be some GitHub artefact justifying changing it to 0.

-- 
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/2753#issuecomment-495142391

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 May 2019 02:32:41 -0700

Settings can only be increased by the SETTINGS frame, if the peer's behavior is bounded by (and not just informed by) the value.  The default therefore needs to be the lowest possible value.  I presume that it was changed when we created default setting values.

-- 
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/2753#issuecomment-495142645

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 May 2019 02:35:21 -0700

Yes, that line last changed in #2038.

-- 
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/2753#issuecomment-495143618

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 23 May 2019 23:22:58 -0700

Maybe the alternative approach would be to:
* Remove the settings parameter, or make it a purely advisory variable like MAX_HEADER_LIST_SIZE allowing the client to exceed the advertised maximum.
* Recommend some sensible number of placeholders that a server is expected to retain (16 - the default value we had prior to merging #2038 - might make sense).

These changes would essentially bring back what we observe in HTTP/2 - server that ignore placeholders would just ignore.

-- 
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/2753#issuecomment-495487631

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 24 May 2019 05:31:49 -0700

> These changes would essentially bring back what we observe in HTTP/2 - server that ignore placeholders would just ignore.

Introduction of placeholders is the backward-compatible part of HTTP/3 prioritization changes: if the client does not use placeholders it can use HTTP/3 priorities without placeholders just as in HTTP/2.  In other words, the clients can ignore placeholders as well.

I agree that it seems that a server SHOULD provide some sensible value.  My guess -- based on some of my mental models -- is that this number should be between N/2 and N, where N is the maximum number of parallel requests the server allows.

-- 
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/2753#issuecomment-495605186

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 26 May 2019 21:51:21 -0700

> I agree that it seems that a server SHOULD provide some sensible value. My guess -- based on some of my mental models -- is that this number should be between N/2 and N, where N is the maximum numb…

FWIW the maximum we have been imposing is 16, we've been closing the connections that goes above that with an ENHANCE_YOUR_CALM error. I do not think that has caused interoperability 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/issues/2753#issuecomment-496076479

---

From: ianswett <[email-masked]>
Date: Tue, 28 May 2019 03:33:35 -0700

Currently, only Firefox would be required to change their prioritization scheme if the number of placeholders is 0.  Based on information I've seen(ie: the Cloudflare presentation and my own anecdotal experience), it's not clear their use of placeholders is any better than a scheme that does not use them, so I think it's possible Firefox could change their priority scheme and it would be faster.

Given that, and that placeholders are a new feature in H3, I'd prefer to allow the number to be 0.

-- 
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/2753#issuecomment-496461068

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 30 May 2019 21:56:44 -0700

Duplicate of #2734?

-- 
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/2753#issuecomment-497575345

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 30 May 2019 22:11:20 -0700

@ianswett 
> Currently, only Firefox would be required to change their prioritization scheme if the number of placeholders is 0. Based on information I've seen(ie: the Cloudflare presentation and my own anecdot…

Fair point. I agree that placeholders becomes no longer a prerequisite for browsers once we bring back the "exclusive" bit (as proposed by #2754).

OTOH, I am still not sure if there is a necessity to diverge from the design we have in HTTP/2 and start requiring clients to take the server's settings into consideration when building a prioritization tree. We currently recommend servers to set `SETTINGS_NUM_PLACEHOLDERS` to some sensible value other than zero, and given that, as I commented in https://github.com/quicwg/base-drafts/issues/2753#issuecomment-495487631, suggesting server's to ignore placeholder IDs out of the server's advertised range might be a simpler solution.

-- 
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/2753#issuecomment-497577780