Date: Mon, 14 Feb 2005 23:31:25 -0500 From: Mark Allman <mallman@icir.org> To: Sam Jansen <sam@meta.net.nz> Cc: freebsd-net@freebsd.org Subject: Re: SACK problems Message-ID: <20050215043125.A8907241AE3@lawyers.icir.org> In-Reply-To: <420BCEF7.1080603@meta.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-= Content-Type: text/plain > During some testing on an isolated network we have, I found some > interesting behaviour from a FreeBSD 5.3 host using TCP SACK. > > I've detailed this problem fully at: > > http://www.wand.net.nz/~stj2/nsc/emu_freebsd.html > > PCAP traces and some screenshots from tcptrace graphs can be found > at the above link to show what is happening. It looks to me like > SACK blocks are being incorrectly generated in this example. I can't > think of any valid reason why a SACK block would SACK from below the > current ACK value to above it (which is the problem here). > > Thoughts, anyone? Am I just wrong here and this is valid, expected > behaviour? RFC2883 offers a case when this would happen --- in the reporting of "duplicate SACKs". I.e., the DSACK extension reports segments that have arrived more than once. I don't suppose this is the problem (since it's freebsd everywhere, right?). But, while folks are messing about in the SACK code this RFC might be something to think about including. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCEXsdWyrrWs4yIs4RAj4iAJ9fkHmvFCw09AjbI1YN0UGv7xuYMQCfW3y3 gSuIcjNfO506s99weZriBv4= =Wjr3 -----END PGP SIGNATURE----- --=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050215043125.A8907241AE3>