On 9/23/2021 11:11 AM, Lucas Pardue wrote:
Hi Spencer,
On Thu, Sep 23, 2021 at 6:52 PM Spencer Dawkins at IETF <
[email protected]> wrote:
Hi, Lucas and Matt,
On Thu, Sep 16, 2021 at 3:35 PM Lucas Pardue <[email protected]>
wrote:
Hello QUIC WG,
This email starts the Working Group Last Call for "An Unreliable Datagram
Extension to QUIC", located at:
https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html
Please take time to review it carefully and raise any remaining issues
you see either on the GitHub repo issues list[1] or on this mailing list.
I've re-read the discussion in https://github.com/quicwg/datagram/issues/6,
and now better understand the points of view that resulted in the lack of
datagram multiplexing in this specification (I was following that
discussion when it was happening, but hindsight during re-reading helped a
lot!)
I especially appreciate the addition of the text in
https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-multiplexing-datagrams
.
I accept the wisdom of getting more experience with various people using
application-defined multiplexing in various ways before adding any flavor
of multiplexing at the transport layer, and agree that holding this
specification up while that experience is gathered, would not be The Right
Thing To Do.
I'm aware of at least two "RTP over QUIC" proposals that assume that
they'll need to multiplex datagrams, so I won't be surprised if we return
to this question in the future, but for now, the chairs are Doing The Right
Thing, and I support requesting publication of -04 (modulo any changes that
pop up in WGLC, of course).
Thanks for your comments.
Chair hat off, speaking as an individual. To add to the examples, the
MASQUE working group is working on a draft to define HTTP's use of QUIC
DATAGRAM frames and it includes multiplexing [1]. The working group's 00
draft started with a single variable-length integer multiplexing identifier
called the Flow ID. After some fruitful WG implementation and discussion,
in draft 01 it switched to an identifier tuple (Quarter Stream ID, Contenxt
ID). I'd say that we're still figuring out exactly how the things the
__use__ datagrams, want to use datagrams. I think it's too early to
understand the right common transport solution at this time, and that
leaving it undefined does not prevent people from using datagram frames for
their own precise needs and purpose.
Another possibility is to use FEC with Datagrams. If an application does
that, it could very well apply FEC before demuxing.
Or, use segmentation/reassembly of datagrams to mitigate MTU issues.
Again, if an application does that, it could very well process a
reassembly header before any demuxing.
Or, use both segmentation/reassembly and FEC.
And of course, if the application needs to stick a flow-id in front of
the datagram packets, it can do that easily, no transport support needed...
-- Christian Huitema
