Re: R: Kernel bug handling TCP_RTO_MAX?

[Andrew McGregor <andrew@indranet.co.nz>]

--On Friday, December 13, 2002 13:33:16 +0100 Bogdan Costescu 
<bogdan.costescu@iwr.uni-heidelberg.de> 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 
OK.

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 :-)

Andrew