Benjamin Kaduk's Discuss on draft-ietf-quic-datagram-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-quic-datagram-08: Discuss

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/



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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I put some editorial suggestions (including the presumed resolution of the
DISCUSS) on github at https://github.com/quicwg/datagram/pull/76 .

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.

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