[Taps] Comments on draft-ietf-taps-transports-08

[Michael Welzl <[e-mail]>]

Dear all,

I finally managed to read draft-ietf-taps-transports-08 in detail, here are my comments. Now, for the first time, I believe I deserve the ACK that is in there  :-)   Most of them are nits, and I apologize for presenting them mixed together with some larger issues (with the biggest issue being towards the end, where I comment on section 5) - but anyway there's nothing huge or show-stopping. There may also be duplicates between these comments and comments that were already given.

Cheers,
Michael



Comments on draft-ietf-taps-transports-08

sec 1:

s/MP-TCP/MPTCP   (for consistency)


sec 2:

This defines "Transport Service Feature" but all the text describing protocols talks about "Transport Features"  (with non-capitalized "features" in some section headings). Define both? Or only "Transport Features" maybe? "Transport Service Feature" seems unnecessarily lengthy...


sec 3:
unordered and unordered message delivery  => should probably be "ordered and unordered"


sec 3.1:
***
and other protocols that choose to use a
 datagram protocol (e.g., UDP or UDP-Lite) need to employ mechanisms
 to prevent congestion collapse
***
=> the fact that these protocols provide a datagram service isn't the issue - it's the lack of congestion control. (indeed just a bit further down there's talk of "datagram congestion control" in DCCP CCID-2).


***
Each technique requires that the protocol provide a method
***
=> provide_s_  ?

From the 3rd paragraph onward, the text of this section seems a bit out of place: in the context of this document, it would probably be better to explain what the various congestion controls mean for applications (smooth TFRC, bursty Reno, LBE-style LEDBAT...), but this text talks about loss vs. delay vs. ECN signals etc. which seems largely irrelevant here. Well at least that part does - rate- vs. window-based has a meaning for an application, so that part is probably fine. Also, it's probably ok to have these explanations there, but the meaning of different congestion control flavors for applications is missing (can be short but should be there).


***
are are deployed in the Internet
***


sec 4

extra space in "connection- oriented"


***
TCP Selective Acknowledgment
 [RFC2018] extends this mechanism by making it possible to identify
 missing segments more precisely, reducing spurious retransmission.
***

I would have thought that DupACKs without SACK are just as precise as SACK is - they just contain less information, and thus it takes longer to notify the sender of multiple holes in one window. So I would say "faster" instead of "more precisely" - and I'm also not sure SACK (without DSACK) reduces spurious retransmission. Why would it?


4.1.2

***
This interface does
 not describe configuration of TCP options or parameters beside use of
 the PUSH and URGENT flags.
***

=> this is the first mention of PUSH, making it hard to understand what PUSH is about. Note however that PUSH is optional to implement, and see my discussion with Karen about it on the list - maybe it could be a better alternative to just not even mention PUSH here.


***
There are current no documents in the RFC Series
 that describe this interface.
***

s/current/currently


***
congestion control: a window-based method that uses Additive
    Increase Multiplicative Decrease (AIMD) to control the sending
    rate and to conservatively choose a rate after congestion is
    detected.
***

I think only mentioning AIMD here is a bit weird - after all this only applies to long-running flows. I would at least also describe slow start.  AIMD needs a citation.


4.2.3

***
When aggregating capacity over multiple
 paths, and depending on the way packets are scheduled on each TCP
 subflow, an additional delay and higher jitter might be observed
 observed before in-order delivery of data to the applications.
***

=> remove "an" before "additional delay"


4.3.1

extra space in "un- ordered" and "user- messages"


4.4

missing space after comma in "error correction,congestion control"

Broken reference: {{I-D.ietf-tsvwg- rfc5405bis}}


This paragraph is confusing in the context of this section because it's strictly about IP, not UDP:

***
 On transmission, UDP encapsulates each datagram into an IP packet,
 which may in turn be fragmented by IP.  Fragments are reassembled
 before delivery to the UDP receiver.
***
=> I'd recommend removing it.


just before 4.4.2 begins: "etc" should be "etc."


4.5

space in UDP- Lite


4.5.1: another "etc"


4.5.3:

strange to have "(as for UDP)" listed only for some but not all features - maybe better to just say that this is completely the same as UDP except for the additional "real" UDP-Lite features. Or add (as for UDP) for *all* features that UDP-Lite shares with UDP.


NEXT: 4.6 DCCP

***
Specifically it includes core functions
  (feature negotiation, path state management, RTT calculation, PMTUD,
  etc): This allows applications to use a compatible method defining
  how they send packets and where suitable to choose common algorithms
  to manage their functions.
***

First, I think that "core functions" should be more specific - e.g. "core transport functions". Second, it's strange to say that this (DCCP including core functions) *allows* apps to use a compatible method - compatible with what? If I need to be compatible with what DCCP does, then this is a prescription, not something DCCP "allows" me to do. Finally, "This" after the colon should not be capitalized.


4.6.1

***
The protocol segments data into messages, typically sized to fit in
  IP packets, but which may be fragmented providing they are less than
  the maximum packet size.
***

I think s/less/smaller would be better here.


***
The protocol may
  support ordered or unordered delivery of data
***
This sounds as if ordered delivery of data is optional to implement in DCCP. Is that so? Else, s/may support ordered or/supports ordered and


***
There is also a
  Data Checksum option that when enabled, contains a strong CRC, to
  enable endpoints to detect application data corruption - similar to
  SCTP.
***
That sounds wrong, I don't think SCTP provides a checksum covering only the data. The data checksum option allows to acknowledge packets even though they had errors in the payload.


***
DCCP uses a Connect packet to initiate a session, and permits half-
  connections that allow each client to choose the features it wishes
  to support.
***
"permits half-connections" sounds strange to a reader who understands TCP; also, I'm not sure DCCP "permits" half-connections, aren't they always there? I would have thought that the concept of half-connections in DCCP makes it possible for each client to choose the features it wishes to support. Recommendation: s/permits/uses
The word "client" also seems strange here - as if we were talking about a server and multiple clients. Recommend: e.g. endpoint or peer.


4.6.2

strange formatting here, better to make a bullet list?


4.7

***
The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and
   [RFC4433] for IPv6 are IETF standards track protocols.
***

s/are/is  or s/Protocol/Protocols   (not sure which is better)


4.7.1

***
ICMP is a connection-less unidirectional protocol that delivers
   individual messages.
***

strange for the reader that this sentence is almost the same as the one 2 sentences earlier. Maybe just change the phrasing a bit. Or maybe drop the sentence and begin with the next as: "ICMP uses independent...".


***
 For example to implement, ICMP-based
   Path MTU discovery...
***
Comma should be after "For example", not after implement - but anyway this isn't a complete sentence. Better to connect to the preceding one, e.g. with a dash.


***
 Such reactions to
   received messages need to protects from off-path data injection
   [I-D.ietf-tsvwg-rfc5405bis], avoiding an application receiving
   packets that were created by an unauthorized third party.
***
s/protects/protect
suggest: "avoiding _that an application receives packets_ ..."  (current phrasing is wrong I think)


***
ICMP processing is integrated into many connection-oriented
   transports,
***
s/into/in  ?


4.7.3

I'm not so sure about the list here... it's obvious to use these lists to compare protocols, and this list would make ICMP seem to be almost similar to e.g. UDP - I mean, "message-oriented delivery" makes me ask "of what? of any data that I want to send from A to B?"  - technically this may be correct... but isn't it odd to present ICMP like a general-purpose message-based protocol?


4.8.1

***
RTP may run over a congestion-controlled or non-
   congestion-controlled transport protocol.
***

Suggest to remove because: how is that a property of the protocol? Everything can run over everything, pretty much... maybe say "is commonly run over a congestion controlled but also used over non-congestion controlled transport protocols" ?  if that's true at all...


***
RTCP is a control protocol that works alongside a RTP flow.
***
s/a RTP/an RTP  ?


4.9  (and 4.11 and 4.12) are not hyperlinks in the HTML ToC, what happened?


4.9.3

***
  error detection (through UDP).
***
I'd remove this from the list, same reason as above: UDP is UDP, that's not an inherent function of the protocol then...



4.10

***
NORM is designed to incorporate packet
   erasure coding as an inherent part of its selective ARQ in response
   to receiver negative acknowledgments.
***
suggest s/receiver/received  or "from the receiver" or something like that?


4.10.1

extra space in "round- trip" and "rate- control"


4.10.3

***
  o  error detection (UDP checksum).
***
suggest to remove, same argument as above


4.12

***
cases where a application server
***
s/a/an


***
provides
   some guidelines and concerns
***
odd to "provide a concern" - maybe s/provides/presents   ?


***
   HTTP 1.1's and HTTP 2.0's persistent connections can be use to
***
s/use/used



***
This reduces connection establishment overhead
   and the effect of the transport layer slow-start on each transaction,
   important in reducing latency for HTTP's primary use case.
***
suggest "which is" before "important"  (currently it's not a complete sentence)


***
which eliminates
   the latency of addition round-trips.
***
s/addition/additional


4.12.2

***
 If TLS is used, API expose a
***
missing "the" before API


Missing "the" before "World Wide Web Consortium (W3C)"


same sentence: s/use/used in "an API that can be use for sending"


***
Besides XML data format, request and
   response data format can also be JSON, HTML and plain text.
***
suggest: Besides the XML data format, the request ...."


***
Specifically JavaScript and XMLHttpRequest are a ubiquitous
   programming model
***
s/a/an


***
Representational State Transfer (REST) [REST] is another example how
   applications can use HTTP as transport protocol.
***
I think there should be "of" before "how".


***
REST is an
   architecture style for building application on the Internet.
***
misses "an" before "application"


4.12.13

This is the first occurrence of "   o  object range request."  and at least I don't intuitively get what that means... does it really fit in here? If so, please add it to the explanations of how the protocol works.

Also, which version is assumed for this list? Wouldn't it look slightly different for v1 and v2?

Also, the list probably misses some things for v2 - e.g. multiplexing (multi-streaming)


***
   HTTPS (HTTP over TLS) additionally provides the following components:
***

suggest s/components/features because everywhere else they are transport features, not components



5

The tables (fig 1 and fig 2) include entries "Poss" and "Pos" which are not self-explanatory. I guess "Poss" means "Possible" but what, then, does "Pos" mean?


***
The transport protocol components analyzed in this document that can
   be used as a basis for defining common transport service features,
   normalized and separated into categories, are as follows:
***

This is odd; having read the whole document, it doesn't strike me as an "analysis of transport protocol components" but as a survey of protocols and their transport features. This also makes me wonder if "Transport Protocol Component" shouldn't be removed from the terminology, the word "component" hardly ever appears in the document, so this term seems unnecessary.

Anyway the sentence above has another issue: it says: "The transport protocol components ..... are as follows" and then it is followed by the list of features from the protocols that were presented in the preceding sections. Why were they features before but all of a sudden they are components?



This bit also stands out:


***
      *  Application to port mapping (TCP, MPTCP, SCTP, UDP, UDP-Lite,
         DCCP, FLUTE/ALC, NORM, TLS, HTTP)

         +  with commonly deployed support in NAPT (TCP, MPTCP, UDP,
            TLS, HTTP)
***

The NAPT support seems pulled out of a hat? It doesn't seem to match the rest of the document or the section, where the impression is that this list is a summary of the list of features found earlier. Introducing such a seemingly made up item makes me wonder if the rest of the list truly maps to the lists of Transport Service Features presented earlier per protocol - it should, else this is strange and inconsistent.


=> Indeed it seems that there is some cleaning up to do. E.g. searching for "object-oriented delivery of discrete data or file items" takes me only to NORM, not to FLUTE/ALC or HTTP. So are the functions there really the same if they're not called the same? I think it's really important for the names of these features to be consistent throughout the document.


Just as a reminder, this:
***
         +  stream-oriented delivery (TCP, MPTCP, SCTP, TLS)

            -  with multiple streams per association (SCTP)
***
should probably also include HTTP if the version number covered is v2 - but I already commented on this above.