Re: R: Kernel bug handling TCP_RTO_MAX?

From: Andrew McGregor (
Date: Fri Dec 13 2002 - 08:07:24 EST

--On Friday, December 13, 2002 13:33:16 +0100 Bogdan Costescu
<> wrote:

> On Sat, 14 Dec 2002, Andrew McGregor wrote:
>> You're going to make lots of IETFer's really annoyed by suggesting that
>> :-)
> I hope not. That was the reason for allowing it to be tuned and for
> having a default value equal to the existing one.

I know the folks in question :-) Actually, they'd be nice about it, but
say something like:

Well, RFC 2988 says that the present value is too small and should be 1s,
although I take it from other discussion that experiment shows 200ms to be

Instead, RFCs 3042 and 3390 present the IETF's preferred approach that has
actually made it through the process. But there are lots of drafts in
progress, so that isn't the final word, although it is certainly better
than tuning down RTO_MAX.

Now, I have no idea if the kernel presently implements the latter two by
default (and on a quick look I can't find either in the code). If not, it
should. Shouldn't the initial window be a tunable?

>> In a closed network, why not have SOCK_STREAM map to something faster
>> than TCP anyway?
> Sure, just give me a protocol that:
> - is reliable
> - has low latency
> - comes with the standard kernel
> and I'll just use it. But you always get only 2 out ot 3...
> --
> Bogdan Costescu

SCTP is in 2.5 now. Does that not fit the bill? I admit, I don't know
about the reliability, although I guess I'm going to find out as I have
cause to use it shortly. Wearing an IETF hat, I'd like to hear about this,
as I'm on a bit of a practicality crusade there :-)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Dec 15 2002 - 22:00:28 EST