From owner-freebsd-net@FreeBSD.ORG  Thu Jan  6 22:06:36 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 490DE16A4CE
	for <freebsd-net@freebsd.org>; Thu,  6 Jan 2005 22:06:36 +0000 (GMT)
Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4B7A943D5A
	for <freebsd-net@freebsd.org>; Thu,  6 Jan 2005 22:06:35 +0000 (GMT)
	(envelope-from knockefreebsd@o2.pl)
Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by poczta.o2.pl (Postfix) with ESMTP id 043B7602B3
	for <freebsd-net@freebsd.org>; Thu,  6 Jan 2005 23:06:34 +0100 (CET)
Message-ID: <004a01c4f43c$521af510$df5561d9@ALFA>
From: "Heinz Knocke" <knockefreebsd@o2.pl>
To: <freebsd-net@freebsd.org>
Date: Thu, 6 Jan 2005 23:03:07 +0100
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Subject: What will do the TCP stack in the described scenario?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: Heinz Knocke <knockefreebsd@o2.pl>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jan 2005 22:06:36 -0000

Hi!

I'm writing here because I'm solving a strange performance problem (
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3420+0+current/freebsd-net )
and wonder is this and OS or aplication side's bottleneck.

Imagine the situation (S /C - TCP sender / client respectively).

S: 0:10
C: ack 10
S: 10:20 (10)
S: 20:30 (10)
S: 30:40 (10)
S: 40:50 (10)
C: ack 30
... <server waits RTO, time passes, cwnd and speed drops>
S: 40:50 (10) - retransmission.

C doesn't send duplicate ACKs to let the S know he don't have
everything yet .. because he doesn't know that 40:50 were ever to be
sent, am I right?
Does it mean that 40:50 was the last from window / allowed by sender's
cwnd?
If he had, lets say, 30:40, 50:60 than he'd send multiple ack 30
segments and start recovery procedure, right?

Is there any way to avoid serious speed drop in this scenario? Can
disabling delayed acks / enabling SACKS on client/ server help??


I'll be very grateful for your comments as usual :))

hk