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.
