Message-ID: <3BC9D1BB.3177FA39@welho.com>
Date: Sun, 14 Oct 2001 20:56:11 +0300
From: Mika Liljeberg <Mika.Liljeberg@welho.com>
MIME-Version: 1.0
To: kuznet@ms2.inr.ac.ru
CC: ak@muc.de, davem@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: TCP acking too fast
In-Reply-To: <200110141735.VAA06277@ms2.inr.ac.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

kuznet@ms2.inr.ac.ru wrote:
> 
> Hello!
> 
> > Well, you should read the preceding messages to understand how we got
> > here.
> 
> I am reading now and until now I did not find why problem of calculating
> rcv_mss raised at all. :-)

I think Andi brought it up. I was actually saying that it probably works
most of the time.

> You nicely understood the reason of the problem and
> it is surely not related to rcv_mss in any way.  :-)
> 
> > When you say "reliably", you should recognize the underlying assumptions
> > as well.
> 
> The assumptions are so conservative, that it is not worth to tell about them.

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

> Heuristics does not predict fall of rcv_mss below 536 when sender
> sets PSH on each frame. And it is pretty evident that such prediction
> is impossible theoretically in this sad case. All that we can do is
> to cry and to hold rcv_mss at 536 and to ack each 4th segment on
> with mtu of 256.

Not really. You could do one of two things: either ack every second
segment and leave rcv estimation only for window calculations, or use an
algorithm like the one I outlined. Either approach would work, I think,
and not produce strech acks.

Regards,

	MikaL
-
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/