Skip to main content

An Unreliable Datagram Extension to QUIC


Erik Kline
Zaheduzzaman Sarker
(Martin Duke)

No Objection

Francesca Palombini
(Alvaro Retana)
(Martin Vigoureux)
(Robert Wilton)

Note: This ballot was opened for revision 08 and is now closed.

Erik Kline
Roman Danyliw
Comment (2022-01-31 for -08) Not sent
Thank you to Carl Wallace for the SECDIR review.
Zaheduzzaman Sarker
Éric Vyncke
Comment (2022-02-02 for -08) Sent
Thank you for the work put into this document. It can indeed be very useful notably for the VPN case.

Please find below some blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Lucas Pardue for the shepherd's write-up including the section about the WG consensus even if I had appreciated a justification for the PS status rather than an assertion. 

I hope that this helps to improve the document,



## Section 3

Does it make any sense to have max_datagram_frame_size <= 20 ? (IPv4 header size)

## Section 4

The first paragraph with the binary notation is not easy to parse. I really prefer the first paragraph of section 19.3 of RFC 9000. 

## Section 5.1

I find the following text hard contradicting the first paragraph of section 5:
   QUIC implementations SHOULD present an API to applications to assign
   relative priorities to DATAGRAM frames with respect to each other and
   to QUIC streams.
Francesca Palombini
No Objection
John Scudder
No Objection
Comment (2022-02-01 for -08) Sent
As a rank QUIC neophyte my ability to offer serious technical review of this document is limited at best. However I do have a few questions that (in the best case) might reveal lacunae that experts overlooked but which trip up a neophyte, or (in the worst case) only my own ignorance. 

1. In the Motivation section you write,

   *  Applications that open both a reliable TLS stream and an
      unreliable DTLS flow to the same peer can benefit by sharing a
      single handshake and authentication context between a reliable
      QUIC stream and flow of unreliable QUIC datagrams.  This can
      reduce the latency required for handshakes.

This threw me off, considering that in the previous section (Introduction) you point to UDP/DTLS as a prior way of providing a similar service. In the quotation above it seems as though you’re using them synonymously… or something.

TBH, I just don’t follow what the quoted text is getting at. :-( I do get (in a general way) that QUIC makes use of (parts of?) TLS, but that doesn’t allow me to make sense of it.

2. You’re inconsistent about whether DATAGRAM frames have a type, singular, or types, plural. Plural seems right to me, but read on. In §3, you refer to “the DATAGRAM frame types”, plural. But then in §4 you say that the LSB of “the DATAGRAM frame type” (singular) “is the LEN bit”. Seems to me you should make up your mind: either you have two types, 0x30 and 0x31, whose semantics differ with respect to the Length field, OR you have a single type and a flag. 

Really I think you have two types (witness the IANA allocation: two, not one) and the characterization of the LSB as a flag is just a distraction, I would remove it. Clearly that doesn’t prevent an implementor from taking advantage of the structure if they want to, but I think it would clean up some awkwardness in the prose.

3. Further to that, in Section 4 you say,

               The DATAGRAM frame type takes the form 0b0011000X
   (or the values 0x30 and 0x31).

It took me an embarrassingly long time to recognize that the first form you list means “binary 0011000x, where x indicates ‘don’t care’”. I suppose maybe I was slow because we use hex notation all the time in our document set, and binary notation exceedingly seldom in my experience. Possibly I am the only person who will stumble on this. But possibly not. In any case if you were to clean up my “is it one type, or two” complaint by collapsing the waveform to “it’s two”, this problem would also go away.

4. In Section 5 you say,

   When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD
   deliver the data to the application immediately, as long as it is
   able to process the frame and can store the contents in memory.

Isn’t the final clause in the category of “well, duh”? I mean, is there a situation in which a QUIC endpoint is *not* able to process the frame or *not* able to store the contents in memory, but still might be expected to deliver the data to the application? Seems like that’d be a “no”. 

I mean, the remark does no real harm, but why bother stating the obvious?
Murray Kucherawy
No Objection
Comment (2022-02-01 for -08) Sent
Section 3:

* "... transport parameter greater or equal to ..." -- s/greater/greater than/  (two instances)

Section 4:

* I also tripped on the thing John pointed out.

Section 5:

* I don't understand the two SHOULDs in this section.  When/why would you ever do otherwise?
Warren Kumari
No Objection
Comment (2022-02-02 for -08) Sent
Something that would make this document *much* more understandable, especially for those of us who are not so bright, is that QUIC datagrams are not just QUIC carrying UDP.
The document says:
"In the past, these applications have built directly upon UDP [RFC0768] as a transport,
and have often added security with DTLS [RFC6347].  Extending QUIC to support transmitting
unreliable application data provides another option for secure datagrams, with the added
benefit of sharing the cryptographic and authentication context used for reliable streams." 

Even though I knew that this isn't just tunneling UDP over QUIC, the above description and use of the term "datagram" (which has become synonymous with UDP) keeps making me forget that.
I don't have any suggested text, but something like a "Note: This is a QUIC transport to carry unreliable data natively, and does not encapsulate UDP packets" or something. 

Also, much thanks to Jürgen Schönwälder for his OpsDir review of -07, and the authors for addressing the comments.

I wanted to confirm that the authors had seen that Jürgen followed up with an additional review of -08 (much thanks Jürgen!) at
Benjamin Kaduk Former IESG member
(was Discuss) Yes
Yes (2022-01-28 for -08) Sent for earlier
Thanks for resolving my previous remarks!
Martin Duke Former IESG member
Yes (for -08) Not sent

Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Not sent

Lars Eggert Former IESG member
No Objection
No Objection (2022-02-03 for -08) Sent
Section 5.2. , paragraph 5, comment:
>    If a sender detects that a packet containing a specific DATAGRAM
>    frame might have been lost, the implementation MAY notify the
>    application that it believes the datagram was lost.
>    Similarly, if a packet containing a DATAGRAM frame is acknowledged,
>    the implementation MAY notify the sender application that the
>    datagram was successfully transmitted and received.  Due to

Being able to emit these notifications seem to depend on structuring the API
between the implementation and the application so that not only opaque datagram
blobs are exchanged, but that they are also associated with some sort of

Thanks to Meral Shirazipour for their General Area Review Team (Gen-ART) review

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Table of Contents", paragraph 2, nit:
> . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . .
>                              ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgment" and "acknowledgement")
within a single text.

"Table of Contents", paragraph 2, nit:
> s, and each frame type defines whether or not the data it contains will be r
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".
Martin Vigoureux Former IESG member
No Objection
No Objection (for -08) Not sent

Robert Wilton Former IESG member
No Objection
No Objection (for -08) Not sent