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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 12 Sep 2018 17:38:54 -0700

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"?

---

From: Michael Welzl <[email-masked]>
Date: Thu, 13 Sep 2018 16:31:37 +0200

Dear Benjamin,

> https://datatracker.ietf.org/doc/draft-ietf-taps-minset/

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.

> protocols have requirements that are not met by this "minimal set".

Done, in the last paragraph of the introduction.

> 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.

> technical grounds to insist on it, so my preference here is just a

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".

> ought to be pulled into the main body of the document.

Done.

> additional contribution is to ask whether "CHANGED FROM RFC8303" would be

Done.

> 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"'.

> connotations of a POSIX socket.

This definition is also taken from RFCs 8303.

> up with concrete examples, but perhaps the text earlier in the document

It means the latter. After moving text from the appendix to the main
text, we think this is now clarified early enough.

> nit: Is this supposed to be "residing in"?

Yes, done.

> 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 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.

> to "source authentication and integrity protection" which would require

Done: added "with respect to random corruption" after "data integrity" everywhere.

> 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)

> nit: It looks like "T,U:" is what's actually used, with the comma.

Done.

> transport protocol's connection or association"?

Done.

Cheers,
Michael

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 17 Sep 2018 18:58:57 -0500

> protocols + LEDBAT is the basis, covered in RFCs 8303 and 8304.

Thanks!

> Done, in the last paragraph of the introduction.

That looks good to me.

> "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.)

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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 18 Sep 2018 11:53:00 +0200

Hi,

> the end of Section 5.6 (of the -09, since things got moved around a lot).

Done, with version -10 (just submitted).

> (Also it looks like there's an "and and" in the list there.)

Thanks, fixed!

Cheers,
Michael