Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt

[Karen Elisabeth Egede Nielsen <[e-mail]>]

Hi,

Please find a very few comments to the document. Nothing major. Please use
if you see fit and only then :-)

Section 1: End First Paragraph:

Here it is said that a transport service feature may be minimal latency.
Opposed to the other features listed here,
like e.g. in-order or reliable delivery, then minimal latency seems a more
delicate obtainable feature; How one best obtain it
within the services provided by a certain transport protocol, may depend
quite heavily on the application traffic pattern (unless CPU and network
resources are unlimited).
Also minimal latency is not a feature which any of the protocols described
in the document has within its list of features (I think) or
are you thinking minimal latency and best effort transport service (like
UDP) - Or are you thinking some smart protocol of the future which will
deduce how to best
provide a minimal latency service for a particular application flow over a
specific E-to-E path ?

Section 3.1.2:

Not sure if this way of describing the TCP Protocol Components is the
right way to do.

I think that it would be nice to have the list here use Transport Service
Features names
and then possibly - if relevant as it is done now - describe in more
detail how the TCP Component implement the Transport Service Feature.
I further think that one should strive -  best possibly - to use the same
Transport Service Features for the different protocols when applicable.

Like (some easy examples) for TCP:

o  Single stream-oriented transmission:

      The stream abstraction atop
      the datagram service provided by IP is implemented by dividing the
      stream into segments.

o  Flow control:

      Window-based flow control, with receiver-side window management
      and signaling of available window: Scaling the flow control window
      beyond 64kB requires the use of an optional feature, which has
      performance implications in environments where this option is not
      supported; this can be the case either if the receiver does not
      implement window scaling or if a network node on the path strips
      the window scaling option.

o  Congestion Control:

      Window-based congestion control reacting to loss, delay,
      retransmission timeout, or an explicit congestion signal (ECN):
      Most commonly used is a loss signal from the reliability
      component's retransmission mechanism.  TCP reacts to a congestion
      signal by reducing the size of the congestion window;
      retransmission timeout is generally handled with a larger reaction
      than other signals.

I am not sure if Connection oriented  and Feature negotiation should be
split into two features ?

I am not sure if one wants something called Fast Transmission Start - or
simply Fast Open - as a feature ?

I am not sure what the slogan of the present bullet about Nagle should be.
Also I am not so sure about the content of this section.
Disabling Nagle does not always give the lowest latency and further then I
think that we are missing the good side of Nagle in the present text.
(the bundling of multiple stream segments into packets  and its benefits)

I do not think that it is relevant to describe how SACK helps reduce the
latency of Fast Recovery.
 If so, one could also describe how it improves the congestion control
handling - or ? . Is it at all relevant to consider TCP without SACK
enabled ?
Generally I am not so sure what the latency discussion in this section is
about. It says that "the retransmission timeout defines the upper
bound...". But exp back-off _is_ used in TCP, further the statement is
really only true if RTO-restart is used.
Should one not rather say that RTO-based loss detection reacts based on
timeouts - or why does one say anything at all here ? Is it to try to
describe if the protocol provides some upper bound for
the latency - if so that is more provided via MAXRT ?. The RTO gives an
upper bound for when to retransmit - not as such on the reliable delivery.
Then on top one have the delay in the SND buffer.
Generally the protocol is continuously being evolved to provide low
latency loss recovery operation. Perhaps this is relevant to state ?

General:

I assume that once one has settled a good way of describing the TCP
Components, then one will try to align the other sections.
Or alternatively one go back now and try to settle the list of Abstract
Transport Service Features that existing transport protocol provides - and
then afterwards
updates the various  Transport Protocol Components sections in this doc,
including the TCP one.

Thanks.
BR,  Karen

>-----Original Message-----
>From: Taps [mailto:[e-mail]] On Behalf Of internet-
>[e-mail]
>Sent: Tuesday, July 07, 2015 12:07 AM
>To: [e-mail]
>Cc: [e-mail]
>Subject: [Taps] I-D Action: draft-ietf-taps-transports-06.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Transport Services Working Group of the
IETF.
>
>        Title           : Services provided by IETF transport protocols
and congestion
>control mechanisms
>        Authors         : Godred Fairhurst
>                          Brian Trammell
>                          Mirja Kuehlewind
>	Filename        : draft-ietf-taps-transports-06.txt
>	Pages           : 39
>	Date            : 2015-07-06
>
>Abstract:
>   This document describes services provided by existing IETF protocols
>   and congestion control mechanisms.  It is designed to help
>   application and network stack programmers and to inform the work of
>   the IETF TAPS Working Group.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-taps-transports/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-taps-transports-06
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-06
>
>
>Please note that it may take a couple of minutes from the time of
submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>Taps mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/taps