Date: Tue, 30 Nov 1999 20:58:02 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: freebsd-net@FreeBSD.ORG Cc: archie@whistle.com, dg@root.com, rousskov@ircache.net Subject: Re: interaction between Nagle's algorithm and TCP delayed ACKs Message-ID: <19991130205802.A66619@prism.flugsvamp.com>
next 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. 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. -- 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?19991130205802.A66619>