Date: Wed, 20 Jan 1999 22:39:54 +0000 From: Chrisy Luke <chrisy@flix.net> To: Wolfgang Rupprecht <wolfgang@wsrcc.com>, Gregory Bond <gnb@itga.com.au> Cc: Brian Del Vecchio <bdv@parlez.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Cisco/Intel Ethernet Trunking Message-ID: <19990120223954.E13293@flix.net> In-Reply-To: <13990.23043.921555.147980@capsicum.wsrcc.com>; from Wolfgang Rupprecht on Wed, Jan 20, 1999 at 02:34:43PM -0800 References: <199901202228.JAA00466@lightning.itga.com.au> <13990.23043.921555.147980@capsicum.wsrcc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wolfgang Rupprecht wrote (on Jan 20): > The problem is not really out-of-order reassembly, but out of order > packets triggering the fast-retransmit logic. Basically the receiver > sees the out of order packet and thinks a segment has been lost and it > retransmits a duplicate ack for the last packet. The transmitter sees > the dup ack, figures the next segment has been lost and retransmits > that. Then of course, anyone with lines slow and over utilised enough for it to happen deserves the performance they get. :-) It's not the scenario the idea is intended for. It's been known for a long time weighted or true "load-balancing" at packet level has problems with procotols that depend on any form of fragmentation (like packets). MPP over dialup lines has enough problems - particularly when over multiple access servers. The variance in packet forwarding time and link latency means you get significantly less than the performance gains you would expect. Chris. -- == chris@easynet.net, chrisy@flix.net, chrisy@flirble.org == Systems Manager for Easynet, part of Easynet Group PLC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990120223954.E13293>