On Mon, 31 Jul 2006, Oumer Teyeb wrote: > -If multiple timeouts occur for one packet then even if we are using the > timestamp option or FRTO TCP linux is not able to detect spurious > retransmissions... and TCP linux is able to detect spurious retransmissions > only for a single timeout for one packet or fast retransmissions that are > caused by duplicate ACK reception.....I have some traces that show this > behaviour, let me know if you are interested.
I have come across this same issue. I can confirm that multiple RTOs is not handled correctly. But there are some other issues in FRTO as well... nothing extremely dangerous though. In one of the cases, the current FRTO algorithm could miss real losses, but you luckily need to be quite clever to trigger that, and due to very conservative response used in case spurious RTO is detected, it has no significant danger in it even then. The other flaws cause too conservative behavior. We have a set of fixes to F-RTO, but part of them have not yet been tested. Since the fixes include 4-5 independent changes to handle also rare cases, it takes some time to test. Besides, I'll probably have to talk with Pasi Sarolahti (author of FRTO) on couple of interpretation issues in RFC4138 as soon as his vacation ends (mid August if I remember correctly) to verify some of the changes. I expect that I'll get some actual results after two weeks or so... I case you're are in hurry and are interested on the fixes, I could prepare an independent patch quite soon and release it (untested) on our projects web site (if you are interested, ask off-list so that we don't bother others :-)). But the kernel inclusion of the fixes should IMO wait at least until I get some decent test cases analyzed, which will take at least two weeks or so due to my schedule. > -In the cases where TCP timestamp or FRTO is not able to detect spurious > retransmissions, the performance degrades even more than when TCP timestamp > or FRTO option are not used.... That's one of the FRTO "features", we have a fix (I cannot say about timestamps since we've been running our tests without tstamps for years). -- i. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
