[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20070906.133949.112618148.davem@davemloft.net>
Date: Thu, 06 Sep 2007 13:39:49 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: ilpo.jarvinen@...sinki.fi
Cc: rick.jones2@...com, ian.mcdonald@...di.co.nz,
netdev@...r.kernel.org
Subject: Re: [PATCH] make _minimum_ TCP retransmission timeout configurable
From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists