Hi Joe, >-----Original Message----- >From: Joe Touch [mailto:[email protected]] >Sent: Thursday, July 16, 2015 7:49 PM >To: Karen Elisabeth Egede Nielsen; [email protected] >Cc: [email protected] >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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
