Thanks Ilpo for the info!
I am trying out the tests now using timestamps only and without FRTO,
and vice versa and see if there is any change.
Actually, I have also noticed in some of the traces also this behaviour
of FRTO where it mistook a loss as spurious which leads to further
performance degradtion. but I was also using timestamps, so I dont know
if it also occurs without timestamps. I will try it out and let you
know. I will send you the traces I just mentioned (FRTO+timestamps
leading to a loss being mistaken for a spurious one..)..
Regards,
Oumer
Ilpo Järvinen wrote:
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).
-
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
