> 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
pgp2iQv70NgDB.pgp
Description: PGP signature
