0 (EDT) X-Virus-Scanned: amavisd-new at merit.edu Received: from trapdoor.merit.edu ([127.0.0.1]) by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JIGC9VZ3GxV for <nanog-outgoing@trapdoor.merit.edu>; Fri, 13 Jul 2007 14:28:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0ADB34DFC2; Fri, 13 Jul 2007 14:27:06 -0400 (EDT) Delivered-To: nanog@trapdoor.merit.edu X-Virus-Scanned: amavisd-new at merit.edu Received: from trapdoor.merit.edu ([127.0.0.1]) by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QmPLIZDrCye for <nanog@trapdoor.merit.edu>; Fri, 13 Jul 2007 14:26:57 -0400 (EDT) Received: from mozart.merit.edu (mozart.merit.edu [198.108.95.9]) by trapdoor.merit.edu (Postfix) with ESMTP id EE43E4DFC5 for <nanog@trapdoor.merit.edu>; Fri, 13 Jul 2007 14:22:38 -0400 (EDT) Received: from bach.merit.edu (razorgate.merit.edu [198.108.95.7]) by mozart.merit.edu (MOS 3.8.2-GA) with ESMTP id AJY25472; Fri, 13 Jul 2007 14:24:17 -0400 (EDT) Received: from chopin.merit.edu (razorgate.merit.edu [198.108.95.8]) by bach.merit.edu (MOS 3.8.2-GA) with ESMTP id ADW05340; Fri, 13 Jul 2007 14:24:16 -0400 (EDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by chopin.merit.edu (MOS 3.8.2-GA) with ESMTP id AFK49711; Fri, 13 Jul 2007 14:24:16 -0400 (EDT) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id l6DIOBLm020621; Fri, 13 Jul 2007 11:24:11 -0700 Received: from [172.29.23.83] (dot.corp.google.com [172.29.23.83]) (authenticated bits=0) by zps77.corp.google.com with ESMTP id l6DINxtd031838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jul 2007 11:24:01 -0700 In-Reply-To: <4696E69E.20104@west.net> References: <30366.27320.qm@web30805.mail.mud.yahoo.com> <4696E69E.20104@west.n et> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <CDC42C7A-A318-48B6-BA55-B73D4675161A@kumari.net> Cc: nanog <nanog@merit.edu> Content-Transfer-Encoding: 7bit From: Warren Kumari <warren@kumari.net> Subject: Re: TCP congestion Date: Fri, 13 Jul 2007 14:23:45 -0400 To: Jay Hennigan <jay@west.net> X-Mailer: Apple Mail (2.752.3) Sender: owner-nanog@merit.edu Precedence: bulk Errors-To: owner-nanog@merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090202.4697C591.0134:SCGAP167720,ss=1,fgs=0, ip=198.108.1.26, so=2006-09-22 03:48:54, dmn=5.3.14/2007-05-31 Status: RO So, when you say "pickup again after 15-20 seconds" do you mean that it takes 15-20 seconds to ramp back up to the original speed or that the line is basically idle for 15-20 seconds before any packets start flowing again? If the latter, I'd suggest that you take a look at the apps some more.. Actually, you might want to try and duplicate the issue with identical machines sitting next to each other and a piece of cable between them... On Jul 12, 2007, at 10:42 PM, Jay Hennigan wrote:

Philip Lavine wrote:

...

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?

Duplex mismatch on an intermediate ethernet segment?

Oooh, I like that one....

-- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV

-- She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade)