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

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 06 January 2021 04:00 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE20D3A0BEB; Tue, 5 Jan 2021 20:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_x_g7H2fXZO; Tue, 5 Jan 2021 20:00:36 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A1F3A0BEE; Tue, 5 Jan 2021 20:00:35 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id y24so3095996edt.10; Tue, 05 Jan 2021 20:00:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kZvLtUjUUhOL1k6J+T+F1ziTXW8X4NThOrQ+dbS4tmk=; b=vfeLvSzJAS20VFphu964+yNqeBWB63teZE+2wJBLD5nYZavH4478WcGEveNfYvXmA2 TezKyQselCSpPYMkeEBLK6YYylEDBkgL4rkbdXLRner2QlqO3p0TswETXadeSeB9OHG3 udOGdFT1ssTJBPVjzLznsxUp4pwdNAw0frCaPmWFX4mzYcCffbyKhgwwUKVctSkBAFAm gGaHx06JqXCBiY7NiRQb54fYWdE5fMhX8CKhcaSyB1nCeuuw1FyCz/K1vaazyy87+8EQ M+jnMHFuKtdwsGs7drQI5I3kJjchyA1s6gOyEAx/uf4Px/6tVlEQ/JUUlZhxmVDPXn+3 khGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kZvLtUjUUhOL1k6J+T+F1ziTXW8X4NThOrQ+dbS4tmk=; b=dr8XSTZ9fEocBTynI16Guk37PADoHT5xf70ak6TvFu3mQOqQMhLIaMLMYa7iV9JSA9 SKuAyWuOLqLdYcDvmItViAWWvJ7//pcOP8FdNjJEuBl3KlheV6a+QOBKLOLyaUnd1smM YhMYlJ9ruLL0TFSscomDgGKQxQ2O9NQOO5u6HZksAhDDEcoibm6r6xzo2QcHCuBjZtbC tWHGGHtbv37VwM1R/YOFov3ngbNcBTpGImoGS8bm0i3pPIlj5AXkcPH7zvc6gErasw5q rGrH64hnZztEdp9O/RPZZ6Yjzfj/i3OMAFlwTEU/oM1DKQUCdi/ZPjzbQKULJcVhPERH TqqQ==
X-Gm-Message-State: AOAM533fMZS3168QG5lDt9hHj1aMsKToQIA74hbVcLc/az0ZPNteg/TA mbNWw8gLhGQ4UU9EtVuBj9tDSHSKtQu7DrE8qStls1vFImjzJw==
X-Google-Smtp-Source: ABdhPJx9IZxYGIPWcPX1895sXtagY6JaxynSzyRs194vhhBOD0ik/Jx2xgHQxT0zToryeolu9sAwPYUHXteVMZhPFxk=
X-Received: by 2002:aa7:dcd0:: with SMTP id w16mr2620914edu.229.1609905634572; Tue, 05 Jan 2021 20:00:34 -0800 (PST)
MIME-Version: 1.0
References: <160984514294.16831.9541196598331741661@ietfa.amsl.com>
In-Reply-To: <160984514294.16831.9541196598331741661@ietfa.amsl.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 06 Jan 2021 04:00:23 +0000
Message-ID: <CALGR9obsCX9t9WV=Z0MxT072nB2vpGp4G+gjJCkf-QQ=A5NUYw@mail.gmail.com>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-quic-transport-33: (with COMMENT)
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-quic-transport@ietf.org, WG Chairs <quic-chairs@ietf.org>, QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>, volz@cisco.com
Content-Type: multipart/alternative; boundary="000000000000787c9205b8335d02"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2PRwCVGon0r3aaKEhx2wHJRpYOw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2021 04:00:39 -0000

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 <
noreply@ietf.org> 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