[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46D5EEB6.3020602@hp.com>
Date: Wed, 29 Aug 2007 15:09:58 -0700
From: Rick Jones <rick.jones2@...com>
To: Ian McDonald <ian.mcdonald@...di.co.nz>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] make _minimum_ TCP retransmission timeout configurable
Ian McDonald wrote:
> Hmmm... RFC2988 says:
> (2.4) Whenever RTO is computed, if it is less than 1 second then the
> RTO SHOULD be rounded up to 1 second.
>
> Traditionally, TCP implementations use coarse grain clocks to
> measure the RTT and trigger the RTO, which imposes a large
> minimum value on the RTO. Research suggests that a large
> minimum RTO is needed to keep TCP conservative and avoid
> spurious retransmissions [AP99]. Therefore, this
> specification requires a large minimum RTO as a conservative
> approach, while at the same time acknowledging that at some
> future point, research may show that a smaller minimum RTO is
> acceptable or superior.
>
> I went and had a look and this RFC has not been obsoleted. RFC3390
> also backs this assertion up.
>
> So I'm suspecting that the default should be changed to 1000 to match
> the RFC which would solve this issue. I note that the RFC is a SHOULD
> rather than a MUST. I had a quick look around and not sure why Linux
> overrides the RFC on this one.
If nothing else, 200 ms is a "principle of least surprise" thing since
that is the current value (in MS) for TCP_RTO_MIN.
rick jones
-
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