Date: Sat, 8 Jan 2005 12:56:54 +0100 From: "Heinz Knocke" <knockefreebsd@o2.pl> To: "Joshua Blanton" <jblanton@masaka.cs.OhioU.Edu> Cc: freebsd-net@freebsd.org Subject: Re: What will do the TCP stack in the described scenario? Message-ID: <004c01c4f579$2a0d7730$df5561d9@ALFA> References: <004a01c4f43c$521af510$df5561d9@ALFA> <20050107105735.GC29573@jtb.ipx.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004c01c4f579$2a0d7730$df5561d9>