3 ms·
There was a recent video or article posted here discussing the poor interaction between Nagle's Algorithm/Delayed ACK/TCP slow-start and how it results in incre
by pests 11y ago
There was a recent video or article posted here discussing the poor interaction between Nagle's Algorithm/Delayed ACK/TCP slow-start and how it results in increased latency, especially for the first few packets.
From a first read it sounds like the decisions made in both BSD and Linux could also be adding to the latency problem for the first initial packets.
Have OSes checked how their TCP backlog implementation affects the various congestion control algorithms being used?
- Animats 11y agoDifferent problem. The bad interaction between the Nagle Algorithm and Delayed ACK still irks me. I designed one, somebody at Berkeley designed the other, and by the time I found out about it, I was out of network architecture and doing something else for a different company. That 200ms fixed timer in delayed ACK was a bad idea. The whole delayed ACK thing was a hack to reduce overhead for character-by-character Telnet, which mattered to Berkeley back then because Berkeley used a lot of dumb terminal servers. The fixed time delay is based on human response time and the time UNIX needed to process a character echo. If a typed character has to be echoed, the ACK can be piggybacked on the reply packet with the echo. This is one of the few cases in which delayed ACK is a win. It might also be a win with some quick request-reply APIs. Really, delayed ACKs should be off by default, and should only turn on when the connection has been showing a consistent pattern of "packet received, ACK sent, application quickly transmitted reply so ACK could have been combined with reply." John Nagle
- dboreham 11y agoI recall emailing you about this in 1996 when I worked on LDAP at Netscape and being rather surprised to receive a reply! Good times...