From: kuznet@ms2.inr.ac.ru
Message-Id: <200110141820.WAA06484@ms2.inr.ac.ru>
Subject: Re: TCP acking too fast
To: Mika.Liljeberg@welho.com (Mika Liljeberg)
Date: Sun, 14 Oct 2001 22:20:24 +0400 (MSK DST)
Cc: ak@muc.de, davem@redhat.com, linux-kernel@vger.kernel.org
In-Reply-To: <3BC9D1BB.3177FA39@welho.com> from "Mika Liljeberg" at Oct 14, 1 08:56:11 pm
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org

Hello!

> The assumption is that the peer is implemented the way you expect and
> that the application doesn't toy with TCP_NODELAY.

Sorry??

It is the most important _exactly_ for TCP_NODELAY, which
generates lots of remnants.


> Not really. You could do one of two things: either ack every second
> segment 

I do not worry about this _at_ _all_. See?
"each other", "each two mss" --- all this is red herring.

I do understand your problem, which is not related to rcv_mss.
When bandwidth in different directions differ more than 20 times,
stretch ACKs are even preferred. Look into tcplw work, using stretch ACKs
is even considered as something normal.

I really commiserate and think that removing "final cut" clause
will help you. But sending ACK on buffer drain at least for short
packets is real demand, which cannot be relaxed.
"final cut" is also better not to remove actually, but the case
when it is required is probabilistically marginal.

Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/