Subject: Warren Kumari's No Objection on draft-ietf-quic-datagram-08: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 02 Feb 2022 11:31:37 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-quic-datagram-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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
https://datatracker.ietf.org/doc/review-ietf-quic-datagram-08-opsdir-telechat-schoenwaelder-2022-01-31/

---

From: David Schinazi <[email-masked]>
Date: Wed, 2 Feb 2022 12:14:37 -0800

Hi Warren,

Thanks for your comment. It's unfortunate that some folks
have a mental association from "datagram" to "UDP", but
at the end of the day that's not necessarily the target
audience. This document is aimed at implementers of
QUIC who do know top-of-mind that you can build a reliable
transport over UDP, and have unreliable transmission
outside of UDP. I understand what you're trying to accomplish
with your proposed text, but unfortunately I suspect that'll
introduce more confusion, because in some cases you
can tunnel UDP inside QUIC datagrams.

Thanks for the reminder about the opsdir review, I just
replied to that.

Cheers,
David

---

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Feb 2022 10:36:14 -0500

> can tunnel UDP inside QUIC datagrams.

John Scudder suggested that "For clarity, in this document we are using
'datagram' with its normal sense of 'a self-contained unit of data
transmitted in a packet-switched network'. One example of a type of
datagram is UDP; however, this specification is not restricted to any
particular variety of datagram." might work.

It still seems to me that *some* warning to help people not trip over the
pointy bits would help, but also (clearly) I'm not going to die on this
hill...

W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 04 Feb 2022 13:55:56 -0800

> On Feb 3, 2022, at 7:36 AM, Warren Kumari <[email-masked]> wrote:
> 
> 
> 
> On Wed, Feb 2, 2022 at 3:14 PM David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Warren,
> 
> John Scudder suggested that "For clarity, in this document we are using 'datagram' with its normal sense of 'a self-contained unit of data transmitted in a packet-switched network'. One example of a type of datagram is UDP; however, this specification is not restricted to any particular variety of datagram." might work.
> 
> It still seems to me that *some* warning to help people not trip over the pointy bits would help, but also (clearly) I'm not going to die on this hill...

The editors discussed this, and we feel that this kind of statement might end up being more confusing in context. The document currently defines what is carried as “unreliable application data”; specifically, bringing in any definition that refers to “packet-switched networks” would start to imply that this frame is only meant for tunneling data blobs that would otherwise be transmitted directly.

Section 2, which covers the motivation, explains several use cases — real time applications, media content, and tunneling of entire IP packets. We feel that this list (and the fact that it never mentions trying to tunnel UDP payload content) is sufficient to avoid making it seem that this can only contain what would otherwise be UDP payloads.

Best,
Tommy
> On Wed, Feb 2, 2022 at 11:31 AM Warren Kumari via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://www.ietf.org/blog/handling-iesg-ballot-positions/>
> https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/ <https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/>
> 
> 
> 
> https://datatracker.ietf.org/doc/review-ietf-quic-datagram-08-opsdir-telechat-schoenwaelder-2022-01-31/ <https://datatracker.ietf.org/doc/review-ietf-quic-datagram-08-opsdir-telechat-schoenwaelder-2022-01-31/>
> 
> 
> 
> 
> 
> --

---

From: Warren Kumari <[email-masked]>
Date: Fri, 4 Feb 2022 17:25:23 -0500

On Fri, Feb 4, 2022 at 4:56 PM Tommy Pauly <[email-masked]> wrote:

> The editors discussed this, and we feel that this kind of statement might
> end up being more confusing in context.
>

Okey dokey,
W

> The document currently defines what is carried as “unreliable application
> data”; specifically, bringing in any definition that refers to
> “packet-switched networks” would start to imply that this frame is only
> meant for tunneling data blobs that would otherwise be transmitted directly.
>
> Section 2, which covers the motivation, explains several use cases — real
> time applications, media content, and tunneling of entire IP packets. We
> feel that this list (and the fact that it never mentions trying to tunnel
> UDP payload content) is sufficient to avoid making it seem that this can
> only contain what would otherwise be UDP payloads.
>
> Best,
> Tommy
>
>
> W
>
>
>>
>>> Please refer to
>>> https://www.ietf.org/blog/handling-iesg-ballot-positions/