From: Andi Kleen <ak@muc.de>
To: Mika Liljeberg <Mika.Liljeberg@welho.com>
Cc: Andi Kleen <ak@muc.de>, "David S. Miller" <davem@redhat.com>,
linux-kernel@vger.kernel.org, kuznet@ms2.inr.ac.ru
Subject: Re: TCP acking too fast
Date: Sun, 14 Oct 2001 18:12:35 +0200 [thread overview]
Message-ID: <20011014181235.63397@colin.muc.de> (raw)
In-Reply-To: <3BC94F3A.7F842182@welho.com> <20011014.020326.18308527.davem@redhat.com> <k2zo6uiney.fsf@zero.aec.at> <20011014.023948.95894368.davem@redhat.com> <20011014133004.34133@colin.muc.de> <3BC97BC5.9F341ACE@welho.com> <20011014160511.53642@colin.muc.de> <3BC9A0AD.598BB4F5@welho.com>
In-Reply-To: <3BC9A0AD.598BB4F5@welho.com>; from Mika Liljeberg on Sun, Oct 14, 2001 at 04:26:53PM +0200
On Sun, Oct 14, 2001 at 04:26:53PM +0200, Mika Liljeberg wrote:
> My solution to this would be to recalculate rcv_mss once per window.
> I.e., start new_rcv_mss from 0, keep increasing it for one window width,
> and then copy it to rcv_mss. No funny heuristics, and it would adjust to
> a shrunken MSS within one transmission window.
Sounds complicated. How would you implement it?
>
> > > > On further
> > > > look the 2.4 tcp_measure_rcv_mss will never update rcv_mss for packets
> > > > which do have PSH set and in this case cause random ack behaviour depending
> > > > on the initial rcv_mss guess.
> > > > Not very nice; definitely violates the "be conservative what you accept"
> > > > rule. I'm not sure how to fix it, adding a fallback to every-two-packet-add
> > > > would pollute the fast path a bit.
> > >
> > > You're right. As far as I can see, it's not necessary to set the
> > > TCP_ACK_PUSHED flag at all (except maybe for SYN-ACK). I'm just writing
> > > a patch to clean this up.
> >
> > Setting it for packets >= rcv_mss looks useful to me to catch mistakes.
> > Better too many acks than to few.
>
> Maybe so, but in that case I would only set it for packets > rcv_mss.
> Otherwise, my ack-every-segment-with-PSH problem would come back.
Yes > rcv_mss. Sorry for the typo.
>
> Actually, I think it would be better to simply to always ack every other
> segment (except in quickack and fast recovery modes) and only use the
> receive window estimation for window updates. This would guarantee
> self-clocking in all cases.
The original "ack after 2*mss" had been carefully tuned to work with well
slow PPP links in all case; after some bad experiences. It came
together with the variable length delayed ack.
The rcv_mss stuff was added later to fix some performance problems
on very big MTU links like HIPPI (where you have a MSS of 64k, but
often stacks send smaller packets like 48k; the ack after 2*mss check
only triggered every third packet, causing bad peroformance)
Now if nobody used slow PPP links anymore it would be probably ok
to go back to the simpler "ack every other packet" rule; but I'm afraid
that's not the case yet.
-Andi
next prev parent reply other threads:[~2001-10-14 16:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-14 0:23 TCP acking too fast Mika Liljeberg
2001-10-14 6:40 ` David S. Miller
2001-10-14 7:05 ` Mika Liljeberg
2001-10-14 7:47 ` David S. Miller
2001-10-14 7:51 ` Mika Liljeberg
2001-10-14 8:12 ` David S. Miller
2001-10-14 8:39 ` Mika Liljeberg
2001-10-14 9:03 ` David S. Miller
2001-10-14 9:15 ` Mika Liljeberg
2001-10-14 9:16 ` David S. Miller
2001-10-14 9:25 ` Andi Kleen
2001-10-14 9:39 ` David S. Miller
2001-10-14 11:30 ` Andi Kleen
2001-10-14 11:49 ` Mika Liljeberg
2001-10-14 14:05 ` Andi Kleen
2001-10-14 14:26 ` Mika Liljeberg
2001-10-14 16:12 ` Andi Kleen [this message]
2001-10-14 16:55 ` Mika Liljeberg
2001-10-14 17:07 ` kuznet
2001-10-14 17:26 ` Mika Liljeberg
2001-10-14 17:35 ` kuznet
2001-10-14 17:56 ` Mika Liljeberg
2001-10-14 18:20 ` kuznet
2001-10-14 18:48 ` Mika Liljeberg
2001-10-14 19:12 ` kuznet
2001-10-14 19:32 ` Mika Liljeberg
2001-10-14 19:40 ` kuznet
2001-10-14 20:06 ` Mika Liljeberg
2001-10-15 18:40 ` kuznet
2001-10-15 19:15 ` Mika Liljeberg
2001-10-15 19:38 ` Mika Liljeberg
2001-10-14 13:14 ` [PATCH] " Mika Liljeberg
2001-10-14 16:36 ` kuznet
2001-10-14 7:50 ` David S. Miller
2001-10-14 7:53 ` Mika Liljeberg
2001-10-15 20:59 ` Bill Davidsen
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=20011014181235.63397@colin.muc.de \
--to=ak@muc.de \
--cc=Mika.Liljeberg@welho.com \
--cc=davem@redhat.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@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