Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Wed, 06 January 2021 17:43 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44A3A1076; Wed, 6 Jan 2021 09:43:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-quic-transport@ietf.org, quic-chairs@ietf.org, quic@ietf.org, quic-chairs@ietf.org, lars@eggert.org
Subject: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <160995499362.18437.16175887825588198380@ietfa.amsl.com>
Date: Wed, 06 Jan 2021 09:43:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vHZBoz6jEnb7HrfFomOT7BG7ni0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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 17:43:14 -0000
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? 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. 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? 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. 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. 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. 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. 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. 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, ... 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". 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. 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? 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. 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. 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"?
- Robert Wilton's Discuss on draft-ietf-quic-transp… Robert Wilton via Datatracker
- Re: Robert Wilton's Discuss on draft-ietf-quic-tr… Lucas Pardue
- Re: Robert Wilton's Discuss on draft-ietf-quic-tr… Martin Thomson
- Re: Robert Wilton's Discuss on draft-ietf-quic-tr… Mikkel Fahnøe Jørgensen
- RE: Robert Wilton's Discuss on draft-ietf-quic-tr… Rob Wilton (rwilton)