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 protected]> Date: Wednesday, 2 February 2022 at 16:27 To: Eric Vyncke <[email protected]> Cc: The IESG <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Éric Vyncke's Yes on draft-ietf-quic-datagram-08: (with COMMENT) Hi Eric, Thanks for your review! Responses are inline. On Feb 2, 2022, at 3:20 AM, Éric Vyncke via Datatracker <[email protected]<mailto:[email protected]>> wrote: É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) 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). EV> fair enough indeed. Could be anything not only IP packets (I was really thinking about the VPN use case !) ## 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. 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 "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. EV> your argument (follow the STREAM) syntax has indeed more value than mine (be readable) ## 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. 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." EV> suggest to add some text after "as soon as possible" about following the congestion & priority control 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
