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

[Joe Touch <[e-mail]>]

Hi, Karen,

On 7/16/2015 12:27 AM, Karen Elisabeth Egede Nielsen wrote:
...
>> 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 ?

There should probably be two levels:

	- minimize what you add at the transport layer

	- reduce even further

> Are we thinking about Nagle OFF ?

That is how TCP might react to a request to minimizing added latency,
but I don't expect a TAPS API should expose the specific knob of "Nagle".

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

Absolutely. Connection oriented means there is state that persists
between messages. To be useful, that state needs to be controllable.
Negotiating features *is* controlling that state.

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

I would think that should be clarified.

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

Because latency depends on the sizes of the messages, it should not be a
surprise that latency can't be minimized without that context.

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

This is difficult for TCP to handle, because TCP thinks of the input
stream as an ordered sequence of bytes, and the issue of latency is
related to message boundaries within the TCP stream that are NOT part of
the TCP API (there's no way for an application to indicate those
boundaries to TCP - and no, the SEND boundaries are explicitly NOT those
markers).

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

Sure, but that's also why it doesn't make sense for TCP.

Joe