From: Rick Jones <rick.jones2@hp.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
Date: Thu, 30 Aug 2007 18:07:13 -0700 [thread overview]
Message-ID: <46D769C1.8090808@hp.com> (raw)
In-Reply-To: <20070830.173912.79067694.davem@davemloft.net>
David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Thu, 30 Aug 2007 17:09:04 -0700 (PDT)
>
>
>>Enable configuration of the minimum TCP Retransmission Timeout via
>>a new sysctl "tcp_rto_min" to help those who's networks (eg cellular)
>>have quite variable RTTs avoid spurrious RTOs.
>>
>>Signed-off-by: Rick Jones <rick.jones2@hp.com>
>>Signed-off-by: Lamont Jones <lamont@hp.com>
>
>
> Thanks for doing this work Rick.
>
> But as John Heffner and I both mentioned, it's pretty clear we should
> do this as a routing metric. Both for handling realistic scenerios
> where the sysctl doesn't work, and to help prevent misuse (example:
> someone decides that it would be _totally_ _awesome_ for "Carrier
> Grade Linux" to set this to 3 seconds by default in /etc/sysctl.conf
> and crap like that).
If nothing else it was worth the practice :) I'll be happy with either
mechanism, just wasn't sure if the jury was still out on whether making
it a routing metric was really necessary. I can see where it would be
goodness if one had separate paths out of a system, one with the highly
variable RTT and one with non-trivial loss rates, just that thusfar I've
not come across any :) I've only seen one path with high RTT
variability and the other path with trivial loss rates.
Also, not surprisingly, the folks for whom I'm doing this are a triffle
"anxious" so I figured that simplicity was worthwhile. Particularly if
it was going to be the case those folks were going to be asking for
back-ports.
Anyhow, I'll try grubbing around the source code (already doing that to
see about writing a pet tcp cong module) but if pointers to the likely
relevant files were available I could try to help thrash-out the routing
metric version. Like I said the consumers of this are a triffle well,
"anxious" :)
rick
next prev parent reply other threads:[~2007-08-31 1:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-31 0:09 [PATCH] make _minimum_ TCP retransmission timeout configurable take 2 Rick Jones
2007-08-31 0:39 ` David Miller
2007-08-31 1:07 ` Rick Jones [this message]
2007-08-31 4:52 ` John Heffner
2007-08-31 17:19 ` Rick Jones
2007-08-31 5:09 ` David Miller
2007-08-31 18:11 ` Rick Jones
2007-08-31 18:57 ` David Miller
2007-08-31 20:59 ` Rick Jones
2007-08-31 21:38 ` David Miller
2007-08-31 22:20 ` Rick Jones
2007-08-31 22:24 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46D769C1.8090808@hp.com \
--to=rick.jones2@hp.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.