Date: Tue, 23 May 2006 09:07:45 -0400 From: Mark Allman <mallman@icir.org> To: mag@intron.ac Cc: freebsd-net@freebsd.org, Marcin Jessa <lists@yazzy.org> Subject: Re: How to Quicken TCP Re-transmission? Message-ID: <20060523130745.94E5D41696D@lawyers.icir.org> In-Reply-To: <courier.4471DD94.00004736@intron.ac>
next in thread | previous in thread | raw e-mail | index | archive | help
--=_bOundary Content-Type: text/plain Content-Disposition: inline > 1. Receiver should tell sender to re-send as soon as possible. > (But TCP makes receiver purely passive) This isn't really going to help you at all. With SACK (especially, but even without it) the receiver isn't really in a whole lot better position than the sender to judge when a packet is actually lost. Some people have worked on SNACKs (selective NEGATIVE acknowledgments), but my opinion is that the results (that I have seen) show them to be fairly equivalent to SACK in terms of performance. > 2. Receiver should tell sender what is really necessary to re-send. > (Sometimes only a single ACK number of TCP cannot include enough > information) RFC2018. (Which provides more than a single ACK number. But, this doesn't make the receiver tell the sender what to resend. The logic still resides at the sender.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEcwkhWyrrWs4yIs4RArY+AJ9RBNZY2RfckhsKe6ta+wryZIN/4ACfVho7 6jTPBvZ2AFgnZc7KjWoHx1I= =yR/N -----END PGP SIGNATURE----- --=_bOundary--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060523130745.94E5D41696D>