On 1/30/2015 7:20 AM, Wolfgang Beck wrote:
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.
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'.
UDP doesn't queue, but UDP implementations do. The interface between
applications and UDP does too.
Maybe some general discussion of the interactions between application
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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
