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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -633,18 +633,22 @@ 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, 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

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

> -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
+SHOULD refrain from supporting placeholders at all, setting
+`SETTINGS_NUM_PLACEHOLDERS` to zero.

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.

> @@ -1224,9 +1228,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

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?

> @@ -1224,9 +1228,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

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