Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <ff92251cb49f5f5ce639057a4118b234@mail.gmail.com>
Date: Tue, 15 Sep 2015 17:08:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EC3BF52-C1FF-4E64-9F66-644D1F1570F2@trammell.ch>
References: <20150706220631.6336.219.idtracker@ietfa.amsl.com>
 <ff92251cb49f5f5ce639057a4118b234@mail.gmail.com>
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/uyGEB5A-ryk-1FVI4JNxlcpojLg>
Cc: taps@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt
Precedence: list

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 =
<karen.nielsen@tieto.com> wrote:
>=20
> Hi,
>=20
> Please find a very few comments to the document. Nothing major. Please =
use
> if you see fit and only then :-)
>=20
> Section 1: End First Paragraph:
>=20
> 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...=20

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".

>=20
> Section 3.1.2:
>=20
> Not sure if this way of describing the TCP Protocol Components is the
> right way to do.
>=20
> 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:
>=20
> o  Single stream-oriented transmission:
>=20
>      The stream abstraction atop
>      the datagram service provided by IP is implemented by dividing =
the
>      stream into segments.
>=20
> o  Flow control:
>=20
>      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.
>=20
> o  Congestion Control:
>=20
>      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 ?
>=20
> 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 ?
>=20
> General:
>=20
> 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
>=20
>> -----Original Message-----
>> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of internet-
>> drafts@ietf.org
>> Sent: Tuesday, July 07, 2015 12:07 AM
>> To: i-d-announce@ietf.org
>> Cc: taps@ietf.org
>> Subject: [Taps] I-D Action: draft-ietf-taps-transports-06.txt
>>=20
>>=20
>> 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.
>>=20
>>       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
>>=20
>> 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.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-taps-transports-06
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-06
>>=20
>>=20
>> 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.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>=20
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps