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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 28 Jan 2022 14:23:36 -0800

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

---

From: David Schinazi <[email-masked]>
Date: Fri, 28 Jan 2022 14:55:57 -0800

Thank you for your review Ben. Responses inline.

David

You're absolutely right, we missed the rename and will fix this by
landing your PR #76.

> COMMENT:

Thanks, let's discuss those on the PR.

Section 2
> the "real" AUTH48 state), so I think we ought to speak to the mechanisms

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

---

From: David Schinazi <[email-masked]>
Date: Fri, 28 Jan 2022 15:00:14 -0800

Hi Ben,

Quick follow-up: we've now merged your PR so we should be good to clear
your DISCUSS.

Thanks,
David

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 28 Jan 2022 15:09:18 -0800

> You're absolutely right, we missed the rename and will fix this by

Excellent, I'm glad this was the easy option, and as you note in the
follow-up, it's fixed in the editor's copy already, so I'll go clear now.

> any version of DTLS, including DTLS 1.3.

That seems reasonable.  I agree that QUIC CC is clearly more nuanced than
DTLS of any version.  And the value of going into any level of detail about
what DTLS actually does provide seems pretty minimal.

> involve thinking about header sizes or doing math.

Okay.  I can't fault that, even if it seems that since we're bounded by
max_udp_payload_size we could just as easily reuse the 65527 value.

Thanks for the quic(k) turnaround!

-Ben

---

From: David Schinazi <[email-masked]>
Date: Fri, 28 Jan 2022 15:26:53 -0800

> what DTLS actually does provide seems pretty minimal.

Thanks. I've now made that change to the editor's copy.

David