Re: HTTP/3 Prioritization Proposal

Thanks. I wasn't sure where the split was going to be as QUIC seemed to be
pushing a lot of prioritization decisions into HTTP. If QUIC is going to be
a general user-mode TCP/IP replacement then this kind of prioritization
probably doesn't belong there since it's mostly targeted at HTTP (and
specifically, web/browser) but if QUIC is more targeted to just be HTTP
then it might make sense.

I'd be open to experimenting with it as an HTTP/2 extension as a step
towards figuring out if it makes sense as well. I'll poke around a bit and
see what would be involved to implement it in a dev build of Chrome and a
server (h2o or nginx) to be able to do some lab testing with it.

On Mon, Jan 28, 2019 at 4:54 PM Mark Nottingham <mnot@mnot.net> wrote:

> Hi Pat,
>
> There's been a fair amount of discussion (and interest) about
> prioritisation, both here and in the QUIC WG.
>
> So far, AIUI our inclination has been to avoid making a large change from
> HTTP/2 in HTTP/3, because doing so would both increase complexity of
> implementations, and also potentially introduce friction for sites and
> applications transitioning from HTTP/2.
>
> I don't recall us having a formal consensus call to support that position,
> but if you want to talk about it more, the QUIC WG mailing list is probably
> the right place.
>
> 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.
>
> Hope this helps,
>
> Cheers,
>
>
> > On 29 Jan 2019, at 2:10 am, Patrick Meenan <patmeenan@gmail.com> wrote:
> >
> > I'm happy to draft it as an I-D but wanted to see if people thought
> there was merit to it before going through the effort:
> https://github.com/pmeenan/http3-prioritization-proposal/blob/master/README.md
> >
> > Basically, I'd like to propose replacing the dependency trees and
> weights with a simpler scheme that has "priority" and "concurrency" values
> for each stream (with no shared tree state).
> >
> > There may be HTTP use cases that it doesn't cover but coming from the
> browser side of things (and having spent some time working on server-side
> prioritization) it should make it MUCH easier to manage prioritization and
> to schedule an "optimal" prioritization for resources.
> >
> > Thanks,
> >
> > -Pat Meenan
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>