From: Andrew McGregor <andrew@indranet.co.nz>
To: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>,
"David S. Miller" <davem@redhat.com>
Cc: dlstevens@us.ibm.com, matti.aarnio@zmailer.org, niv@us.ibm.com,
alan@lxorguk.ukuu.org.uk, stefano.andreani.ap@h3g.it,
linux-kernel@vger.kernel.org, linux-net@vger.kernel.org
Subject: Re: R: Kernel bug handling TCP_RTO_MAX?
Date: Sat, 14 Dec 2002 00:48:54 +1300 [thread overview]
Message-ID: <19000000.1039780134@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44.0212131233220.11129-100000@kenzo.iwr.uni-heidelberg.de>
You're going to make lots of IETFer's really annoyed by suggesting that :-)
Honestly, there are lots of other ways to solve this, and it would be nice
if the IETF's recent additions got implemented; there are many relevant
things going on there. Those interested should just talk to the draft
authors about implementing things. It's an open organisation just like
linux-kernel after all, just a bit more formal.
In a closed network, why not have SOCK_STREAM map to something faster than
TCP anyway? That is, if I connect(address matching localnet), SOCK_STREAM
maps to (eg) SCTP. That would be a far more dramatic performance hack!
Andrew
--On Friday, December 13, 2002 12:46:15 +0100 Bogdan Costescu
<bogdan.costescu@iwr.uni-heidelberg.de> wrote:
> On Thu, 12 Dec 2002, David S. Miller wrote:
>
>> This is well understood, the problem is that BSD's coarse timers are
>> going to cause all sorts of problems when a Linux stack with a reduced
>> MIN RTO talks to it.
>
> Sorry to jump into the discussion without a good understanding of inner
> workings of TCP, I just want to share my view as a possible user of this:
> one of the messages at the beginning of the thread said that this would
> be useful on a closed network and I think that this point was overlooked.
>
> Think of a closed network with only Linux machines on it (world
> domination, right :-)) like a Beowulf cluster, web frontends talking to
> NFS fileservers, web frontends talking to database backends, etc. Again
> as proposed earlier, border hosts (those connected to both the closed
> network and outside one) could change their communication parameters
> based on device or route and this would become an internal affair that
> would not affect communication with other stacks.
>
> I don't want to suggest to make this the default behaviour; rather, have
> it a parameter that can be changed by the sysadmin and have the current
> value as default.
>
> --
> Bogdan Costescu
>
> IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
> Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
> Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
> E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2002-12-13 11:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-13 6:55 R: Kernel bug handling TCP_RTO_MAX? David Stevens
2002-12-13 6:59 ` David S. Miller
2002-12-13 11:46 ` Bogdan Costescu
2002-12-13 11:48 ` Andrew McGregor [this message]
2002-12-13 12:33 ` Bogdan Costescu
2002-12-13 13:07 ` Andrew McGregor
2002-12-13 18:07 ` Nivedita Singhvi
2002-12-13 22:25 ` Andrew McGregor
2002-12-13 22:58 ` Matti Aarnio
-- strict thread matches above, loose matches on Subject: below --
2002-12-12 20:37 Nivedita Singhvi
2002-12-12 20:18 Andreani Stefano
2002-12-12 20:32 ` David S. Miller
2002-12-12 21:16 ` Alan Cox
2002-12-13 2:26 ` Nivedita Singhvi
2002-12-13 3:39 ` Matti Aarnio
2002-12-13 4:45 ` Nivedita Singhvi
2002-12-13 6:26 ` Nivedita Singhvi
2002-12-13 11:40 ` Andrew McGregor
2002-12-13 5:23 ` David S. 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=19000000.1039780134@localhost.localdomain \
--to=andrew@indranet.co.nz \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bogdan.costescu@iwr.uni-heidelberg.de \
--cc=davem@redhat.com \
--cc=dlstevens@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=matti.aarnio@zmailer.org \
--cc=niv@us.ibm.com \
--cc=stefano.andreani.ap@h3g.it \
/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.