Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04

[Spencer Dawkins at IETF <[e-mail]>]

Dear TAPsters,

I've completed my AD review for this document, and have two high-level
responses:

   - This looks good, and
   - I only have 8 pages of comments ...

Please look these over, and ask for explanations if you need them. When we
work through my comments, I'll request Last Call.

And thanks for your work to date.

Spencer

I'm looking at this text

   Because the considered
   transport protocols conjointly cover a wide range of transport
   features, there is reason to hope that the resulting set (and the
   reasoning that led to it) will also apply to many aspects of other
   transport protocols.

and wondering whether it's accurate to say "many aspects of other transport
protocols that may be in use today, or may be designed in the future"?

Part of my question is wrapped up in discussions about whether QUIC is a
one-off new transport protocol, or whether QUIC is the first example of a
new generation of transport protocols that are now worth designing because
we know how to deploy them.

This text

   For example, it does not help an
   application that talks to a library which offers its own
   communication interface if only the underlying Berkeley Sockets API
   is extended to offer "unordered message delivery", but the library
   only exposes an ordered bytestream.

read oddly to me - I think the first "only" could be removed, unless I'm
missing your point, but please take a look at that sentence for clarity.

This text

   This "minimal set" can be implemented one-sided over TCP (or UDP, if
   certain limitations are put in place).  This means that a sender-side
   transport system can talk to a standard TCP (or UDP) receiver, and a
   receiver-side transport system can talk to a standard TCP (or UDP)
   sender.

was a bit difficult for me to read, and seems to mix explaining what
"one-sided" means with the explanation that "one-sided" also applies to
UDP, if certain limitations are put in place. I wonder if it is accurate to
say

   This "minimal set" can be implemented "one-sided" over TCP.  This means
   that a sender-side transport system can talk to a standard TCP receiver,
   and a receiver-side transport system can talk to a standard TCP sender.
   If certain limitations are put in place, the "minimal set" can also be
   implemented "one-sided" over UDP.

Is "ungrouped communication" in

   For ungrouped connections, early configuration is necessary because
   it allows the transport system to know which protocols it should try
   to use.

a well-understood term? I can guess at the meaning, but I'd be guessing,
and RFCs 8095 and 8304 don't define or use either term.(Further down, I
also see "grouped communications", and I'm guessing what that means, too,
and Section 3.2.1 is even called "Connection groups", but doesn't clearly
define what that means)

I don't disagree with

  Note that this decision tree is not optimal for all cases.  For
   example, if an application wants to use "Specify checksum coverage
   used by the sender", which is only offered by UDP-Lite, and
   "Configure priority or weight for a scheduler", which is only offered
   by SCTP, the above decision tree will always choose UDP-Lite, making
   it impossible to use SCTP's schedulers with priorities between
   grouped connections.  The transport system must know which choice is
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   more important for the application in order to make the best
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   decision.  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.

but I'm not sure how a general-purpose transport system will know which
choice is more important for any arbitrary application. I see the Is this
advice transport system implementers can act on?

This isn't a big deal, but

  This also means that the active opening side is assumed to be the
   first side sending data.

seems really reasonable for the vast majority of (client-server)
applications, but I wonder if peer-to-peer applications will trip over a
problem here ("I open a connection to you, but you already had data queued
for me since we last connected and you sent it immediately" could be a
scenario for SMTP or DTN, I guess). But I'll let you folks think about that.

This is a nit, but

  o  A buffer limit (in bytes); when the sender has less then the
                                                         ^^^^ than

In this text,

  o  Reliability: this parameter is used to convey a choice of: fully
      reliable (!UDP), unreliable without congestion control, unreliable
      (!UDP), partially reliable (see [RFC3758] and [RFC7496] for
      details on how to specify partial reliability) (!UDP).

it took me some re-reading to figure out that "unreliable (!UDP)" meant
something besides JUST "unreliable" (because UDP is "unreliable without
congestion control"). Could this be clearer? I wonder about "unreliable
with congestion control (!UDP)", but I'm guessing that this is the
distinction you're making.

This text in 7.  Security Considerations

   Authentication, confidentiality protection, and integrity protection
   are identified as transport features by [RFC8095].  As currently
   deployed in the Internet, these features are generally provided by a
   protocol or layer on top of the transport protocol; no current full-
   featured standards-track transport protocol provides all of these
   transport features on its own.  Therefore, these transport features
   are not considered in this document, with the exception of native
   authentication capabilities of TCP and SCTP for which the security
   considerations in [RFC5925] and [RFC4895] apply.  The minimum
   security requirements for a transport system are discussed in a
   separate document [I-D.ietf-taps-transport-security].

confuses me, because I think at least two things are in play. First, I
think the point you're probably making is that the underlying transport
protocols remain unmodified, so the security considerations for each of
those protocols apply unchanged, and this document isn't doing anything to
create new security considerations. So, modulo SECDIR and SEC AD comments,
I think that's all you need to say.

Second, you guys are the experts, but I think a reference to
[I-D.ietf-taps-transport-security] isn't actually needed for this document,
because that document surveys security protocols, rather than specifying
minimum security requirements. That document might someday discuss the
minimum security requirements, in the way this document discusses the
minimum set of transport services, but at least in
https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that
document is much more comparable to RFCs 8095 and 8304 than to this
document.

In Informative References, I see

  [RFC7305]  Lear, E., Ed., "Report from the IAB Workshop on Internet
              Technology Adoption and Transition (ITAT)", RFC 7305,
              DOI 10.17487/RFC7305, July 2014,
              <https://www.rfc-editor.org/info/rfc7305>.

which is awesome (I wish more IETF people referred to IAB workshop
reports), but the only place I see it referred to is in A.3.1.  Sending
Messages, Receiving Bytes:

   For example, if an application requests to transfer fixed-size
   messages of 100 bytes with partial reliability, this needs the
   receiving application to be prepared to accept data in chunks of 100
   bytes.  If, then, some of these 100-byte messages are missing (e.g.,
   if SCTP with Configurable Reliability is used), this is the expected
   application behavior.  With TCP, no messages would be missing, but
   this is also correct for the application, and the possible
   retransmission delay is acceptable within the best effort service
   model [RFC7305].  Still, the receiving application would separate the
   byte stream into 100-byte chunks.


I was at that workshop, and it was pretty wide-ranging, so you might want
to provide a section number with this reference to give an inquiring reader
a chance of finding what you're referring to (I'm guessing the section
number is 3.5, but I'm guessing).

Just so you know - I did notice that Appendix A is two thirds of the page
count for this document, and I agree that the material belongs in an
appendix, and I think it's important for you to "show your work", in case
anyone ever needs to update the minimal set in the future. So, I support
what you're doing there.

You folks know what you actually did, but I'm hoping that

  2.  Reduction: a shorter list of transport features is derived from
       the categorization in the first step.  This removes all transport
       features that do not require application-specific knowledge or
       cannot be implemented with TCP or UDP.

was actually "cannot be implemented with TCP, SCTP, or UDP". Was that an
omission in this text, or do we need to chat?

This text,

Appendix A.  Deriving the minimal set

   We approach the construction of a minimal set of transport features
   in the following way:

   1.  Categorization: the superset of transport features from [RFC8303]
       is presented, and transport features are categorized for later
       reduction.
   2.  Reduction: a shorter list of transport features is derived from
       the categorization in the first step.  This removes all transport
       features that do not require application-specific knowledge or
       cannot be implemented with TCP or UDP.
   3.  Discussion: the resulting list shows a number of peculiarities
       that are discussed, to provide a basis for constructing the
       minimal set.
   4.  Construction: Based on the reduced set and the discussion of the
       transport features therein, a minimal set is constructed.

   The first three steps as well as the underlying rationale for
   constructing the minimal set are described in this appendix.  The
   minimal set itself is described in Section 3.

would have been clearer to me, if each step was labeled with the part of
the document where this work appears (so, step 1 would be labeled "Section
A.1", etc.), rather than providing the pointers at the end of the list. I
couldn't tell whether you meant that these were the steps you took in the
working group, or whether this was the organization of this appendix (plus
Section 3), until I got to the paragraph at the end.

Does

  Finally, some transport features are aggregated and/or slightly
   changed in the description below.  These transport features are
   marked as "ADDED".  The corresponding transport features are
   automatable, and they are listed immediately below the "ADDED"
   transport feature.

mean "aggregated and/or slightly change from [RFC8303]"?

I have the same question with

  In this description, transport services are presented following the
   nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL",
   equivalent to "pass 2" in [RFC8303].  We also sketch how some of the
   transport features can be implemented by a transport system.  For all
   transport features that are categorized as "functional" or
   "optimizing", and for which no matching TCP and/or UDP primitive
   exists in "pass 2" of [RFC8303], a brief discussion on how to
   implement them over TCP and/or UDP is included.

as I did above - is SCTP intentionally omitted from this paragraph?

(Somewhere about here, I started thinking about "automated" - I didn't see
a clear definition of this in the document. I think I understand what you
mean at a hand-waving level, but you might consider adding a definition
earlier in the document, so that's clearer without relying on context
clues.

I'm not going to list them off, but starting in Section A.1.1.  CONNECTION
Related Transport Features, I'm seeing a lot of analysis that includes some
transport protocols and doesn't include others. I'm comparing

  o  Indicate (and/or obtain upon completion) an Adaptation Layer via
      an adaptation code point
      Protocols: SCTP
      Functional because it allows to send extra data for the sake of
      identifying an adaptation layer, which by itself is application-
      specific.
      Implementation: via a parameter in CONNECT.SCTP.
      Implementation over TCP: not possible.
      Implementation over UDP: not possible.

which includes TCP, SCTP, and UDP, to something like

  o  Hand over a message to reliably transfer during connection
      establishment
      Protocols: SCTP
      Functional because this can only work if the message is limited in
      size, making it closely tied to properties of the data that an
      application sends or expects to receive.
      Implementation: via a parameter in CONNECT.SCTP.
      Implementation over UDP: not possible.

which does not mention TCP. There are a bunch of examples with this kind of
omission. Is it worth showing a complete set of "Implementation over
$Transport: not possible"s for each feature?

If this next is too much trouble, do the right thing, but I notice that

  o  Change timeout for aborting connection (using retransmit limit or
      time value)
      Protocols: TCP, SCTP
      Functional because this is closely related to potentially assumed
      reliable data delivery.
      Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP.
      Implementation over UDP: not possible (UDP is unreliable and there
      is no connection timeout).

includes a parenthetical explanation of why a function is not possible to
implement on a specific transport protocol, but most "not possible" entries
don't have such an explanation. I mention this now, both because it might
reduce the number of conversations with reviewers and ADs that you have
starting with Last Call, and because you folks are likely the best equipped
to add these explanations now, rather than someone else trying to guess
what you were thinking later.

And, while I was thinking about that, I started thinking about entries like

     Implementation over UDP: Do nothing (this is irrelevant in case of
      UDP because there, reliable data delivery is not assumed).

and wondered how many of the "not possible" entries in the appendix might
be "do nothing". If you had parenthetical explanations for why something is
"not possible", or why an implementation might "do nothing", that would
probably sharpen the difference for the average reader …

And finally, at a high level, I don't understand why there are
"Implementation over $Protocol" lines so often that name $Protocols that
weren't listed in "Protocols:" at the beginning of each description. I have
several guesses about what that might mean, but I bet all of them are
wrong, so I have to ask.

To the details ...

Is this text

  o  Reliably transfer a message, with congestion control
      Protocols: SCTP
      Functional because this is closely tied to properties of the data
      that an application sends or expects to receive.
      Implementation: via SEND.SCTP.
      Implementation over TCP: via SEND.TCP.  With SEND.TCP, messages
      will not be identifiable by the receiver.
      Implementation over UDP: not possible.

saying

  o  Reliably transfer a message, with congestion control
...
      Implementation over TCP: via SEND.TCP.  With SEND.TCP, message
      boundaries will not be identifiable by the receiver, because TCP
      provides a stream service.
...

or something else?

I have the same question about the next one

  o  Unreliably transfer a message
      Protocols: SCTP, UDP(-Lite)
      Optimizing because only applications know about the time
      criticality of their communication, and reliably transfering a
      message is never incorrect for the receiver of a potentially
      unreliable data transfer, it is just slower.
      ADDED.  This differs from the 2 automatable transport features
      below in that it leaves the choice of congestion control open.
      Implementation: via SEND.SCTP or SEND.UDP(-Lite).
      Implementation over TCP: use SEND.TCP.  With SEND.TCP, messages
      will be sent reliably, and they will not be identifiable by the
      receiver.

("message boundaries"?)

In section A.2, I have the same "is SCTP out or in?" question, especially
around

  In the following list, we 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.

I don't understand

A.2.1.  CONNECTION Related Transport Features

   ESTABLISHMENT:

   o  T: Hand over a message to reliably transfer (possibly multiple
      times) before connection establishment

Is this saying "possibly retransmitting multiple times to achieve
reliability", or something else?