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

[Éric Vyncke via Datatracker <[e-mail]>]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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