Re: types of traffic in tcp congest control

Alan Cox <alan@lxorguk.ukuu.org.uk> Mon, 13 May 2002 23:45 UTC

Subject: Re: types of traffic in tcp congest control
To: jinw@comp.leeds.ac.uk (J Wu)
Date: Tue, 14 May 2002 00:45:28 +0100 (BST)
Cc: touch@ISI.EDU (Joe Touch), liy666@sina.com (=?ISO-8859-1?Q?=B4=F3=C0=EE?=), tcp-impl@lerc.nasa.gov
In-Reply-To: <Pine.LNX.4.33.0205131624560.30118-100000@cslin135.leeds.ac.uk> from "J Wu" at May 13, 2002 04:47:44 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E177PVR-0006cV-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 769
Lines: 16

> Well, if only the mice can still congest the link, which shows that the
> network resources are under severe shortage. The only way to solve under
> this situation is hardware solution. But I think even under this situation

I disagree. You can start by collapsing events together when there is
congestion. The fact that userspace can't easily ask "if I send this will
it go out right about now" is a socket API lack.

> restrict the elephants will also do benefit to alleviate the stage of
> congestion.

The bigger problem with your streaming high datarate connections is capture
effect. That's *very* non trivial to handle without doing expensive things like 
connection tracking, or per ToS queues and praying someone used the ToS bits
(or port based hacks)

Alan