Re: Éric Vyncke's No Objection on draft-ietf-quic-transport-33: (with COMMENT)

[Lucas Pardue <[e-mail]>]

Hi Éric,

Thanks for the review. I've captured your comments as issues on the QUIC WG
GItHub repository. Links to each are provided as in-line responses.

I apologize for spelling your name with a 'k' not a 'c'. I've realized this
only at the end of the issue-making process. I was so focused on getting
the accent correct I missed that part. I'll get this fixed up soon.

On Tue, Jan 5, 2021 at 11:12 AM Éric Vyncke via Datatracker <
[e-mail]> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-quic-transport-33: No Objection
>
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this long but easy to read document. It is
> clearly a major change for the Internet.
>
> Special thanks to Bernie Volz for his internet directorate review.
>
> I support Erik Kline's comments about sections 9.6.3 (interaction of NAT64
> and
> preferred address) and 14.1 (IPv6 extension headers).
>
> Please bear with some comments from a non-transport oriented person... I
> have
> yet to review QUIC-RECOVERY so I will assume for now that packet loss by
> the
> network (such as RED) will also reduce the "QUIC congestion window".
>
> NB: I still wonder why QUIC is in upper case if it is a name and not an
> acronym
> ;-)
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated), and some nits.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> -- Section 1 --
> "QUIC packets are carried in UDP datagrams ([UDP]) to better facilitate
> deployment in existing systems and networks.", this is an assumption
> presented
> as a fact without citing any reference... This does not seem too good to
> me.
>

https://github.com/quicwg/base-drafts/issues/4524


> -- Section 2.2 --
>   "an endpoint MAY treat receipt of different data at
>    the same offset within a stream as a connection error of type
>    PROTOCOL_VIOLATION."
>
> Should it be a SHOULD or even a MUST rather than a MAY ? Even if streams
> are
> protected, isn't it a security issue to allow overwrite of a stream ? Esp
> when
> the endpoints could deliver out-of-order to the application ?
>

https://github.com/quicwg/base-drafts/issues/4525


> -- Section 3.1 (and others) --
> It would have been nice to use the SVG alternate graphic format for such an
> fundamental document ;-)
>

https://github.com/quicwg/base-drafts/issues/4526


> -- Section 4.2 and others  --
> The specification is rather vague about the behavior (no default timer, no
> default "window", nothing said about increasing the credit, ...) and
> leaves a
> lot to implantations. Is it an issue or is it described in QUIC-RECOVERY ?
>

https://github.com/quicwg/base-drafts/issues/4527


> -- Section 5.1 --
> It would be nice for the reader to explain the rationale for having
> multiple
> connection IDs for the same connection.
>

https://github.com/quicwg/base-drafts/issues/4528


> -- Section 7 --
> Please state before that QUIC version 0x00000001 is the version specified
> by
> the document or use "This version of QUIC" rather than "Version 0x00000001
> of
> QUIC"
>
>
https://github.com/quicwg/base-drafts/issues/4529

-- Section 8.1 --
> Out of curiosity, why selecting a UDP payload of at least 1200 octets? I
> would
> assume that 1232 would have worked as well (1280 IPv6 MTU - 40 IPv6 header
> - 8
> UDP header). Of course, 1200 is a nicer number ;-)
>

https://github.com/quicwg/base-drafts/issues/4530


> -- Section 9 (and also 9.4 and possibly others) --
> Please also consider adding another reason for an endpoint to change its
> IPv6
> address due to RFC 4941 ("privacy extensions for IPv6 addresses") and not
> only
> NAT ;-)
>

https://github.com/quicwg/base-drafts/issues/4531


> -- Section 9.1 --
> Can this mechanism also be used not only when changing of IP address but
> also
> of IP version ?
>
> Did the QUIC WG/authors consider using happy eyeball (RFC 8305) to probe
> whether IPvfoo could become better than IPvbar regularly during a QUIC
> connection (using the preferred addresses) ?
>

https://github.com/quicwg/base-drafts/issues/4532


> -- Section 9.7 --
> Why a SHOULD for the use of a hash, IMHO a good pseudo-random number would
> also
> work (as explained in RFC 6437).
>

https://github.com/quicwg/base-drafts/issues/4533


> -- Section 13 --
> Should the text provide a forward reference to section 14 (datagram size) ?
>

https://github.com/quicwg/base-drafts/issues/4534


> -- Section 14.1 --
> This padding on the initial packets is quite a smart technique ;-)
>

https://github.com/quicwg/base-drafts/issues/4535


> -- Section 17.2.1 --
> I find a little weird that the "unused" field have a SHOULD setting for the
> MSB... Suggest to keep the F bit apart and use a 6-bit "unused" field.
>

https://github.com/quicwg/base-drafts/issues/4536


> -- Section 18.2 --
> I am not a transport expert, so, I can be wrong but usually, rather than
> using
> "::.0",  "[::]:0" is used.
>

https://github.com/quicwg/base-drafts/issues/4537


> -- Section 19.2 --
> Suggest to also mention "keeping NAT binding states alive" as a use case
> for
> PING.
>

https://github.com/quicwg/base-drafts/issues/4538


> == NITS ==
>
> -- Section 1 --
> In "QUIC authenticates all packets and encrypts as much as is practical."
> it is
> a little unclear to me whether the 'as much' applies only to 'encrypts' or
> also
> on 'authenticates'. Or is it clear for an English-native speaker (that I am
> not).
>

https://github.com/quicwg/base-drafts/issues/4539


> -- Section 1.3 --
> Rather than using "described by ?" why not using the letter 'l' (as in
> length)
> rather than a '?'. It is confusing at first sight.
>

https://github.com/quicwg/base-drafts/issues/4540


> -- Section 4.5 --
> "the final size is the number of bytes sent" is slightly ambiguous as it
> could
> either be the number of bytes sent by the application or sent as UDP
> payload.
> The rest of the paragraph kind of answers the question though.
>

https://github.com/quicwg/base-drafts/issues/4541


> -- Section 5.2.2 --
> "If a server receives a packet that indicates an unsupported version but is
> large enough to initiate a new connection" it is unclear what is the
> subject of
> "is"...
>

https://github.com/quicwg/base-drafts/issues/4542


> -- Section 6.3 --
> The use of "0x?a?a?a?a" with undefined syntax brings only question marks
> in the
> reader's mind => suggest to remove "0x?a?a?a?a" but keep the forward
> pointer to
> section 15.
>

https://github.com/quicwg/base-drafts/issues/4543


> -- Section 8.2 --
> Why using "two-tuple" rather than the simpler "pair" ?
>

https://github.com/quicwg/base-drafts/issues/4544


> -- Section 23.1 --
> Why using the anchor [IPv4] rather than [RFC791] ? Just curious...
>

https://github.com/quicwg/base-drafts/issues/4545

Cheers,
Lucas
On behalf of QUIC WG Chairs