Subject: Éric Vyncke's Yes on draft-ietf-quic-datagram-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 02 Feb 2022 03:20:46 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-quic-datagram-08: Yes

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:
----------------------------------------------------------------------

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,

Regards,

-éric

## 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.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 02 Feb 2022 07:27:08 -0800

Hi Eric,

Thanks for your review! Responses are inline.

> On Feb 2, 2022, at 3:20 AM, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 

It certainly should be possible to have a max_datagram_frame_size below 20 bytes. The meaning of the datagram is not defined by this document, and will be different per application. Something that encapsulates IP packets may need a bigger size, but even the CONNECT-UDP usage that just contains UDP payloads could theoretically have a smaller max size (since there is no minimum size for the payload of a UDP datagram).

> prefer the first paragraph of section 19.3 of RFC 9000.

DATAGRAM is following the form of STREAM frames, since they are equivalent in how they encode their frame type.

Please see https://datatracker.ietf.org/doc/html/rfc9000#section-19.8 <https://datatracker.ietf.org/doc/html/rfc9000#section-19.8>

"STREAM frames implicitly create a stream and carry stream data.  The
   Type field in the STREAM frame takes the form 0b00001XXX (or the set
   of values from 0x08 to 0x0f).”

I believe keeping the DATAGRAM text as a mirror of the STREAM text is most appropriate.

>   relative priorities to DATAGRAM frames with respect to each other and

Can you clarify the contradiction you see?

That first paragraph says:

"When an application sends a datagram over a QUIC connection, QUIC will generate a new DATAGRAM frame and send it in the first available packet. This frame SHOULD be sent as soon as possible, and MAY be coalesced with other frames."

That does not mean that priorities are not useful. When we say it should be sent as soon as possible, that may not be immediate due to needing to wait for a congestion control window to open, or packet pacing to allow sending a packet. The relative priorities allows the QUIC implementation to order any pending DATAGRAM frames before sending them out.

Best,
Tommy

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 2 Feb 2022 16:12:41 +0000

Hello Tommy

Thank you for a prompt and early reply.

As you know, my comments were not blocking anyway, so, I appreciate your time to reply. Look after EV>

Regards

-érc

From: Tommy Pauly <[email-masked]>
Date: Wednesday, 2 February 2022 at 16:27
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's Yes on draft-ietf-quic-datagram-08: (with COMMENT)

Hi Eric,

On Feb 2, 2022, at 3:20 AM, Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

-éric

## Section 3

EV> fair enough indeed. Could be anything not only IP packets (I was really thinking about the VPN use case !)

## Section 4

Please see https://datatracker.ietf.org/doc/html/rfc9000#section-19.8

EV> your argument (follow the STREAM) syntax has indeed more value than mine (be readable)

## Section 5.1

EV> suggest to add some text after "as soon as possible" about following the congestion & priority control

Best,
Tommy