All of lore.kernel.org
 help / color / mirror / Atom feed
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/
>
>



  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.