A Minimal Set of Transport Services for End Systems
draft-ietf-taps-minset-11

[Ballot comment]
Thanks for addressing my DISCUSS point.

Original COMMENT:

It seems like this document will be in need of updating once QUIC is published. Is the plan to publish this now and then publish an update next year? Why is that preferable to waiting and just publishing once?

[Ballot comment]
Thank you for addressing my DISCUSS points; original comments retained
below for posterity.

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

[Ballot comment]
I support the first paragraph of Benjamin's DISCUSS. (For avoidance of doubt: I take no position on the remainder of his DISCUSS, and in no way intend to diminish it by explicitly supporting a specific subset of his DISCUSS.)

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4808



IMPORTANT
S 3.1.
>        - Is any of the following useful to the application?
>          *  Specify checksum coverage used by the sender
>          *  Specify minimum checksum coverage required by receiver
> 
>          Yes: UDP-Lite is preferred.
>          No: UDP is preferred.

there seems to be something missing here wrt penetration rates. I.e.,
SCTP  (absent UDP) does not reliably work for any client behind NATs,
which means that it's not preferred for those clients regardless of
the other benefits in this tree.

COMMENTS
S 1.
>      of libraries to use this transport feature without exposing it, based
>      on knowledge about the applications -- but this is not the general
>      case).  In most situations, in the interest of being as flexible and
>      efficient as possible, the best choice will be for a library to
>      expose at least all of the transport features that are recommended as
>      a "minimal set" here.

What is the bar for the requirements here. I.e., do you believe that
all of these can be implemented with a standard sockets API.


S 3.
> 
>      Based on the categorization, reduction, and discussion in Appendix A,
>      this section describes a minimal set of transport features that end
>      systems should offer.  The described transport system can be
>      implemented over TCP.  Elements of the system that are not marked
>      with "!UDP" can also be implemented over UDP.

Does this mean over native UDP with no other session protocol. Because
you can have TCP over UDP.


S 3.2.
>      multiplexed as streams on a single SCTP association when SCTP may not
>      be available).  The transport system must therefore ensure that
>      group- versus non-group-configurations are handled correctly in some
>      way (e.g., by applying the configuration to all grouped connections
>      even when they are not multiplexed, or informing the application
>      about grouping success or failure).

How do you group connections in TCP? Or is this text saying it
doesn't?


S 7.2.
>      o  Request to negotiate interleaving of user messages
>        Protocols: SCTP
>        Automatable because it requires using multiple streams, but
>        requesting multiple streams in the CONNECTION.ESTABLISHMENT
>        category is automatable.
>        Implementation: via a parameter in CONNECT.SCTP.

I'm not sure I follow how this is automatable. Is the argument that
SCTP will always do it, and so once you have asked for SCTP...?


S 7.2.
> 
>      o  Disable MPTCP
>        Protocols: MPTCP
>        Automatable because the usage of multiple paths to communicate to
>        the same end host relates to knowledge about the network, not the
>        application.

I don't think I understand how this is automatable. Is the theory that
the host auto-negotiates MPTCP? But what if the app doesn't want it no
matter what.

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

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

[Ballot discuss]
I was wondering about why this document is going for informational rather than proposed standard. I see that draft-ietf-taps-interface-01 has a normative reference to it, so this is effectively setting up a downref situation. That isn't necessarily a problem, but if the point is for this document to recommend an actual minimal set of transport services to be supported and exposed via the API specified in draft-ietf-taps-interface and other APIs, shouldn't that set be normative?

[Ballot comment]
It seems like this document will be in need of updating once QUIC is published. Is the plan to publish this now and then publish an update next year? Why is that preferable to waiting and just publishing once?

[Ballot comment]
General:

It's not clear to me who the target audience is for this draft or what the purpose is for publishing it as an RFC. It seems like an internal working group document that won't have much archival value once the interfaces are published. It seems telling that Appendix A (which IIUC is entirely historical) is almost twice as long as the body of the draft.  But I see that it is in fact chartered work, so I'm balloting "No Objection".

Otherwise, I just have a few editorial comments:

General: The annotation "(!UDP)" is used throughout. I can guess the meaning, but it would be better to explicitly state it. Also, it seems odd to find that sort of annotation imbedded in paragraph form text.

§1: Please include a citation for the "Berkeley Sockets Interface". (Maybe the POSIX specs?)

§3.1, section title: What is the meaning of using all-caps here? It would help to include some description of the typographical convention. (This repeats in some other sections).

§3.1 "We caution implementers to be aware of the full
  set of trade-offs, for which we recommend consulting the list in
  Appendix A.2.1 when deciding how to initialize a connection."

If there is content in an Appendix that is risky for an implementor to skip, please consider moving it into the body. People regularly skip reading appendices.

[Ballot comment]
Mostly just a nit...

What is an end system?  I was curious to see the definition to get an idea of who the recommendations in this document are for.  I assumed pretty much any device is an end system; the Introduction seems to focus on applications as the users of the transport services (which obviously makes sense).

There is no definition of "end system" in the document.  But there is one for endpoint: "an entity that communicates with one or more other endpoints using a transport protocol."  Hmmm...so an endpoint is one that communicates with other endpoints.  Just what I thought! ;-)

Seriously...  The terminology may not be obvious to the casual reader.  It would be nice to at least be consistent in the terminology/description.  BTW, all the terminology in §2 is pretty much the same as what is already defined in rfc8303.

[Ballot comment]
Rereading this doc again, I still have a couple of mostly editorial comments (however, none of them are critical in any way):

1) In the terminology section I think "Transport Service Instance" is actually never used in this doc and could therefore be removed. Please also double-check if service and feature is used coherently; I thought there were one or two cases where I would have expected to see feature instead of service. And finally Connection Group is explain there, however, given it is a new term and important concept, I would recommend to introduce it anyway separately in the intro as well.

2) Not sure if the paragraph in the intro about "one-sided" deployment is needed there, given that this doc does not/should not really talk about any deployment considerations for an taps system.

3) In section 3 I find this sentence a bit confusing: "The described transport system can be implemented over TCP."
This sentence leaves open if other protocols can be implemented as well. However, I guess what you actually what to say is something like
"Any configuration based the described minimum set of transport feature can always be realized over TCP but also gives the transport system flexibility to choose another transport if implemented." Or something like this. I think a clarification would be helpful to make clear that there is no direct dependency on TCP.

4) I personally still think that having this example decision tree in section 3.1 puts to much emphasis on this specific example (that "only" covers TCP, SCTP, and UDP(-Lite)) and I would rather move it to the appendix (or maybe create an own subsection somehow).

5) In section 3.1 the paragraph starting with "Once a connection is created..." seems redundant with section 3.2.1 and could potentially be just removed.

6) sec 3.3.1: "Note that
      applications sending unreliable data without congestion control
      should themselves perform congestion control in accordance with
      [RFC2914]."
  I guess the better reference is RFC8085 (if this sentence is needed at all).

7) Why is "Configure checksum usage" (only) applicable to individual connections?

[Ballot comment]
Rereading this doc again, I still have a couple of mostly editorial comments (however, none of them are critical in any way):

1) In the terminology section I think "Transport Service Instance" is actually never used in this doc and could therefore be removed. Please also double-check if service and feature is used coherently; I thought there were one or two cases where I would have expected to see feature instead of service. And finally Connection Group is explain there, however, given it is a new term and important concept, I would recommend to introduce it anyway separately in the intro as well.

2) Not sure if the paragraph in the intro about "one-sided" deployment is needed there, given that this doc does not/should not really talk about any deployment considerations for an taps system.

3) In section 3 I find this sentence a bit confusing: "The described transport system can be implemented over TCP."
    This sentence leaves open if other protocols can be implemented as well. However, I guess what you actually what to say is something like
  "Any configuration based the described minimum set of transport feature can always be realized over TCP but also gives the transport system flexibility to choose another transport if implemented." Or something like this. I think a clarification would be helpful to make clear that there is no direct dependency on TCP.

4) I personally still think that having this example decision tree in section 3.1 puts to much emphasis on this specific example (that "only" covers TCP, SCTP, and UDP(-Lite)) and I would rather move it to the appendix (or maybe create an own subsection somehow).

5) In section 3.1 the paragraph starting with "Once a connection is created..." seems redundant with section 3.2.1 and could potentially be just removed.

6) sec 3.3.1: "Note that
      applications sending unreliable data without congestion control
      should themselves perform congestion control in accordance with
      [RFC2914]."
  I guess the better reference is RFC8085 (if this sentence is needed at all).

7) Why is "Configure checksum usage" (only) applicable to individual connections?

[Ballot comment]
Rereading this doc again, I still have a couple of mostly editorial comments (however, none of them are critial in any way):

1) In the terminolgy section I think "Transport Service Instance" is actually never used in this doc and could therefore be removed. Please also double-check if service and feature is used coherently; I thought there were one or two cases where I would have expected to see feature instead of service. And finally Connection Group is explain there, however, given it is a new term and important concept, I would recommend to introduce it anyway separately in the intro as well.

2) Not sure if the paragraph in the intro about "one-sided" deployment is needed there, given that this doc does not/shoud not really talk about any deployment considerations for an taps system.

3) In section 3 I find this setence a bit confusing: "The described transport system can be implemented over TCP."
    This sentence leaves open if other protocols can be implemented as well. However, I guess what you actually what to say is something like
  "Any configuration based the described minimum set of transport feature can always be realized over TCP but also gives the transport system flexibilty to choose another transport if implemented." Or something like this. I think a clarification would be helpful to make clear that there is no direct dependency on TCP.

4) I personally still think that having this example decision tree in section 3.1 puts to much emphasis on this specific example (that "only" covers TCP, SCTP, and UDP(-Lite)) and I would rather move it to the appendix (or maybe create an own subsection somehow).

5) In secton 3.1 the paragraph starting with "Once a connection is created..." seems redundant with section 3.2.1 and could potentially be just removed.

6) sec 3.3.1: "Note that
      applications sending unreliable data without congestion control
      should themselves perform congestion control in accordance with
      [RFC2914]."
  I guess the better reference is RFC8085 (if this sentence is needed at all).

7) Why is "Configure checksum usage" (only) applicable to individual connections?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-taps-minset-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-taps-minset@ietf.org, Theresa Enghardt , theresa@inet.tu-berlin.de, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Minimal Set of Transport Services for End Systems) to Informational RFC


The IESG has received a request from the Transport Services WG (taps) to
consider the following document: - 'A Minimal Set of Transport Services for
End Systems'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This draft recommends a minimal set of Transport Services offered by
  end systems, and gives guidance on choosing among the available
  mechanisms and protocols.  It is based on the set of transport
  features in RFC 8303.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-taps-minset/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Theresa Enghardt. The responsible Area Director is Spencer Dawkins.

This document recommends a minimal set of transport services offered by end systems, based on the set of existing transport protocol features surveyed in RFC 8303. It summarizes which transport features are worth exposing to an application, in contrast to those which can be automated within a transport system, addressing TAPS agenda item 2. Furthermore, the document gives guidance on choosing among the available mechanisms and protocols.
The intended publication type is Informational, as the document provides useful information about transport services. Its Appendix documents the Working Group's bottom-up process of finding the right abstraction for the transport system interface.

2. Review and Consensus

As this document generalizes and categorizes primitives that are already standardized in the RFC series, there was few controversy about them.
Initially, there was not a lot of interest in this agenda item, but eventually the document was extensively reviewed and discussed by half a dozen active Working Group participants. In addition, on WGLC the body of the document was reviewed by a person who had not read the document before, who found it easy to understand and ready for publication.

Much of the discussion was about coming up with consistent terminology and about finding the right scope, which now focuses on features of existing transport protocols that can be implemented over TCP, or UDP if certain limitations are put in place.
It was discussed whether to include security features, and finally after broadening the TAPS charter, they were put in a separate document.

3. Intellectual Property

This document introduces no new technologies beyond those already published.

4. Other Points

There are no normative downward references and no IANA considerations.