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

[Michael Welzl <[e-mail]>]

Hi Spencer!

Thank you so much for your detailed work and all these comments!
I'm commenting in line below, and marking my comments with "MW:".
I'm terminating my responses with a "--".

I'm attaching an update which incorporates the changes described in this email, but I'm delaying its submission until it's clear that this conversation has converged.

Cheers,
Michael

---


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.

MW: Done
--

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. 

MW: Done (first "only" removed)
--

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.

MW: Done
--

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)

MW: Good catch, thanks!  I added "Connection Group" to the terminology section; this text block also explains "grouped" and "ungrouped".
--

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?

MW: Agreed; I removed this sentence.
--

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.

MW: I added the following paragraph at the beginning of section 3 (as the second para)
to address this issue:

   The arguments laid out in Appendix A.3 ("discussion") were
   used to make the final representation of the minimal set as short,
   simple and general as possible.  There may be situations where these
   arguments do not apply -- e.g., implementers may have specific
   reasons to expose multi-streaming as a visible functionality to
   applications, or the restrictive open / close semantics may be
   problematic under some circumstances.  In such cases, the
   representation in Appendix A.2 ("reduction") should be
   considered.
--   
   

This is a nit, but

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

MW: Done
--

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.

MW: Good catch, thanks! And yes, that's the distinction. I changed this to the following, to be explicit about congestion control for all choices:

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

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. 

MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't have section 5.
I believe section 5 in this document is an effort to do the same as minset does, here;
are you maybe asking for this section of [I-D.ietf-taps-transport-security] to use a
more authoritative tone?  Either way, as things stand now, the existence of
[I-D.ietf-taps-transport-security] is used as a justification to not include the
security related features of TCP and SCTP in the minimum set, and I think this
citation is necessary.

--

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

MW: Done (and you guessed right).
--

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.

MW: Thanks :)
--

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? 

MW: the point was that TCP and UDP can't work as a fall-back in case e.g. SCTP isn't available. As stated at the beginning of the document, the minset can be implemented "one-sided" over TCP.  (and with some limitations, also UDP). For example: it's fine (within "best effort") to always send everything in order when an application allows out-of-order delivery - but there's simply no way to implement SCTP's out-of-band transmission of a number ("Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point") with TCP or UDP. If an application relies on that, TCP or UDP fall-backs become impossible. We were asked to avoid writing using the term "fall-back", for good reasons, but this particular sentence may have ended up being less clear as we simply replaced "fall-back" with "implemented with".

I changed the sentence as follows, is it better?

NEW:

This removes all transport features that do not require application-specific knowledge or would result in semantically incorrect behavior if they were implemented over TCP or UDP.
--


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. 

MW: Done (and final paragraph removed)
--

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

MW: Yes, done. New sentence:
  Finally, some transport features are aggregated and/or slightly
   changed from [RFC8303] in the description below.
--

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? 

MW: Yes, for the same reason I gave above. I now prefaced the last sentence
with 'The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. Hence, ...'
--

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

MW: "automated" doesn't appear in the draft - I'm sure you mean "automatable".
It only appears in the appendix, where it's defined upon its first occurrence, in paragraph 5 of Appendix A.1, as follows: "The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be transparently utilized by a transport system are called "Automatable"."  - maybe you just missed this? I believe it's in the most suitable place. I now made this sentence a bit clearer now, by changing it into: "The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be utilized by a transport system on its own without involving the application are called "Automatable"."
--

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?

MW: Yes, done, for all the functional and optimizing features (as
explained in the introductory text of Appendix A.1.
--

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 …

MW: Done everywhere
--

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. 

MW: maybe that's related to your confusion about the omission of SCTP, which I hope
I have addressed (as explained above). So that's answered by text that appears just before we list the transport features, which now reads:
"The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. Hence, 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."
--

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?

MW: It says what you suspect, and I updated the text as you propose (although saying "byte stream" instead of just "stream").
--

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

MW: same here - I replaced "they" with "message boundaries" in the last sentence.
--



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.

MW: I addressed this in the same way as the others above, by replacing it with:

"The "minimal set" derived in this document is meant to be implementable "one-sided"
over TCP, and, with limitations, UDP. In the following list, we therefore precede ..."
--                   
  
                    
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?

MW: No, it means that a message is transferred reliably, and that it may arrive
multiple times; that's a long-winded way of saying "idempotence" for TFO.
I really don't want to change this text because it is a literal copy from
RFC 8303 - these text snippets tie these documents together.
And, even though I agree that the wording could be better, I think it's actually
clear because this is describing a service to the application.
Retransmissions to achieve reliability wouldn't be relevant to the application;
"transferring multiple times" can therefore only mean that the message really is
transferred from application A to application B multiple times, and this is what
can happen with TFO.

----