Stream prioritization

[steveanton]

The QUIC IETF specification has a section on stream prioritization: https://tools.ietf.org/html/draft-ietf-quic-transport-16#section-2.4

The summary is that the application is responsible for instructing the QUIC implementation how to prioritize stream data. Which means that this API should have a way for Web developers to indicate the relative priority of streams.

[Atrius]

Depending on how datagram support works, we should also consider how to prioritize datagrams vs. streams, and datagrams vs. other datagrams.

If the application gets a callback whenever the transport is ready to send another datagram, but the applications also uses streams, what happens first?

• the transport sends queued stream data
• the transport calls the application for another datagram

And if the application hands datagrams to the transport, and the transport queues them to be sent at an appropriate moment, it seems fairly apparent we'd want some mechanism to say which streams and/or datagrams should go first.

[LPardue]

You might be interested in the individual Internet-Draft https://datatracker.ietf.org/doc/html/draft-pardue-masque-dgram-priority-01

[jan-ivar]

Datagram send queues are specified now with sender-side back pressure so we're in a bit of a better shape than when this filed. This means applications are somewhat in control over sending priorities simply by throttling inputs independently.

That said, we could always do better, but discussion is happening over in #62 so I'm closing this one in favor of that issue.