Subject: Updates to QUIC Datagrams

From: David Schinazi <[email-masked]>
Date: Tue, 22 Oct 2019 14:19:18 -0700

Hi everyone,

In Montreal, we discussed the flow ID in QUIC datagrams, and reached rough
consensus that it made sense for QUIC datagrams to be as simple as
possible, and for higher layers to handle demultiplexing if necessary.

So we've split the identifier into a new draft that only defines it for
application protocols sharing a QUIC connection with HTTP/3.

Here are the updated drafts:

https://tools.ietf.org/html/draft-pauly-quic-datagram-04
https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-01
<https://tools.ietf.org/html/draft-pauly-quic-datagram-04>
Thanks,
David

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Oct 2019 11:22:14 +1100

Thanks for doing this, I think that this is a reasonable approach.

> https://tools.ietf.org/html/draft-pauly-quic-datagram-04

Simple is good.

This probably need to say more about 0-RTT.  That is, explain that protocols that use DATAGRAM in 0-RTT need to define a protocol-specific profile that explains what usage patterns are safe and what anti-replay countermeasures are recommended.

The bit that mentions flow identifiers shouldn't presume so much about how these frames will be used.  The only point you need to make is that it is up to the protocol in use to define how the receiver of a DATAGRAM frame processes that frame.  If you are going to make a point, you might observe that it might be desirable in some protocols to have multiple logical entities receiving DATAGRAM frames, in which case it is up to the protocol to define how DATAGRAM frames are efficiently routed to one of those entities.

Is it illegal to send an empty DATAGRAM frame?

> https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-01

I would frame this slightly differently, to the above point: This creates a system of "flow identifiers" to allow for concurrent use of DATAGRAM frames by multiple extensions without creating contention.  Except that it doesn't entirely...

You should mention that signaling about flow identifiers is necessary, but that is the responsibility of the protocol that defines the usage.  If you don't signal, how does a receiver know that flow ID 1 maps to usage foo and flow ID 2 maps to usage bar?

Also, you should explain that there is no general limit to the flow identifier space, though protocols might want to provide mechanisms to limit usage to prevent resource exhaustion.  This will depend on the protocol, of course.  Some protocols might not expend resources when creating flow IDs.

---

From: Rui Paulo <[email-masked]>
Date: Wed, 23 Oct 2019 12:26:35 -0700

> This probably need to say more about 0-RTT.  That is, explain that protocols that use DATAGRAM in 0-RTT need to define a protocol-specific profile that explains what usage patterns are safe and wha…

That’s a valid point and I brought up other 0-RTT considerations in July:

https://github.com/tfpauly/draft-pauly-quic-datagram/issues/14

> Is it illegal to send an empty DATAGRAM frame?

With the removal of the flow identifiers from the transport, I don’t see reason why it’s even needed.  That said, I don’t oppose it being legal.

—
Rui Paulo

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Oct 2019 12:07:17 -0700

Thanks Martin,

I've filed GitHub issues for these:
https://github.com/tfpauly/draft-pauly-quic-datagram/issues/18
https://github.com/tfpauly/draft-pauly-quic-datagram/issues/19
https://github.com/DavidSchinazi/draft-h3-datagram/issues/2

David

On Wed, Oct 23, 2019 at 12:26 PM Rui Paulo <rpaulo=
[email-masked]> wrote:

> > This probably need to say more about 0-RTT.  That is, explain that
> protocols that use DATAGRAM in 0-RTT need to define a protocol-specific
> profile that explains what usage patterns are safe and what anti-replay
> countermeasures are recommended.
>
> With the removal of the flow identifiers from the transport, I don’t see
> reason why it’s even needed.  That said, I don’t oppose it being legal.
>
> —
> Rui Paulo
>
>