Thread (30 messages) 30 messages, 9 authors, 2007-09-06

Re: [PATCH] make _minimum_ TCP retransmission timeout configurable

From: David Miller <davem@davemloft.net>
Date: 2007-09-06 20:40:03

From: "Ilpo_Järvinen" <redacted>
Date: Wed, 5 Sep 2007 22:04:11 +0300 (EEST)
Main obstacle to FRTO use is its deployment as it has to be on the
sender side where as wireless link is often the receiver's access
link but if one can tune tcp_min_rto (or equal) on the sender side,
one could enable FRTO at will as well.
Correct.

I've currently succumbed to the realization that no matter what we
tell these folks about FRTO they aren't interested in testing it as a
usable solution mostly because they already invested to time to find
out that min_rto gives them pretty much what they want.

I'd prefer they used an FRTO based solution but this is reality :)
Uninteresting enough, even IETF seems to 
interested in advancing FRTO from experimental [1].
That's great :)
A funny sidenote about the experiment, we found out what Linux
cannot do (from userspace only): it seems to be unable to receive
the same packet it has sent out to itself as we forced the packet
out from eth0 by binding sending dev to eth0 and received from ppp0
=> the packet gots always discard as martian and there seems to be
no knob to that, so had to hack it :-).
Yes, and this is loosely related to the "send to self" patches
that come up from time to time because Linux naturally wants
to just loopback in software any packet you try to direct out
a real interface that matches a local host address.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help