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

[David Schinazi <[e-mail]>]

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 <[e-mail]>
wrote:

> Thank you for your review Ben. Responses inline.
>
> David
>
> On Fri, Jan 28, 2022 at 2:23 PM Benjamin Kaduk via Datatracker <
> [e-mail]> 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.
>