Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.

Overall, I like the design if the working group has the will to restructure this much.  I think you're burying the lede by not discussing what happens when a placeholder has both weighted and unweighted children.  It's at the very bottom of the prioritization section, and it's a major departure from HTTP/2 that should probably be at the top.

I find the idea of simultaneously having a priority and a weight overly complicated.  As an alternative, perhaps this could be a property of the placeholder -- children are served either in sequence or round-robin by weight, but you can't mix.  (And if you need to mix, just put a placeholder of the opposite type as a child.)

> @@ -1099,36 +1096,41 @@ the RST bit set if it detects an error with the stream or the QUIC connection.
 ## Prioritization {#priority}
 
 HTTP/3 uses a priority scheme similar to that described in {{!RFC7540}}, Section
-5.3. In this priority scheme, a given element can be designated as dependent
-upon another element. This information is expressed in the PRIORITY frame
-{{frame-priority}} which identifies the element and the dependency. The elements
-that can be prioritized are:
-
-- Requests, identified by the ID of the request stream
+5.3, but replaces streams depending upon streams with strict priorities and
+placeholders.  In the HTTP/3 priority scheme, a stream can be given a strict
+priority or can be designated as dependent upon a placeholder or the root.

...or weights, apparently?

>  - Pushes, identified by the Push ID of the promised resource
   ({{frame-push-promise}})
 - Placeholders, identified by a Placeholder ID
 
-Taken together, the dependencies across all prioritized elements in a connection
-form a dependency tree. An element can depend on another element or on the root
-of the tree. A reference to an element which is no longer in the tree is treated
-as a reference to the root of the tree. The structure of the dependency tree
-changes as PRIORITY frames modify the dependency links between prioritized
-elements.
-
-Due to reordering between streams, an element can also be prioritized which is
-not yet in the tree. Such elements are added to the tree with the requested
-priority.
+In HTTP/3, stream dependencies that were implicitly encoded by dependencies in
+HTTP/2 are explicitly encoded with strict prioritization.  This simplifies
+priority tree management, eliminates potential new race conditions introduced
+by HTTP/3's multiple streams, and improves framing efficiency with more than
+64 requests.

I'm not sure we need to be explicit about the 64 requests part.  Maybe just say "for long-lived connections"?

>  
 When a prioritized element is first created, it has a default initial weight
-of 16 and a default dependency. Requests and placeholders are dependent on the
-root of the priority tree; pushes are dependent on the client request on which
-the PUSH_PROMISE frame was sent.
+of 16, priority of 16, and a default dependency. Requests and placeholders are

I'm surprised that they have an initial weight, when weight can be omitted.  Shouldn't the default be to have null weight?

>  
 When a prioritized element is first created, it has a default initial weight
-of 16 and a default dependency. Requests and placeholders are dependent on the
-root of the priority tree; pushes are dependent on the client request on which
-the PUSH_PROMISE frame was sent.
+of 16, priority of 16, and a default dependency. Requests and placeholders are
+dependent on the root of the priority tree; pushes are dependent on the client
+request on which the PUSH_PROMISE frame was sent.

...except that your PR removes the ability to depend on streams, so this means push streams start out in an impossible-to-express state.  Not _necessarily_ a problem (we're doing it with the orphan placeholder), but make sure it's deliberate.

>  
 Requests may override the default initial values by including a PRIORITY frame
 (see {{frame-priority}}) at the beginning of the stream. These priorities
 can be updated by sending a PRIORITY frame on the control stream.
 
+Higher priority elements have all available data sent before elements of lower
+priority.  When multiple elements have the same priority, if a weight is
+specified, elements with weights are interleaved.  If a weight is not
+specified, then elements are delivered sequentially and all available data
+from one element is sent before any data from the next.  If a given priority
+level has some elements with weights and some without, the two groups share
+the available bandwidth equally.

How weights and explicit priorities interact probably needs to come at the top of the section, since it's a pretty substantial departure from HTTP/2.

> -    |                |
-    A                A
-~~~~~~~~~~
-{: #fig-pruning title="Example of Priority Tree Pruning"}
-
-In the example in {{fig-pruning}}, `P` represents a Placeholder, `A` represents
-an active node, and `I` represents an inactive node.  In the first step, the
-server discards two inactive branches (each a single node).  In the second step,
-the server condenses an interior inactive node.  Note that these transformations
-will result in no change in the resources allocated to a particular active
-stream.
-
-Clients SHOULD assume the server is actively performing such pruning and SHOULD
-NOT declare a dependency on a stream it knows to have been closed.
+When a placeholder is reparented, given a new weight or given a new strict
+priority, all dependent placeholders and streams are also re-prioritized.

```suggestion
priority, the effective priority of all dependent placeholders and streams is impacted.
```
Just to be explicit that their priorities don't directly change.

-- 
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/2700#pullrequestreview-237930797