All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: David Miller <davem@davemloft.net>
Cc: kuznet@ms2.inr.ac.ru, alex@sectorb.msk.ru, netdev@vger.kernel.org
Subject: Re: high latency with TCP connections
Date: Thu, 31 Aug 2006 20:23:09 -0700	[thread overview]
Message-ID: <20060831202309.5caefbff@localhost.localdomain> (raw)
In-Reply-To: <20060831.165701.104033558.davem@davemloft.net>

On Thu, 31 Aug 2006 16:57:01 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Date: Fri, 1 Sep 2006 03:29:23 +0400
> 
> > > 2) a way to take delayed ACKs into account for cwnd growth
> > 
> > This part is OK now, right?
> 
> This part of ABC is not on by default, and was broken until last week
> :-)
> 
> Test in tcp_slow_start() used to be:
> 
> 	tp->bytes_acked > 2*tp->mss_cache
> 
> but now it is the correct:
> 
> 	tp->bytes_acked >= 2*tp->mss_cache
> 
> It allows to make two congestion window increases from one ACK, when
> noticing delayed ACK.
> 
> Non-ABC code did not do this, but could figure this kind of thing
> out while scanning retransmit queue.
> 
> > > 1) protection against ACK division
> > 
> > But Linux never had this problem... Congestion window was increased
> > only when a whole skb is ACKed, flag FLAG_DATA_ACKED. (TSO could
> > break this, but should not). Otherwise, this ACK just advanced snd_una
> > and nothing more.
> 
> Ugh, I missed this. :-/
> 
> The TSO code is carefuly to only trim TSO skbs on proper boundaries,
> and this ensures proper setting of FLAG_DATA_ACKED too.  So no
> problems here.
> 
> > The only problem of kind "too-aggressive" with Linux was that we could
> > develop large cwnd sending small segments, and then switch to sending
> > mss-sized segments. It does not look scary, to be honest. :-)
> 
> Agreed.
> 
> > Linux had troubles with slow start even before ABC. Actually,
> > some of applications can suffer of the same syndrome even if ABC disabled.
> > With ABC it becomes TROUBLE, cwnd has no chances to develop at all.
> 
> I've discussed that very issue here before, some time ago, with
> John Heffner.  It was in response to a user reporting a similar
> problem.  The problem is really at the receiver because we only
> ACK every other full sized frame.  I had the idea to ACK every 2
> frames, regardless of size, but that might have other problems.
> 
> There is an assymetry between how we do congestion control on
> sending (packet counting) and our ACK policy on receive (packet
> sized based).
> 
> > Probably, aspect 1 of ABC just should be disabled. And the first my
> > suggestion looks working too.
> 
> I'm ready to rip out ABC entirely, to be honest.  Or at least
> turn it off by default.

Turn it off for 2.6.18, by default then evaluate more for 2.6.19


  reply	other threads:[~2006-09-01  3:24 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 10:07 high latency with TCP connections Alexander Vodomerov
2006-08-30 17:27 ` Stephen Hemminger
2006-08-30 21:39   ` David Miller
2006-08-30 22:04     ` Stephen Hemminger
2006-08-30 23:00     ` Rick Jones
2006-08-31  8:14     ` Alexander Vodomerov
2006-08-31 15:44       ` Sridhar Samudrala
2006-08-31 18:22     ` Kelly Burkhart
2006-08-31 19:40       ` Rick Jones
2006-08-31 21:08       ` Ian McDonald
2006-08-31 21:46   ` Alexey Kuznetsov
2006-08-31 22:14     ` Stephen Hemminger
2006-08-31 22:44       ` David Miller
2006-08-31 23:29         ` Alexey Kuznetsov
2006-08-31 23:57           ` David Miller
2006-09-01  3:23             ` Stephen Hemminger [this message]
2006-09-01  3:39               ` Ian McDonald
2006-09-01  6:23                 ` David Miller
2006-09-01  9:44             ` Pekka Savola
2006-09-01  9:49               ` David Miller
2006-09-01  9:47             ` Alexey Kuznetsov
2006-09-01 11:00               ` Evgeniy Polyakov
     [not found]                 ` <20060901090046.69b3d583@localhost.localdomain>
2006-09-01 20:55                   ` [PATCH] tcp: turn ABC off Stephen Hemminger
2006-09-02  7:22                     ` Evgeniy Polyakov
2006-09-02  8:10                       ` Herbert Xu
2006-09-04  9:10                 ` high latency with TCP connections Alexey Kuznetsov
2006-09-04 16:00 ` [PATCH][RFC] " Alexey Kuznetsov
2006-09-05 17:55   ` Rick Jones
2006-09-05 22:13     ` Alexey Kuznetsov
2006-09-18  7:39     ` David Miller
2006-09-18 17:11       ` Rick Jones
2006-09-18 20:41         ` Alexey Kuznetsov
2006-09-18 21:24           ` Rick Jones
2006-09-18 22:51             ` Alexey Kuznetsov
2006-09-19  0:37               ` Rick Jones
2006-09-22 13:46                 ` Alexey Kuznetsov
2006-09-22 17:15                   ` Rick Jones
2006-09-18  7:31   ` David Miller
2006-09-18 10:37     ` Alexey Kuznetsov
2006-09-18 13:56       ` David Miller
2006-09-20 22:44         ` Stephen Hemminger
2006-09-20 22:47           ` David Miller
2006-09-20 22:55             ` Stephen Hemminger

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=20060831202309.5caefbff@localhost.localdomain \
    --to=shemminger@osdl.org \
    --cc=alex@sectorb.msk.ru \
    --cc=davem@davemloft.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --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.