Stream prioritization about webtransport HOT 3 CLOSED

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.

from webtransport.

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

from webtransport.

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.

from webtransport.