Patrick McHardy wrote:
> OBATA Noboru wrote:
> > From: OBATA Noboru <[EMAIL PROTECTED]>
> >
> > Make TCP_RTO_MAX a variable, and allow a user to change it via a
> > new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
> > then guarantee TCP retransmission to be more controllable, say,
> > at least once per 10 seconds, by setting it to 10. This is
> > quite helpful on failover-capable network devices, such as an
> > active-backup bonding device. On such devices, it is desirable
> > that TCP retransmits a packet shortly after the failover, which
> > is what I would like to do with this patch. Please see
> > Background and Problem below for rationale in detail.
>
>
> Would it make sense to do this per route?
Well, for a certain case, maybe yes.
For example,
(1) You have both a fast route (link) and a slow route,
(2) You want to use a short RTO for the fast route and not for
the slow route, and
(3) Routes are static, as mentioned by Siim.
On such a case, only a global tcp_rto_max, which is set to a
very small value, may overload the slow link due to many
retransmission packets. Then, as Stephen mentioned, people will
find it useful to have per route tcp_rto_max.
But let me give you some number.
The number of retramsmission packets in the first 60[s] on
tcp_rto_max = 10[s], starting from RTO = 0.2[s], are:
10 with tcp_rto_max = 10[s], where
8 with tcp_rto_max = 120[s] (original).
Only extra 2 packets per minute per socket should be acceptable
in most cases.
So if you choose a moderate tcp_rto_max, you may not necessarily
need per route tcp_rto_max.
Regards,
--
OBATA Noboru ([EMAIL PROTECTED])
-
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
