Date: Fri, 13 Apr 2007 16:55:23 -0400 From: Mark Allman <mallman@icir.org> To: Mike Silbersack <silby@silby.com> Cc: freebsd-net@freebsd.org, LI Xin <delphij@delphij.net>, "Bruce M. Simpson" <bms@freebsd.org> Subject: Re: [PATCH] kern/681110 re-roll of RFC3522 (Eifel detection) patchset Message-ID: <20070413205523.83AAC1D1E76@lawyers.icir.org> In-Reply-To: <20070412095035.N77693@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > That sounds like an option... but is it worth it? Can you give us > access to your testbench that shows eifel to be an important > improvement over the current eifel-less stack we have right now? My > guess is that SACK nullified most of eifel's importance. SACK doesn't help in the domain where Eifel plays. The observation that led to Eifel is that sometimes the network sort of hicups and delays a stream of packets for a bit longer than usual. So, nothing is lost, but packets are delayed. So, since there is no loss there will be no SACK. If this delay lasts long enough then the RTO of the sender will expire and the sender will start retransmitting. And, in fact, will retransmit a whole window of stuff that doesn't really need retransmitted. Eifel tries to detect this case where the RTO expired and caused a spurious retransmission by looking at the timestamp on the first ACK to roll in after the RTO. F-RTO plays a different trick by carefully manipulating which data is transmitted after an RTO such that it can gain the same insight (i.e., whether the RTO was spurious). So, just because you have SACK doesn't mean you don't need Eifel. The work Vern Paxson and I did a lot of years back that I cited the other day shows that these hicups / delay spikes are pretty rare and if you use the RTO given in RFC 2988 then you won't fall prey to this effect much on the general Internet. Our measurements are now old. Things might have changed. I am aware of no more recent measurements that confirm or refute our's. Now, there is a claim that in mobile environments these sort of hicups happen quite often and so having something like Eifel is quite important. IMHO, this is not clear either way. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGH+47WyrrWs4yIs4RAlB2AJ49fvrqh45+XoXT+BotWMUvN2io1QCdEQqN CYbNh9NPOx7AWkqlQqil+GU= =zI0z -----END PGP SIGNATURE----- --=_bOundary--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070413205523.83AAC1D1E76>