Re: [Taps] Benjamin Kaduk's Discuss on draft-ietf-taps-minset-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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
>