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

From: Michael Welzl <[email-masked]>
Date: Sun, 1 Feb 2015 21:48:29 +0100

> On 1. feb. 2015, at 08.51, [email-masked] wrote:
> 
>> Would it make sense to include statements about latency?
>> 
> I think if we come to think about the API that could be presented by TAPS
> to the application, we'll need to focus on what characteristics the Apps
> expect from the network. Low latency is clearly one service that many apps
> will desire.

Then again, we may decide to reserve this for doc #2?
My thinking was that this should be the home of such generalization (which is one way to reduce the number of services exposed).

>> We recently had a discussion with one of our suppliers about application
>> layer timeouts that fired while the request was still stuck in the send
>> queue.
>> 
>> There were statements like 'UDP never queues' or 'we can't control the TCP
>> send buffer size'.
>> 
>> Maybe some general discussion of the interactions between application
>> layer
>> timers and transport layer retransmission strategies (like Nagle) would be
>> useful.
>> 
> I agree, some words on the Latency introduced by mechanisms would be good.

If you go that way, here’s one of the drafts preceding the BOF, and written for the purpose of this group, as possible for input:
http://tools.ietf.org/html/draft-petlund-latency-transport-services-00 <http://tools.ietf.org/html/draft-petlund-latency-transport-services-00>

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Feb 2015 10:03:49 -0800

> Would it make sense to include statements about latency?

Yes, but I'm not sure what at this point.

Latency is a multidimensional property; it depends on the interaction of 
a variety of factors, so even if you wanted to have the application say 
"I want low latency", that's not well-defined.

> There were statements like 'UDP never queues' or 'we can't control the
> TCP send buffer size'.

UDP doesn't queue, but UDP implementations do. The interface between 
applications and UDP does too.

> layer timers and transport layer retransmission strategies (like Nagle)
> would be useful.

That's a really good example of how poorly understood this problem is.

Nagle should be off for multi-byte transaction protocols using TCP, but 
TCP isn't a low-latency protocol to start with. Nagle is as much about 
minimizing short packets as it is about the effect on transaction 
interaction delay.

However, it's also well-understood that Nagle should be off for 
transactions involving multiple bytes - whether that's because the 
transaction itself is larger (e.g., web transactions) or because the 
character encoding is larger (e.g., telnet using Unicode rather than 
ASCII). (J. Heidemann, K. Obraczka, J. Touch, “Modeling the Performance 
of HTTP Over Several Transport Protocols,” IEEE/ACM Transactions on 
Networking, V5, N5, Oct. 1997, pp.616-630.)

The fact that TCP doesn't have a way for the application to signal a 
transaction boundary (it's a byte stream model) means that the entire 
issue of latency of transactions over TCP is questionable.

--

So, in summary, yes, an API from transport to the service layer should 
have an indication of latency, but this is a very complex, 
*bidirectional* interface. So other than saying that this should be 
addressed in the future, anything said now will be at best woefully 
incomplete, and at worst, wrong.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Mon, 2 Feb 2015 21:48:34 +0100

> On 2. feb. 2015, at 19.03, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> Latency is a multidimensional property; it depends on the interaction of a variety of factors, so even if you wanted to have the application say "I want low latency", that's not well-defined.
> 
> UDP doesn't queue, but UDP implementations do. The interface between applications and UDP does too.
> 
> Nagle should be off for multi-byte transaction protocols using TCP, but TCP isn't a low-latency protocol to start with. Nagle is as much about minimizing short packets as it is about the effect on transaction interaction delay.
> 
> However, it's also well-understood that Nagle should be off for transactions involving multiple bytes - whether that's because the transaction itself is larger (e.g., web transactions) or because the character encoding is larger (e.g., telnet using Unicode rather than ASCII). (J. Heidemann, K. Obraczka, J. Touch, “Modeling the Performance of HTTP Over Several Transport Protocols,” IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630.)
> 
> The fact that TCP doesn't have a way for the application to signal a transaction boundary (it's a byte stream model) means that the entire issue of latency of transactions over TCP is questionable.
> 
> --
> 
> So, in summary, yes, an API from transport to the service layer should have an indication of latency, but this is a very complex, *bidirectional* interface. So other than saying that this should be addressed in the future, anything said now will be at best woefully incomplete, and at worst, wrong.

I’m for keeping this first document correct and complete.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Feb 2015 13:05:57 -0800

On 2/2/2015 12:48 PM, Michael Welzl wrote:
>> So, in summary, yes, an API from transport to the service layer
>> should have an indication of latency, but this is a very
>> complex,*bidirectional*  interface. So other than saying that this
>> should be addressed in the future, anything said now will be at
>> best woefully incomplete, and at worst, wrong.
 >

In that case, I suggest that latency issues be listed under "TBD". The 
only way to deal with them currently is via interfaces that describe HOW 
an existing mechanism is to be configured, not WHAT the goal of that 
configuration is.

Joe