Date: Wed, 1 Dec 1999 10:43:05 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: David Greenman <dg@root.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <19991201104305.D67400@prism.flugsvamp.com> In-Reply-To: <199912010447.UAA01534@implode.root.com> References: <19991130205802.A66619@prism.flugsvamp.com> <199912010447.UAA01534@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 30, 1999 at 08:47:59PM -0800, David Greenman wrote: > >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). [ snip ] > >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. > I agree that the value should probably be lowered to at least 100ms, as this was the statistical average of the previous implementation. However, I'm not sure that lowering it further will provide much of a benefit in some situations as opposed to just turning it off completely. The reason for this is that when you turn off delayed acks, then you get one ack for every incoming packet, while normally (with the delay), TCP will attempt to ack every other packet. Now, if the delayed ack time is reduced to a value which is smaller than the spacing between the incoming packets, you still get one ACK per segment, but it is delayed, probably causing an inflated RTT estimate. As an example, I ftp'd a file from the WC server. The incoming inter-packet packet spacing that I normally see is roughly 35ms. When I lower the delayed ack timer to 20ms, this causes an ack to be sent for each segment, but which is delayed 20ms. So in this particular situation, we lose, as there is neither any ACK aggregation nor a lower RTT. -- Jonathan 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?19991201104305.D67400>