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
next prev parent 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).