Date: Tue, 5 Apr 2005 11:26:08 -0700
From: "David S. Miller" <davem@davemloft.net>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org, stable@kernel.org,
       shemminger@osdl.org, netdev@oss.sgi.com
Subject: Re: [07/08] [TCP] Fix BIC congestion avoidance algorithm error
Message-Id: <20050405112608.0b3c07f0.davem@davemloft.net>
In-Reply-To: <20050405182202.GA11979@thunk.org>
References: <20050405164539.GA17299@kroah.com>
	<20050405164758.GH17299@kroah.com>
	<20050405182202.GA11979@thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1256
Lines: 29

On Tue, 5 Apr 2005 14:22:02 -0400
Theodore Ts'o <tytso@mit.edu> wrote:

> If the congestion control alogirthm is "Reno-like", what is
> user-visible impact to users?  There are OS's out there with TCP/IP
> stacks that are still using Reno, aren't there?  

An incorrect implementation of any congestion control algorithm
has ramifications not considered when the congestion control
author verified the design of his algorithm.

This has a large impact on every user on the internet, not just
Linux machines.

Perhaps on a microscopic scale "this" part of the BIC algorithm
was just behaving Reno-like due to the bug, but what implications
does that error have as applied to the other heuristics in BIC?
This is what I'm talking about.  BIC operates in several modes,
one of which is a pseudo binary search mode, and another is a
less aggressive slower increase mode.

Therefore I think fixes to congestion control algorithms which
are enabled by default always should take a high priority in
the stable kernels.
-
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/