netdev.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).