W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: HTTP/3 Prioritization Proposal

From: Patrick Meenan <patmeenan@gmail.com>
Date: Tue, 29 Jan 2019 09:38:40 -0500
Message-ID: <CAJV+MGxoPeTgUgzXEgbwhrzfmLWvBGLr5hJ=agkzyg9O_Cf9Ag@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Thanks for the suggestion on the concurrency bit swapping, just made the
change.

On Mon, Jan 28, 2019 at 7:33 PM Mike Bishop <mbishop@evequefou.be> wrote:

> I think you’re both right, actually.  We’ve had discussions in H3 about
> whether the built-in PRIORITY scheme should be pulled out to an extension,
> and one of the reasons not to was that we didn’t have a competing priority
> scheme specified.  If the proposal is an extension, whether to H2 *or *H3,
> the HTTPbis WG owns those per our recharter, no?  So it belongs here, but
> it’s relevant to the H3 discussion and H3 is a reasonable target.
>
>
>
> As to the actual proposal, I think it goes a long way toward giving us
> much of the needed functionality with a minimum of complexity.  I like it.
> One minor suggestion:  I would swap the polarity of the low bits so that it
> flows the same direction as the priority field – greater numbers are more
> important.  (That is, make `11` Exclusive Sequential and `01` Shared.)
> This enables a naïve implementation to just sort by the entire byte and
> come out not far wrong, plus makes a more correct implementation more
> intuitive.
>
>
>
> *From:* Lucas Pardue <lucaspardue.24.7@gmail.com>
> *Sent:* Tuesday, January 29, 2019 7:22 AM
> *To:* Mark Nottingham <mnot@mnot.net>
> *Cc:* Patrick Meenan <patmeenan@gmail.com>; HTTP Working Group <
> ietf-http-wg@w3.org>
> *Subject:* Re: HTTP/3 Prioritization Proposal
>
>
>
> Hey Mark,
>
>
>
> On Tue, 29 Jan 2019, 06:58 Mark Nottingham <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
>
Received on Tuesday, 29 January 2019 14:39:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 January 2019 14:39:13 UTC