From owner-freebsd-net@FreeBSD.ORG  Sat Jan  8 11:54: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 5E2A716A4CE
	for <freebsd-net@freebsd.org>; Sat,  8 Jan 2005 11:54:36 +0000 (GMT)
Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 40BD143D45
	for <freebsd-net@freebsd.org>; Sat,  8 Jan 2005 11:54: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 B31AD60042;
	Sat,  8 Jan 2005 12:54:33 +0100 (CET)
Message-ID: <004c01c4f579$2a0d7730$df5561d9@ALFA>
From: "Heinz Knocke" <knockefreebsd@o2.pl>
To: "Joshua Blanton" <jblanton@masaka.cs.OhioU.Edu>
References: <004a01c4f43c$521af510$df5561d9@ALFA>
	<20050107105735.GC29573@jtb.ipx.ath.cx>
Date: Sat, 8 Jan 2005 12:56:54 +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
cc: freebsd-net@freebsd.org
Subject: Re: 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: Sat, 08 Jan 2005 11:54:36 -0000

Hi!

I see that I didn't explain everything clearly, and made some mistakes
so let me get through it again :))
You're right about the segment numers, but I use the same packet
numeration as tcpdump, so the last segment of the previous packet and
the first segment of the following one have the same number.

Actually I DO have such situation that client (or I should rather
say - the TCP reciever) doesn't send dupack for the packet loss, so
the server (or rather - the TCP sender) doesn't know anything about
the packet being lost and waits the whole long RTO for retransmission.

I'll give you the exact tcpdump extract to see how it works. The
output is alittle processed to make it clear, 1.445 is the TCP sender,
2.49821 the reciever.

2.542532  1.445 > 2.49821: P 3807194718:3807198814(4096) ack
1971888923 win 32768 <timestamp 8099541 8263475>
2.542541  1.445 > 2.49821: P 3807198814:3807202910(4096) ack
1971888923 win 32768 <timestamp 8099541 8263475>
2.542872  2.49821 > 1.445: . ack 3807194718 win 31744 <timestamp
8263475 8099541>
....
2.635501  2.49821 > 1.445: . ack 3807198814 win 32768 <timestamp
8263485 8099541>
....
....
....
2.956050  1.445 > 2.49821: P 3807198814:3807202910(4096) ack
1971888923 win 32768 <timestamp 8099583 8263485>


As you can see the reciever doesn't ACK segments 3807198814 to
3807202910 which are the last sent by the sender (not like I
previously wrote - packet before the last one). Could you please
explain this behaviour?
I observe this kind of behaviour on many FreeBSD systems using Samba
(newest STABLE and CURRENT sys as well) , performance is very poor
probably because of the dropping cwnd caused by RTO.

hk