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

[Kazuho Oku <[e-mail]>]

@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 is new nonetheless.

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