Hi Ben, Quick follow-up: we've now merged your PR so we should be good to clear your DISCUSS.
Thanks, David On Fri, Jan 28, 2022 at 2:55 PM David Schinazi <[email protected]> wrote: > Thank you for your review Ben. Responses inline. > > David > > On Fri, Jan 28, 2022 at 2:23 PM Benjamin Kaduk via Datatracker < > [email protected]> wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 5 refers to a "max_packet_size" transport parameter but I do not >> see that parameter defined in the registry or RFC 9000. >> It seems that a transport parameter of that name was present in earlier >> versions of draft-ietf-quic-transport, but got renamed to >> max_udp_payload_size in the -28, so hopefully this is just a trivial >> rename. >> > > You're absolutely right, we missed the rename and will fix this by > landing your PR #76. > > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I put some editorial suggestions (including the presumed resolution of the >> DISCUSS) on github at https://github.com/quicwg/datagram/pull/76 . >> > > Thanks, let's discuss those on the PR. > > Section 2 >> >> * QUIC uses a more nuanced loss recovery mechanism than the DTLS >> handshake, which has a basic packet loss retransmission timer. >> >> This is true of DTLS 1.2 and prior versions, which technically is right >> now the current version of DTLS. However, it's not quite true of DTLS >> 1.3, which includes an explicit ACK message to supplement the >> retransmission timer. DTLS 1.3 stands a pretty decent chance of being >> published as an RFC prior to this document (per ekr, it should have the >> last technical changes from the WG finalized this weekend and then go into >> the "real" AUTH48 state), so I think we ought to speak to the mechanisms >> of DTLS 1.3 here. >> > > How about we just remove "which has a basic packet loss retransmission > timer"? > I think it's safe to say that QUIC congestion control is more nuanced than > that of > any version of DTLS, including DTLS 1.3. > > Section 3 >> >> For most uses of DATAGRAM frames, it is RECOMMENDED to send a value >> of 65535 in the max_datagram_frame_size transport parameter to >> indicate that this endpoint will accept any DATAGRAM frame that fits >> inside a QUIC packet. >> >> It's interesting to compare this to the RFC 9000 max_udp_payload_size >> default of 65527, the maximum permitted UDP payload. Indeed, the QUIC >> 1-RTT packet header does not even contain a length field that would limit >> the frame size. So I'm not entirely sure what motivates the 65535 value >> specifically. (I do see the subsequent discussion about how there are >> other factors, including max_packet_size/max_udp_payload_size, that can >> further limit what is usable.) >> > > We picked that value because it means "don't limit the length" and doesn't > involve thinking about header sizes or doing math. >
