Hi Eric, Thanks for your review! Responses are inline.
> On Feb 2, 2022, at 3:20 AM, Éric Vyncke via Datatracker <[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). > > ## 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 <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. > > ## 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." 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 > > >
