[Taps] Benjamin Kaduk's Discuss on draft-ietf-taps-minset-08: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Thu, 13 September 2018 00:38 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: taps@ietf.org
Delivered-To: taps@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBDA129385; Wed, 12 Sep 2018 17:38:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-taps-minset@ietf.org, Theresa Enghardt <theresa@inet.tu-berlin.de>, taps-chairs@ietf.org, theresa@inet.tu-berlin.de, taps@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153679913425.9530.5444017312043760775.idtracker@ietfa.amsl.com>
Date: Wed, 12 Sep 2018 17:38:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/OoCxZVlUucbkkbJWbRENrne5tv8>
Subject: [Taps] Benjamin Kaduk's Discuss on draft-ietf-taps-minset-08: (with DISCUSS and COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2018 00:38:55 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-taps-minset-08: 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-taps-minset/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [My general summary view of this document is not really relevant to these Discuss points and appears in the COMMENT section.] This document includes a general discussion of the features/services that IETF transport protocols (TCP, MPTCP, SCTP, UDP, etc.) provide ... and also throws in LEDBAT congestion control, with no real coverage of all the other congestion control schemes the IETF provides. It seems that there should be some text/justification of why LEDBAT (but none of the others) fall into the same categorization as the general transport features. As far as I can tell, the idea is that there can be a "low-impact background data transfer" feature/service, which LEDBAT attempts to provide, but I'm basing that on inference and not something explictily stated in the document. Section 3.3.2 and Appendix A.3.1 are limiting this "minimal set" of transport services to exclude discrete messages and allow only the provisioning for TCP-like byte streams. While I can understand the desire to make TCP the "gold standard", the surrounding discussion, particularly in A.3.1, seems to be a layering violation. That is, we are hearing that AFra-Bytestream requires receivers (i.e., applications) to be able to consume contiguous bytestreams. But this seems to really be a requirement on the application protocol to be self-framing (and to provide its own sequence numbers if needed)! Normally we think of an application protocol placing requirements on the transport, or a particular transport as being inappropriate for use with a given application protocol. So I think this document needs to more explicitly acknowledge that this is not a "generic minimal set" of transport features, but rather a minimal set that is applicable for many, but not all, applications: some application protocols have requirements that are not met by this "minimal set". In Section A.3.6, "Data encryption" and "source authenticity" are absent from the list of "security related transport features" (that are relegated to the other document); this seems like a fatal omission. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As a former academic, I can see the appeal of abstracting away details to get to a generic set of features that could allow the backend to do protocol selection and increase the usage of more modern/better-featured protocols. But in some sense this feels like it really wants to be defining an abstract API for transport services, making the feature set into an *interface*, and more directly enabling this automatic selection in the backend. Unfortunately, this particular description is perhaps too abstract to be translateable into "interoperable implementations" of an abstract API (that is, so that an application written for one instantiation of the API would be able to be used with a different instantiation of the API using only a thin shim layer). In particular, in Section 3.2 we are given the option for keeping grouping information within the transport abstraction (even when SCTP is not available) or reporting to the application that he attempt to group connections failed. An abstract API would also need to be quite clear on the semantics of the exposed routines; e.g., "timeout event when data could not be delivered for too long" is predicated on reliable delivery being requested, so an application should not try to use that event as a failsafe abort timer, since UDP does not provide reliable delivery at all, and the application won't know that UDP is/is not in use. So while my personal preference would be to see this document written in a very different way before publication, I have not technical grounds to insist on it, so my preference here is just a nonblocking objection. I agree with Ben that some of the content in the appendices probably ought to be pulled into the main body of the document. The Gen-ART review called out "ADDED" as being noteworthy; my only additional contribution is to ask whether "CHANGED FROM RFC8303" would be easier on the reader. Per-section comments follow. I think we need a reference for LEDBAT in Section 1 when it first shows up. (Also, RFC 6817 seems to say that the 'T' is "Transport", not "Transfer".) Section 2 has an interesting definition of socket, but I don't have an alternate term handy to reflect this concept without overloading the connotations of a POSIX socket. I may just be thinking too hard, but does "Hand over a message to reliably transfer (possibly multiple times) before connection establishment" mean that the data transfer of this message will complete prior to connection establishment, or merely that the application has handed data to the transport prior to connection establishment (but the data transfer will occur after connection establishment)? (The Appendices do help clear this up with concrete examples, but perhaps the text earlier in the document could be clarified?) Section 3.1 [...] This means that unacknowledged data residing a transport system's send buffer may have to be dropped from that buffer upon arrival of a "close" or "abort" notification from the peer. nit: Is this supposed to be "residing in"? Section A.1.1 I'm a little confused how the multiple-streams establishment features are "automatable". Coming at this from the perspective of an application that needs to know that multiple streams exist in order to concurrently send data on them, it seems non-automatable. But I assume there's a different sense in which the application can't really tell whether those "multiple streams" are related at the transport protocol level or it's just the transport abstraction that's tracking the group. I'm also a little unsure about "configure message fragmentation" being "automatable", given my understanding of how many fragmentation-intolrant networks there are. (But that's far from my area of expertise and any data I have would be stale, so I don't really have anything useful to say here.) o Disable checksum when sending Protocols: UDP Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity. Implementation: via SET_CHECKSUM_ENABLED.UDP. Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result). (Also for receiving, "checksum coverage" topics, etc.). Please clarify that this is "data integrity with respect to random corruption" (as opposed to "source authentication and integrity protection" which would require more crypto). The notification of unsent/unacknowledged (part of a) message items are listed as automatable because the distinction is "network-specific". I agree that the distinction is something that can be made automatically, but I don't really understand how what "network" it is supposed to be that matters for the distinction. Section A.2 the following list, we therefore precede a transport feature with "T:" if an implementation over TCP is possible, "U:" if an implementation over UDP is possible, and "TU:" if an implementation over either TCP or UDP is possible. nit: It looks like "T,U:" is what's actually used, with the comma. Section A.3.2 With only these semantics necessary to represent, the interface to a transport system becomes easier if we assume that connections may be a transport protocol's connection or association, but could also be a stream of an existing SCTP association, for example. nit: is this missing a "not only" (or similar) in "may be not only a transport protocol's connection or association"?
- [Taps] Benjamin Kaduk's Discuss on draft-ietf-tap… Benjamin Kaduk
- Re: [Taps] Benjamin Kaduk's Discuss on draft-ietf… Michael Welzl
- Re: [Taps] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Taps] Benjamin Kaduk's Discuss on draft-ietf… Michael Welzl