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

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

HI Joe,

>
>
>On 7/15/2015 7:51 AM, Karen Elisabeth Egede Nielsen 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 ?
>
>FWIW, UDP doesn't minimize latency; it (arguably) minimizes the latency
>created by the transport layer at the expense of ordered, reliable
delivery and
>congestion control.
>
[Karen ] I agree.

>So there are several levels of the latency issue:
>
>	- minimize the latency ADDED by the transport layer
>	- reduce the latency seen by the app
>	(which can involve more active interaction with the network
>	layer, anticipation, etc.)
>
>Note also that latency is not a single metric nor a meaningful standalone
>metric:
>
>	1. latency between two parties is a property *of a message*,
>	i.e., it requires knowing the message size
>
>	2. latency includes both basic and higher order effects;
>	the basic is "delay", the higher order include "jitter" etc.
>	Many common delay-sensitive use cases are really mostly
>	jitter sensitive.
>
>...
[Karen ] I agree so what do we mean in this document when we say that
a transport service feature can be to provide minimal latency ?
Are we thinking about Nagle OFF ?

>> I am not sure if Connection oriented  and Feature negotiation should
>> be split into two features ?
>
>If you don't share state (i.e., what we tend to call a "connection"),
what is the
>meaning of feature negotiation?
>
[Karen ] Yes, but does connection oriented necessarily means that you can
negotiate features ?

>...
>> 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.
>
>Nagle reduces the number of small packets at the expense of introducing
>transport delay. Turning it off increases the number of small packets and
>reduces the transport delay.
>
>Although it's theoretically possible for the larger number of packets to
cause
>delays larger than those that Nagle aggregation would induce, in practice
the
>Nagle delays are several orders of magnitude larger.
>
>Using byte-based congestion control, the larger number of packets would
>have no effect. Using packet-based congestion control, the larger number
of
>packets would reduce latency (by opening up the window faster, keeping it
>open longer, etc.) unless the increased number of packets itself is the
>bottleneck.
>
>So the general assumption that turning off Nagle will reduce latency
should be
>reasonable.
[Karen ] I agree with this as a general assumption.
But when I read the paragraph in the doc it almost sounds as if turning
Nagle off comes with no price.

 Do you have a counterexample seen in the wild?
>
[Karen ] Yes we have examples with NO Nagle where the number of packets
then becomes the bottleneck.
In the local ends (CPU) as well as in the infrastructure elements. I am
not sure how much of this information I can share.
I can try to find out. That is why I was saying that how to provide
minimal latency may depend on the application traffic.
How to solve also depends on whether it is the average latency that needs
to be minimal or whether the latency for some particular application
"messages" should be kept
as low as possible.

For SCTP we allow for that Nagle is disabled on some streams (streams with
high scheduling priority) and not on others. This is done exactly for this
purpose.
(There is an IPR on this I have to say).

BR, Karen

>Joe