On Thu, Sep 13, 2018 at 04:31:37PM +0200, Michael Welzl wrote: > Dear Benjamin, > > Thanks a lot for your comments! Answers below: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-taps-minset-08: Discuss > > > > 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. > > You're right about the technical rationale for LEDBAT. From the > point of view of this document however, the more important reason > for the specific choice of protocols + LEDBAT is that this document > only carries out an analysis based on what's in RFC 8303 + RFC 8304, > which is: TCP, MPTCP, UDP(-Lite), SCTP, LEDBAT. > Anyway, we now inserted a note about LEDBAT immediately after the > sentence (in intro, par. 2) that already says that this list of > protocols + LEDBAT is the basis, covered in RFCs 8303 and 8304.
Thanks! > > > 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". > > Done, in the last paragraph of the introduction. That looks good to me. > > > 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. > > The list here are the security related transport features from A.1, > which are taken (literally, for consistency) from RFC 8303, which is > an analysis of what TCP, MPTCP, SCTP, UDP(-Lite) and LEDBAT offer. > Since none of them offer encryption and "Data encryption" is thus > not included in RFC 8303, we believe that this is a misunderstanding. > We have now clarified where this list is from by adding > "from Appendix A.1" in the sentence that introduces this list. Because it is a list of things *not* covered, I do not think that the artificial limitation of scope to just those from RFC 8303 is necessarily binding. In particular, the TAPS charter even calls out that "content privacy to in-path devices" is to be considered. So, given how important these features have become for the modern internet, I think it would be good to say something like "it also excludes security transport features not listed in Appendix A, including content privacy to in-path devices" at the end of Section 5.6 (of the -09, since things got moved around a lot). A previous draft of this message also was going to list something like "integrity protection from active replacement", but I think that the existing source authentication mechanisms would cover that. (Also it looks like there's an "and and" in the list there.) > > ---------------------------------------------------------------------- > 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. > > We agree that there are several difficulties when trying to take this > to a real implementation; otherwise the next step currently taken by the > WG (to define an API and describe the implementation below) would be easy > (but it isn't). We note, though, that interoperability is essentially > solved by the requirement of "one-sided implementation over TCP". I guess this is more about the API side of things, that has its own document; I had missed that document when I wrote this text. Thank you for all the updates! -Benjamin > > > I agree with Ben that some of the content in the appendices probably > > ought to be pulled into the main body of the document. > > Done. > > > > 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. > > Done. > > > Per-section comments follow. > > > I think we need a reference for LEDBAT in Section 1 when it first shows up. > > Reference: not done now because, in this case, we should probably also have > references to TCP, MPTCP, UDP, UDP-Lite and SCTP - but they all are taken > from RFC 8303 here. > > > > (Also, RFC 6817 seems to say that the 'T' is "Transport", not "Transfer".) > > The features are copied literally (for consistency) from RFC 8303, which > calls this the LEDBAT transport feature: > 'Enable and configure "Low Extra Delay Background 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. > > This definition is also taken from RFCs 8303. > > > > 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?) > > It means the latter. After moving text from the appendix to the main > text, we think this is now clarified early enough. > > > > 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"? > > Yes, done. > > > > 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. > > Right, the notion of grouping needs to be there such that priorities > can be given - but whether this grouping really is available, and > really is implemented using multi-streaming, is a matter that can > be decided without application-specific knowledge. We changed the > text to point two references that describe how this can be done in > case of SCTP. > > > > 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.) > > From the text in "pass 1" in RFC 8303 it's clear that this is about > fragmentation in the host itself, by SCTP, not IP-level fragmentation. > In this draft, however, it's hard to understand that. We clarified > this in the text. > > > > 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). > > Done: added "with respect to random corruption" after "data integrity" > everywhere. > > > > 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. > > Agreed; we replaced this with "does not relate to application-specific > knowledge". > (basically, applications don't have to care about this 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. > > Done. > > > > 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"? > > Done. > > Cheers, > Michael > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
