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

[Brian Trammell <[e-mail]>]

hi Karen, all,

Apologies for overlooking this message in last week's note about "things to do"; add "address Karen's comments from two months ago" to this list. :)

Inline:

> On 15 Jul 2015, at 16:28, Karen Elisabeth Egede Nielsen <[e-mail]> wrote:
> 
> 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 ?

This is a good point... 

What we were trying to capture here is that, in the present arrangement of the transport layer, the features we think of are not very far removed from the mechanisms that provide them, while in the transport layer we'd like to see in the future, the features can be expressed in terms closer to application-layer requirements than to transport-layer mechanisms.

Here, minimal latency could be better stated as "a preference to accept loss instead of buffer-induced latency", but on second thought this is hard to capture in a single sentence in the intro, so we'll remove "and minimal latency".

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

This is the direction we're leaning toward, perhaps with a bit less explanatory text (indeed, now I recall that it was our discussion about these comments in Prague that led to this direction...)

> 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 suspect many of the following comments will be overtaken by the reorganization of these sections to be feature- rather than component-centered. We'll keep them in mind during the reorg, though I will comment briefly on a few points...

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

At a feature level, yes. At the component level we were proposing with this text, they're not really separable.

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

Nagle is an oddity, and a perfect example of the mechanism and requirements getting completely tangled up in one another we're trying to avoid. But the name of the algorithmic mechanism is also a shorthand way that everyone who kind of understands TCP will recognize as the requirement...

Talking about it as a pure feature, it's "data bundling". The ability to *disable* Nagle is kind of irrelevant in a TAPS world -- indeed, *every* feature should be selectable.

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

Yep. The good way looks a lot closer to your suggestion than to what we proposed in -06.

Thanks, cheers,

Brian

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