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.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
