Re: HTTP/3 Prioritization Proposal

> I agree with Subodh that deadlines are very useful in QUIC, but I'm not convinced that clients are always in a better position to specify the deadline than servers.  If servers can specify the deadline, then we don't need to add them to priorities.

An example I have is a video player requesting the next DASH segment. The video player knows how much time is remaining before a buffering event will happen and can indicate this to the peer. However I think this could be separable from prioritization completely and could inform the scheduling of priorities.

Specifying a normative behavior of sequential scheduling in concurrency group 2, could be a bit limiting, and we could instead say that if an endpoint has some external information to guide scheduling within a concurrency group it may use that instead of sequential scheduling. Otherwise if we do add deadlines as a concept in the future we would have to use a completely different prioritization scheme which would be sad.

> I need to dig into the extensions mechanism a bit but does it require negotiation

One alternative is to use transport parameters, however that becomes tricky with shoving a bunch of HTTP related settings into transport parameters and also exposes the prioritization scheme being used in the clear. SETTINGs is probably the "right" way to do this even if it does take effect after 1-RTT and would probably have to specify what happens with the old priority frames.

Subodh
________________________________
From: Patrick Meenan <patmeenan@gmail.com>
Sent: Tuesday, January 29, 2019 6:55 AM
To: Lucas Pardue
Cc: Mark Nottingham; HTTP Working Group
Subject: Re: HTTP/3 Prioritization Proposal

I need to dig into the extensions mechanism a bit but does it require negotiation (I would imagine it does to some level)? My main concern would be to figure out how to pull off the prioritization without adding round trips. If the new prioritization byte also made sense as a "weight" for most implementations without breaking prioritization for servers that don't understand the new scheme it might be possible to send the extension frame and stuff the priorities into the weight field and still have servers that don't understand the new prioritization do the right thing with the existing trees.

On Mon, Jan 28, 2019 at 5:21 PM Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>> wrote:
Hey Mark,

On Tue, 29 Jan 2019, 06:58 Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net> wrote:
My sense is that people know that we need to do something about prioritisation, but we're not yet confident about any particular solution. Experimentation with new schemes as HTTP/2 extensions would be very helpful, as it would give us some data to work with. If you'd like to propose such an extension, this is the right place to do it.

The small amount of thinking I did on this lead me to a different conclusion. That it would be easier to experiment with new prioritization schemes in HTTP/3, due mainly to the removal of priority information from the H3 HEADERS frame. This makes it quite feasible to write an extension along the lines of "the extension replaces/supersedes the base standard PRIORITY frame when negotiated". In contrast, a H2 extension either needs to define a new HEADERS format or provide supplemental information in the form of a new frame, which is possible but a bit redundant.

There didn't seem to be much appetite for adopting H3 priority placeholder design in H2 (I cant remember when this was presented, sorry). I'd be curious to know if there is more interest in other alternate priority schemes in H2.

Lucas