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

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

Hi Joe,

>-----Original Message-----
>From: Joe Touch [mailto:[e-mail]]
>Sent: Thursday, July 16, 2015 7:49 PM
>To: Karen Elisabeth Egede Nielsen; [e-mail]
>Cc: [e-mail]
>Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt
>
>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.
>
[Karen ] Yes. OK.
>...
>>> 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.
>
[Karen ] Good. Perhaps a clarification also can come with enforcing the
bundling aspects of the segmentation paragraph.

>>  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).
>
[Karen ] sure.

>> 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.
>
[Karen ] Yes and then also why Nagle off for TCP may give undesired and
contra-productive results from a latency perspective.
But then TCP applications may not typically have the application traffic
patterns that gives these undesired latency effects of disabling Nagle.

BR, Karen
>Joe