All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: David Miller <davem@davemloft.net>
Cc: ZHOU0022@ntu.edu.sg, baruch@ev-en.org, jmorris@namei.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH] TCP Veno module for kernel 2.6.16.13
Date: Thu, 25 May 2006 13:50:11 -0700	[thread overview]
Message-ID: <20060525135011.470dc3dd@localhost.localdomain> (raw)
In-Reply-To: <20060525.132350.39157903.davem@davemloft.net>

On Thu, 25 May 2006 13:23:50 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: "#ZHOU BIN#" <ZHOU0022@ntu.edu.sg>
> Date: Thu, 25 May 2006 16:30:48 +0800
> 
> > Yes, I agree. Actually the main contribution of TCP Veno is not in
> > this AI phase. No matter the ABC is added or not, TCP Veno can
> > always improve the performance over wireless networks, according to
> > our tests.
> 
> It seems to me that the wireless issue is seperate from congestion
> control.
> 
> The key is to identify "true loss" due to overflow of intermediate
> router queues, vs. "false loss" which is due to temporary radio
> signal interference.

Is it really possible to tell the two apart.  Also, a lot of times when
an access point is overloaded, performance is killed because of congestion
overload. 

> This determination is a job for the loss detection in the generic ACK
> processing code in tcp_input.c, not for a congestion control algorithm.
> The congestion control algorithm uses the "true loss" information to
> make congestion control decisions.
> 
> We already have code that tries to make this differentiation, in the
> form of FRTO, and your techniques can likely be placed there as well.

The general idea of resetting cwnd to an estimate of capacity seems to
be a general feature of Westwood, Veno, Compound and Africa. Also FreeBSD
does the same thing, but they don't have a cool name.

  reply	other threads:[~2006-05-25 20:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-25  8:30 [PATCH] TCP Veno module for kernel 2.6.16.13 #ZHOU BIN#
2006-05-25 20:23 ` David Miller
2006-05-25 20:50   ` Stephen Hemminger [this message]
2006-05-25 21:08     ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2006-05-29  3:26 #ZHOU BIN#
2006-05-26  6:32 Fu Cheng Peng, Franklin
2006-05-25 21:11 Caitlin Bestler
2006-05-25 21:59 ` David Miller
2006-05-24 11:08 #ZHOU BIN#
2006-05-24 15:04 ` Stephen Hemminger
2006-05-24 15:20   ` James Morris
2006-05-24 16:16 ` Baruch Even
2006-05-24 16:46   ` Stephen Hemminger
2006-05-28 22:22 ` Thomas Kho

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=20060525135011.470dc3dd@localhost.localdomain \
    --to=shemminger@osdl.org \
    --cc=ZHOU0022@ntu.edu.sg \
    --cc=baruch@ev-en.org \
    --cc=davem@davemloft.net \
    --cc=jmorris@namei.org \
    --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.