TCP congestion

Thu Jul 12 18:42:05 UTC 2007

In order to solve this, you need to see a trace from both sides of the
WAN.  Which side is your trace from?  Can you see the original ACK on
both ends?  

If the receiver is sending a DUP ACK, then the sender either never
received the first ACK or it didn't receive it within the timeframe it
expected.

Brian

-----Original Message-----
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of
Philip Lavine
Sent: Thursday, July 12, 2007 1:07 PM
To: nanog
Subject: TCP congestion

Can someone explain how a TCP conversation could degenerate into
congestion avoidance on a long fat pipe if there is no packet/segment
loss or out of order segments? 

Here is the situation:
WAN = 9 Mbps ATM connection between NY and LA (70 ms delay)
LAN = Gig Ethernet
Receiver: LA server = Win2k3
Sender: NY server = Linux 2.4
Data transmission typical = bursty but never more that 50% of CIR
Segment sizes =  64k to 1460k but mostly less than 100k

Typical Problem Scenario: Data transmission is humming along
consistently at 2 Mbps, all of a sudden transmission rates drop to
nothing then pickup again after 15-20 seconds. Prior to the drop off
(based on packet capture) there is usually a DUP ACK/SACK coming from
the receiver followed by the Retransmits and congestion avoidence. What
is strange is there is nothing prior to the drop off that would be an
impetus for congestion (no high BW utilization or packet loss).

Also is there any known TCP issues between linux 2.4 kernel and windows
2003 SP1? Mainly are there issues regarding the handling of SACK, DUP
ACK's and Fast Retransmits. 

Of course we all know that this is not a application issue since
developers make flawless socket code, but if it is network issue how is
caused?

Philip

________________________________________________________________________
____________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC