Date: Fri, 3 Mar 2000 12:26:41 -0800 From: jayanth <jayanth@yahoo-inc.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: =?iso-8859-1?Q?R=E9mi_Guyomarch?= <rguyom@mail.dotcom.fr>, net@FreeBSD.ORG Subject: Re: TCP performance problems, Linux faster than FreeBSD ? Message-ID: <20000303122641.B23208@yahoo-inc.com> In-Reply-To: <20000303135950.C307@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Fri, Mar 03, 2000 at 01:59:50PM -0600 References: <local.mail.freebsd-net/20000303165052.C23732@pingoo.ifn.fr> <200003031759.LAA03466@prism.flugsvamp.com> <20000303194730.A26727@pingoo.ifn.fr> <20000303125536.A307@prism.flugsvamp.com> <20000303195724.A26837@pingoo.ifn.fr> <20000303135950.C307@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Was the SACK feature being used for the connection from the Linux machine ? jayanth Jonathan Lemon (jlemon@flugsvamp.com) wrote: > Okay, I took a look at the trace you sent me, and yup, the answer > is, "they're broken". :-( > > Somewhere in the transfer, some packets are getting lost, which > in turn leads to the following steady-state scenario: > > After 3 duplicate acks (caused by receiving older re-transmitted packets), > the sender (mistakenly) presumes that a packet was lost and re-transmits, > in accordance to the VJ fast-retransmit algorithm. Call the sequence > number of this re-transmitted packet 'A'. The sender continues sending > at the leading edge of the window, say, on sequence 'F'. > > Now, another older retransmitted packet is received, and a 4th duplicate > ack is sent. This appears to cause the sender to abandon transmitting > at the leading edge of the window, and start re-transmitting segments > B-F at full speed. > > Since at this point, no packets are being lost, the receiver gets the > original sequence 'F', that was transmitted, then must ack the duplicate > retransmits. This leads to duplicate acks, starting the whole cycle again. > > > I would guess the problem is primarily caused because the sender does > not correctly implement VJ fast-recovery, and slow-start is never > entered, so there is no chance for re-synchronization. > > Linux implements SACK (selective ack), which I would guess allows it > to work around this problem; it doesn't have to send multiple duplicate > acks in a row. > > 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?20000303122641.B23208>