Date: Tue, 30 Nov 1999 20:47:59 -0800 From: David Greenman <dg@root.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <199912010447.UAA01534@implode.root.com> In-Reply-To: Your message of "Tue, 30 Nov 1999 20:58:02 CST." <19991130205802.A66619@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Archie Cobbs <archie@whistle.com> writes: >> David Greenman writes: >> > >The vendors also say that Linux TCP stack does not emit that many ACKs >> > >while not suffering from extra delays that default FreeBSD settings >> > >create (i.e., Linux folks allegedly found some magic "golden middle" >> > >that satisfies everybody). We have not verified these claims. >> > >> > It could be that delayed ACKs aren't delayed as long in Linux. We >> > could do the same thing in FreeBSD by shortening it down to say 10ms >> > or something. That would allow the ACKs to be aggregrated with the >> > character echoes while still keeping the response time fairly quick. >> > Delayed ACKs are evil in other ways, however. For one thing they add >> > noise and additional delay to the estimated RTT. >> >> Do the delayed ACK's have a fixed timeout, or is it proportional to >> the estimated RTT? It seems like in the former case, you're always >> going to find a situation where the timeout is too long. To avoid >> this the delayed ACK timeout should be some percentage of the >> estimated RTT. > >Well, in -current, at least, the delack time is under a sysctl, so you >can change it to anything you want. In -current, the time that the >ACK is delayed is exactly this much (assuming no other traffic that it >can be piggybacked on). On -stable, it uses a fixed 200ms timer, so >the delay for a specific ACK can vary from 0 - 200 ms. One thing that has changed in -current is the average delay. It used to be 100ms and it is now 200ms. We should at least change the default to be 100ms, and I think even much lower (see below). >Linux uses a "quick ack" timer at the beginning of the connection to >coerce the other side to leave slow start quickly. This probably does >wreak some havoc with RTT estimates, and I'm not convinced it's the >right thing to do. > >A pronounced example of the delack problem is FTP transfers; after the >data channel opens, information flows only one way. So on startup, the >sender sends one packet (as allowed by it's congestion window), but the >receiver delays its ACK in hopes that it can piggyback the ACK on some >(nonexistent) data flowing back to the sender. So after the ftp data >session starts and after the first packet is transmitted, absolutely >nothing is happening on the network. Agreed. The purpose of the delayed ACK is to give a process a chance to respond with something and thus piggyback the ACK. Computers these days are very fast and I see no good reason to not lower the delay to 20ms (more accurately, two clock ticks). I'd say 10ms (next clock tick) except that due to lack of timer resolution, we'd end up with 0-10ms with an average of 5ms, and I'd rather it was 10-20ms with an average of 15ms. In any case, this would seem to me to settle the issue about untimely delayed ACKs while preserving the ACK aggregation capability and also improving the accuracy of the RTT estimate. Note that prior to Jonathan's new tcp_timer code, lowering the timeout that low would have had serious CPU overhead problems on server systems, but this is no longer a significant concern. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912010447.UAA01534>