Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 07 January 2021 02:54 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 6B02B3A0964; Wed, 6 Jan 2021 18:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 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, RCVD_IN_DNSWL_BLOCKED=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 Azl_s8BvW3IO; Wed, 6 Jan 2021 18:54:10 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 2616F3A1290; Wed, 6 Jan 2021 18:54:10 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id j16so6381706edr.0; Wed, 06 Jan 2021 18:54:10 -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=ak82pQ56lqxoYEuANfvS2PGavKtZZ37xciJZHhyV7p4=; b=a8t9WdTenJ//J2Bwfzfh5EK8zGFt2zOVbpyPWftPb53cLB0u3CYzTuOi40MQ9o+i8d RWQNJeRmazwAQ7DMW0hy838aLDss8ZNRsKLTLb5Lp92QXTQIuyhocfySYf3NTdI7i3ta cM2Axv+WzYDiIBKquInXILWtf400GcgEIq/VJiikDLspkGIaVfWJPkNrfRTaMZ4YGlUv r0ltlpSkZdD4EtRmVhOcZMGtEihMKa07Pfz9bdLMy9FO3rkN/7NNVFQfQkqfzl0Bwez4 LKtYluQGUM5pu7TZVI5t+I7uhE930SafB/nFOyIaXnPACyRW0YkVsaKB8ArrO3RVgHao Ow8w==
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=ak82pQ56lqxoYEuANfvS2PGavKtZZ37xciJZHhyV7p4=; b=DeZAuFMAsTQGbHLODgCIf7Gcg18isv2+HofOkprLYm2S+rc98PS4N/T1ztxzIkGpR2 gQMJadIUEGNks6s4Wo7DxBXGYHy56IWQMhdwja/bwiFx+K2lC+GDJvki8uzQcVXkgOQs 1b2o48XtgbLJgQR4y8gYXVNf3EY45ACQqodP9S2f3as6XyTE+LF5y+HfM8L1HtqtLe1U lY4L50/VrGQ2qek3Y/QyzQLgydiGZEzIgFAU5NqJGAFCStYmvUk23CTG/MiOwAeC8Obe m1a+pdaeF6+MsvGyie3EidEEl7m5oA8Ps/1tPdUuKvIr09oNEkZePMQ77/V/MicrXOmT Zrkg==
X-Gm-Message-State: AOAM5310eOA4nlL0btVxPDnXOpS8toysQ5UJzzMlZf7rM4t1a5A3rptH H+5Qh5MtBBd6EDRbPgYe8x3hNHZfFM+Ljp+ZMck=
X-Google-Smtp-Source: ABdhPJwtNVVJl42XjDHRv679Rka+Dyi0XDV5zRP8zE8i6MoAVKXnDk/8k701XFE5ead2+/UWhs60YN5UNP5620KO5rE=
X-Received: by 2002:aa7:dcd0:: with SMTP id w16mr41372edu.229.1609988048563; Wed, 06 Jan 2021 18:54:08 -0800 (PST)
MIME-Version: 1.0
References: <160995499362.18437.16175887825588198380@ietfa.amsl.com>
In-Reply-To: <160995499362.18437.16175887825588198380@ietfa.amsl.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 7 Jan 2021 02:53:57 +0000
Message-ID: <CALGR9oZCg8_003ZS3v0wZoeTYP4JzofLMUq+P=OmxFPzVRamsA@mail.gmail.com>
Subject: Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
To: Robert Wilton <rwilton@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>
Content-Type: multipart/alternative; boundary="000000000000ba309105b8468df0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LQkHiadY3chKolcjvXReo7G8zkQ>
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: Thu, 07 Jan 2021 02:54:13 -0000

Hi Rob,

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.

On Wed, Jan 6, 2021 at 5:43 PM Robert Wilton via Datatracker <
noreply@ietf.org> wrote:

> Robert Wilton has entered the following ballot position for
> draft-ietf-quic-transport-33: 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/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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> With so many "Yes" votes from other ADs, I feel like I'm swimming against
> the
> flow by raising a discuss ...
>
> Firstly, I would like the thank the authors and WG on such a well written
> document.  I am  supportive of this protocol and hope that it will be good
> for
> the Internet.
>
> However, I do have some discuss questions relating to the Spin Bit and the
> ability to manage and monitor networks.  I appreciate that there has
> already
> been a lot of (presumably heated) discussion on the spin bit, which I've
> not
> read or participated in, but I am concerned about the operational
> manageability
> aspect of QUIC.
>
> Firstly, I have two comments on clarifying the spin bit
> behaviour/specification:
>
> 1) It would be helpful to clarify what the expected behaviour is for an
> implementation that chooses not to support the spin-bit.  Does it just
> leave
> the bit set as 0, or is it meant to follow the same behaviour as if
> spin-bit is
> supported but disabled?
>

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


>
> 2) This may not be discuss worthy, but some of the spin bit behaviour is
> inconsistently defined between the quic transport and quic manageability
> drafts.  Specifically:
>   - The transport draft states that at least 1 in 16 connections "MUST"
> disable
>   spinning, whereas the manageability draft states this as "recommended".
> - In
>   the case that the spin bit is disabled, the transport draft uses
>   "RECOMMENDED" to use a random value for each packet, or chosen
> independently
>   for each connection.  Whereas the manageability draft uses "can" and
> lists
>   the two options in the opposite order.
>
>   For this review, since it is in IESG review, I've presumed that the
> transport
>   draft has the definitive definitions and the manageability draft is
> lagging.
>

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


> But my two main discuss questions/comments relate to whether the spin-bit,
> as
> specified in quic transport, achieves its goal.  I appreciate that there
> are
> individuals who don't think that it is required at all, conversely some
> network
> operators believe that they will lose vital information needed to help
> manage
> their networks, and presumably we are trying to find a pragmatic compromise
> between these two positions.
>
> 1) I find it hard to understand why a server is allowed to independently
> decide
> whether or not to support the spin bit on a connection?  Shouldn't the
> client
> (or administrator of the client system) that opened the connection be able
> to
> choose whether they want the RTT to be monitorable via the spin bit?  What
> is
> the reasoning for allowing the server (or server administrator) to be able
> to
> independently be able to decide what is best for the client?
>

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


> 2) In the case that the spin-bit is disabled, I don't understand the
> benefit of
> injecting a random spin bit value in each packet rather than always
> setting it
> to a per connection random value.  It seems that whether or not the
> randomness
> is injected, it is expected to be feasible to extract the RTT for those
> connections that are genuinely spinning the bit (or otherwise the spin bit
> is
> entirely pointless), but it just seems to make it computationally harder to
> extract the signal from the noise.  Perhaps the goal here is reduce the
> ability
> for pervasive monitoring to occur, but that feels a bit like security
> through
> obscurity.
>

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


> Some enlightenment for these questions would be appreciated.
>
> Regards,
> Rob
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Comments:
>
>     1.2.  Terms and Definitions
>
>     Frame: A unit of structured protocol information. There are multiple
> frame
>     types, each of which carries different information. Frames are
> contained in
>     QUIC packets.
>
> Perhaps indicate that a quic packet can contain multiple frames?  The
> terminology states that a datagram contains multiple quick packets, but it
> wasn't obvious to me that a quick packet can contain multple frames.
>

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


>     This document uses the terms "QUIC packets", "UDP datagrams", and "IP
>     packets" to refer to the units of the respective protocols. That is,
> one or
>     more QUIC packets can be encapsulated in a UDP datagram, which is in
> turn
>     encapsulated in an IP packet.
>
> Frame is a widely used term in L2.  Hence, it might be helpful if this
> description also covered "Frames".  Perhaps this would also be a helpful
> place
> (or an alternative place) to mention that a QUIC packet contains one or
> more
> QUIC frames.
>

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


>     3.  Stream States
>
>     Bidirectional streams use both state machines
>
> Maybe clarify this to indicate that it means that both state machines are
> used
> at each endpoint.  Otherwise, even unidirection steams use both state
> machines,
> one at each endpoint.
>

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


>     3.2.  Receiving Stream States
>
>     Figure 3: States for Receiving Parts of Streams
>
> Perhaps expand "App Read RST" to "App Read RESET", since there doesn't
> seem a
> great reason to abbreviate it.
>

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


>     3.2.  Receiving Stream States
>
>     The receiving part of a stream enters the "Recv" state when the
>     sending part of a bidirectional stream initiated by the endpoint
>     (type 0 for a client, type 1 for a server) enters the "Ready" state.
>
> This might be slightly clearer if the conditional predicate was moved to
> the
> beginning of the sentence.  E.g., For bidirectional streams, ...
>
>
https://github.com/quicwg/base-drafts/issues/4674


>     4.1.  Data Flow Control
>
>     * Stream flow control, which prevents a single stream from consuming
> the
>     entire receive buffer for a connection by limiting the amount of data
> that
>     can be sent on any stream
>
> Perhaps "on a stream" would be better than "on any stream".
>

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


>     4.6.  Controlling Concurrency
>
>     An endpoint that is unable to open a new stream due to the peer's
> limits
>     SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This signal is
>     considered useful for debugging. An endpoint MUST NOT wait to receive
> this
>     signal before advertising additional credit, since Iyengar & Thomson
>     Expires 16 June 2021 [Page 29] Internet-Draft QUIC Transport Protocol
>     December 2020 doing so will mean that the peer will be blocked for at
> least
>     an entire round trip, and potentially indefinitely if the peer chooses
> not
>     to send STREAMS_BLOCKED frames.
>
> By additional credit, does it sending MAX_STREAMS?  If so, it might be
> helpful
> to clarify that.
>

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

>
>     5.1.  Connection ID
>
>     5.1.1.  Issuing Connection IDs
>
>        Additional connection IDs are communicated to the peer using
>        NEW_CONNECTION_ID frames (Section 19.15).  The sequence number on
>        each newly issued connection ID MUST increase by 1.  The connection
>        ID randomly selected by the client in the Initial packet and any
>        connection ID provided by a Retry packet are not assigned sequence
>        numbers unless a server opts to retain them as its initial
> connection
>        ID.
>
> I was slightly confused by the "The connection ID randomly selected by the
> client".  Elsewhere in section 5.1 it says that connection id allocation
> are
> implementation specific.  Are there any constraints on how connection ids
> can
> be allocated (other than not repeating as already stated).  E.g., could an
> implementation just allocate them as integers starting at 1?  Or can all
> connection ids (including NEW_CONNECTION_IDs) be randomly allocated?
>

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

>
>     16. Variable-Length Integer Encoding
>
>     No requirement to send integers in smallest encoding possible?  E.g.
> okay
>     to send the value 3 in an 8 byte field?
>
> This section doesn't indicate whether a sender is allowed to send integers
> not
> using the smallest possible encoding, and doesn't indicate whether a
> receive is
> expected to process non optimal encodings.  It might be helpful to be
> explicit.
>

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



>     17.  Packet Formats
>
>     Version: The QUIC Version is a 32-bit field that follows the first
> byte.
>     This field indicates the version of QUIC that is in use and determines
> how
>     the rest of the protocol fields are interpreted.
>
> By "rest of the protocol fields", I had incorrectly interpreted this as
> meaning
> all subsequent fields described after the version field are determined
> Perhaps worth clarifying - although I recall that it does become clear
> elsewhere.
>

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


>     17.  Packet Formats
>
>     Type-Specific Bits: The lower four bits (those with a mask of 0x0f) of
> byte
>     0 are type-specific
>
> Perhaps "packet type specific" rather than just "type-specific"?
>

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

Cheers,
Lucas
On behalf of QUIC WG Chairs