W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

Re: [Masque] Prioritizing QUIC DATAGRAMs (was: Re: Prioritizing HTTP DATAGRAMs)

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 23 Jun 2021 20:52:43 +0100
Message-ID: <CALGR9oacZNVAKUD2qAv-ZB8VXs-XZEW+GE9GL_25gHNH13YiOg@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Patrick Meenan <patmeenan@gmail.com>, MASQUE <masque@ietf.org>, Samuel Hurst <samuelh@rd.bbc.co.uk>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, David Schinazi <dschinazi.ietf@gmail.com>, QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Hi Martin,

On Wed, Jun 23, 2021 at 5:44 PM Martin Duke <martin.h.duke@gmail.com> wrote:

> Lucas,
> 15 months ago, I brought up DATAGRAM priorities as a reason to put the
> stream ID in QUIC Datagrams:
> https://github.com/quicwg/datagram/issues/6. I was happy with where this
> ended up: that QUIC should present a stream-based datagram API to
> applications for prioritization purposes, but that there was no reason for
> the stream ID to go out over the wire.
> Alternatively, this could be done on a per-datagram basis.
> Granted, this is not currently in the corresponding PR:
> https://github.com/quicwg/datagram/pull/20/files
> I'll review accordingly.

Thanks for the reminder.

> ISTM that in H3 use cases the datagram is associated with a QUIC stream,
> and it would be straightforward to use httpbis-priority to negotiate a
> priority that then applies to datagrams associated with that stream.

It's easy to say this. The difficulty comes, as an implementer, with
knowing what to actually do with the information. Concrete example, if a
client signals "incremental false" does a server send all streams as FIFO
and then all DATAGRAMS as FIFO, or does it look at DATAGRAM flow creation
order (expect the flow IDs are not strictly ordered as Mikkel points out).
There's a lot of unknowns here and I don't think it is the best use of
folks time on these 2 drafts spinning tires trying to square that circle.

HTTP/3 is shipping without any priorities and the world isn't crumbling.
Prioritization signals are just a fraction of the information that server
implementers take as input.

Servers are going to have to make similar scheduling choices for DATAGRAMs.
That will ultimately depend on how they are being used. IMO neither the
priorities draft nor the HTTP/3 DATAGRAM draft are good venues to consider

> When using QUIC over CONNECT-UDP you have streams on top of streams, and
> H3 priorities are negotiated both with the origin server and the proxy at
> different levels of hierarchy.
> Does this answer your question? Or have I totally missed the point?

Not sure. The question is really, are folks happy to punt detailed
discussion about DATAGRAM multiplexing scheduling and prioritization
signalling to some new I-D. Are you?

Received on Wednesday, 23 June 2021 19:53:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 23 June 2021 19:53:25 UTC