> On 2. feb. 2015, at 19.03, Joe Touch <[email protected]> wrote: > > > > 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.
I’m for keeping this first document correct and complete. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
