[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ef84de89c2597793d4cca5eee446ba90@localhost>
Date: Thu, 19 May 2011 10:02:07 +0200
From: Hagen Paul Pfeifer <hagen@...u.net>
To: Alexander Zimmermann <alexander.zimmermann@...sys.rwth-aachen.de>
Cc: tsuna <tsunanet@...il.com>, David Miller <davem@...emloft.net>,
<kuznet@....inr.ac.ru>, <pekkas@...core.fi>, <jmorris@...ei.org>,
<yoshfuji@...ux-ipv6.org>, <kaber@...sh.net>,
<eric.dumazet@...il.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tcp: Implement a two-level initial RTO as per draft RFC 2988bis-02.
On Thu, 19 May 2011 08:52:10 +0200, Alexander Zimmermann wrote:
>> #define TCP_RTO_MAX ((unsigned)(120*HZ))
>> #define TCP_RTO_MIN ((unsigned)(HZ/5))
>>
>> So we're talking about a [200ms ; 120s] range no matter what.
>
> Why is 200ms a valid lower bound for initRTO? I'm aware of
> measurements that 1s is save for Internet, but I don't know of any
> studies that 200ms is save...
TCP_RTO_MAX and TCP_RTO_MIN is the lower/upper bound for the RTO in
general, not for the initial RTO. RFC 2988 specify a lower bound of 1
second but all operating system choose a lower one because at the time
where RFC 2988 was written the clock granularity was not that accurate. The
minimum RTO for FreeBSD is even 30ms! Furthermore, analysis had
demonstrated that a minimum RTO of 1 second badly breaks throughput in
environments faster then 33kB with minor packet loss rate (e.g. 1%).
So yes, it CAN be wise to choose other lower/upper bounds. But keep in
mind that we should NOT artificial limit ourself. I can image data center
scenarios where a initial RTO of <1 match perfectly.
Hagen
--
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