- Test - lists.nanog.org

None
by None 12 Jul '07

12 Jul '07

) by chopin.merit.edu (MOS 3.8.2-GA) with SMTP id AFJ75544; Thu, 12 Jul 2007 15:43:44 -0400 (EDT) X-VirusChecked: Checked X-Env-Sender: jloiacon(a)csc.com X-Msg-Ref: server-12.tower-171.messagelabs.com!1184269421!7290336!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 25947 invoked from network); 12 Jul 2007 19:43:42 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-12.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 12 Jul 2007 19:43:42 -0000 Received: from amer-gw07.amer.csc.com (amer-gw07.amer.csc.com [20.6.39.243]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l6CJhtpO 001246; Thu, 12 Jul 2007 15:43:56 -0400 (EDT) In-Reply-To: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> To: Philip Lavine <source_route(a)yahoo.com> Cc: nanog <nanog(a)merit.edu>, owner-nanog(a)merit.edu Subject: Re: TCP congestion MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: Joe Loiacono <jloiacon(a)csc.com> Message-ID: <OF24F6577F.3CB4C2F7-ON85257316.006BDA71-85257316.006C55D3(a)csc.com> Date: Thu, 12 Jul 2007 15:43:26 -0400 X-MIMETrack: Serialize by Router on AMER-GW07/SRV/CSC(Release 7.0.2FP1 HF180|Mar ch 29, 2007) at 07/12/2007 03:42:47 PM, Serialize complete at 07/12/2007 03:42:47 PM Content-Type: multipart/alternative; boundary="=_alternative 006C1B0785257316_=" Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A09020B.46968652.005A: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 X-Status: X-Keywords: NonJunk X-UID: 16 This is a multipart message in MIME format. --=_alternative 006C1B0785257316_= Content-Type: text/plain; charset="US-ASCII" owner-nanog(a)merit.edu wrote on 07/12/2007 02:07:00 PM: > 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). Perhaps you're filling buffers by flowing from a 1Gbps link into a 9Mbps circuit. Dropped packets induces slow-start/congestion avoidance. Joe --=_alternative 006C1B0785257316_= Content-Type: text/html; charset="US-ASCII" <tt>owner-nanog(a)merit.edu wrote on 07/12/2007 02:07:00 PM: > 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). </tt> <tt>Perhaps you're filling buffers by flowing from a 1Gbps link into a 9Mbps circuit. Dropped packets induces slow-start/congestion avoidance.</tt> <tt>Joe</tt> --=_alternative 006C1B0785257316_=--

1 0

None
by None 12 Jul '07

12 Jul '07

id BC1804DF47; Thu, 12 Jul 2007 15:41:53 -0400 (EDT) Delivered-To: nanog(a)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 IfD9rZGYV1iq for <nanog(a)trapdoor.merit.edu>; Thu, 12 Jul 2007 15:41:48 -0400 (EDT) Received: from mozart.merit.edu (mozart.merit.edu [198.108.95.9]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AE6B4DF47 for <nanog(a)trapdoor.merit.edu>; Thu, 12 Jul 2007 15:41:48 -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 AJW76100; Thu, 12 Jul 2007 15:43:26 -0400 (EDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by bach.merit.edu (MOS 3.8.2-GA) with ESMTP id ADV37928; Thu, 12 Jul 2007 15:43:25 -0400 (EDT) Received: from E03MVC4-UKBR.domain1.systemhost.net ([193.113.197.115]) by smtp4. smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 20:43:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP congestion Date: Thu, 12 Jul 2007 20:44:57 +0100 Message-ID: <D03E4899F2FB3D4C8464E8C76B3B68B0AF5947(a)E03MVC4-UKBR.domain1.systemh ost.net> In-Reply-To: <14272.1184268577(a)turing-police.cc.vt.edu> Thread-Topic: TCP congestion Thread-Index: AcfEu/7UMKRMPcbGSWycnzy61l7YvwAANReA References: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> <14272.1184268577@turin g-police.cc.vt.edu> From: <michael.dillon(a)bt.com> To: <nanog(a)merit.edu> X-OriginalArrivalTime: 12 Jul 2007 19:43:24.0605 (UTC) FILETIME=[E90AE6D0:01C7C4 BC] Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.469684F2.0150: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 X-Status: X-Keywords: NonJunk X-UID: 15 > Who knows, maybe a few packets got corrupted on the wire, and=20 > the TCP chucksum actually caught it and dropped the offending packets. Or there could be flags in the bitstream... --Michael Dillon

1 0

None
by None 12 Jul '07

12 Jul '07

) by chopin.merit.edu (MOS 3.8.2-GA) with ESMTP id AFJ74342; Thu, 12 Jul 2007 15:29:37 -0400 (EDT) Received: from turing-police.cc.vt.edu (turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.14.1/8.14.1) with ESMTP id l6CJTbg9014274; Thu, 12 Jul 2007 15:29:37 -0400 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Philip Lavine <source_route(a)yahoo.com> Cc: nanog <nanog(a)merit.edu> Subject: Re: TCP congestion In-Reply-To: Your message of "Thu, 12 Jul 2007 11:07:00 PDT." <30366.27320.qm(a)web30805.mail.mud.yahoo.com> From: Valdis.Kletnieks(a)vt.edu References: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1184268577_3357P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 12 Jul 2007 15:29:37 -0400 Message-ID: <14272.1184268577(a)turing-police.cc.vt.edu> Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.4696825D.009C: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 X-Status: X-Keywords: NonJunk X-UID: 14 --==_Exmh_1184268577_3357P Content-Type: text/plain; charset=us-ascii On Thu, 12 Jul 2007 11:07:00 PDT, Philip Lavine said: > 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). Just because there wasn't any congestion reason that *you* could see where you hat your instrumentation doesn't mean there's 100% congestion free end-to-end. (Feel free to hit delete if you actually *do* have instrumentation looking both directions on every segment involved). Who knows, maybe a few packets got corrupted on the wire, and the TCP chucksum actually caught it and dropped the offending packets. --==_Exmh_1184268577_3357P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFGloEhcC3lWbTT17ARAhJ+AJ9hZzBts0geN/HQQyrtVpHB9rHaBwCg5aQA O5kDiauP3dxbe3i+qXsnf+0= =cOY3 -----END PGP SIGNATURE----- --==_Exmh_1184268577_3357P--

1 0

Re: TCP congestion
by Jared Mauch 12 Jul '07

12 Jul '07

nether.net [204.42.254.5]); Thu, 12 Jul 2007 15:18:21 -0400 (EDT) Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.46967FCA.0145: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 X-Status: X-Keywords: NonJunk X-UID: 13 On Thu, Jul 12, 2007 at 11:07:00AM -0700, Philip Lavine wrote: > > Can someone explain how a TCP conversation could degenerate into congestion av oidance on a long fat pipe if there is no packet/segment loss or out of order se gments? > > Here is the situation: > WAN = 9 Mbps ATM connection between NY and LA (70 ms delay) Do you know there is no cell loss on your ATM path? Have you also accounted for SAR overhead? Do you know if they use any sort of cell-chaining technology in their network to reduce overhead? - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

1 0

None
by None 12 Jul '07

12 Jul '07

201.139]) by chopin.merit.edu (MOS 3.8.2-GA) with SMTP id AFJ72255; Thu, 12 Jul 2007 15:02:50 -0400 (EDT) Received: (qmail 35638 invoked by uid 60001); 12 Jul 2007 19:02:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type :Message-ID; b=o8K5L4iQddCaql75FT6+jzTiP46Zb6DufoYvftGz9PmfT+o9A7nJkLNyq6u81Cf23w5Sw0SkjZGj tGXQdRsOtQC2Y7cs5Ml2950Qi2x1h1dao1zXd9Dphq99tgcr79lcD47iRMe/w3VztWIzzy/K3WT+Sd67 eIynBxVW0vkPMK4=; X-YMail-OSG: 9GDop5wVM1mzt3l.pjl2xteBLdwWeTGeyd4kQnWuWPiIxhpKgGQRUvTs7c2QKBlWNQ- - Received: from [64.60.42.95] by web30813.mail.mud.yahoo.com via HTTP; Thu, 12 Ju l 2007 12:02:49 PDT X-Mailer: YahooMailRC/651.41 YahooMailWebService/0.7.41.16 Date: Thu, 12 Jul 2007 12:02:49 -0700 (PDT) From: Philip Lavine <source_route(a)yahoo.com> Subject: Re: TCP congestion To: nanog <nanog(a)merit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Message-ID: <352820.35037.qm(a)web30813.mail.mud.yahoo.com> Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.46967C94.0032: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 X-Status: X-Keywords: NonJunk X-UID: 12 Even if the segment was received out of order what would cause congestion avoida nce to starve the connection of legitimate traffic for 15 to 20 seconds? That is the core of the problem. ----- Original Message ---- From: Fred Baker <fred(a)cisco.com> To: Brian Knoll <Brian.Knoll(a)tradingtechnologies.com> Cc: Philip Lavine <source_route(a)yahoo.com>; nanog <nanog(a)merit.edu> Sent: Thursday, July 12, 2007 11:56:06 AM Subject: Re: TCP congestion On Jul 12, 2007, at 11:42 AM, Brian Knoll ((TTNET)) wrote: > 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. or received it out of order. Yes, a tcpdump trace is the first step. ________________________________________________________________________________ ____ Be a better Globetrotter. Get better travel answers from someone who knows. Yaho o! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469

1 0

None
by None 12 Jul '07

12 Jul '07

2]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2007 11:56:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJYWlkasE2C2/2dsb2JhbAAN X-IronPort-AV: i="4.16,533,1175497200"; d="scan'208"; a="181120603:sNHT26384400" Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l6CHbNqX018189; Thu, 12 Jul 2007 10:37:23 -0700 In-Reply-To: <D4C8D8B144E6DE49AA3FC67557D58733061F4021@chiex01> References: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> <D4C8D8B144E6DE49AA3FC6 7557D58733061F4021@chiex01> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2489B0CD-DE00-4B83-B022-64BC712211A5(a)cisco.com> Cc: "Philip Lavine" <source_route(a)yahoo.com>, "nanog" <nanog(a)merit.edu> Content-Transfer-Encoding: 7bit From: Fred Baker <fred(a)cisco.com> Subject: Re: TCP congestion Date: Thu, 12 Jul 2007 11:56:06 -0700 To: Brian Knoll ((TTNET)) <Brian.Knoll(a)tradingtechnologies.com> X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=296; t=1184261844; x=118512584 4; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred(a)cisco.com; z=From:=20Fred=20Baker=20<fred(a)cisco.com> |Subject:=20Re=3A=20TCP=20congestion |Sender:=20 |To:=20Brian=20Knoll=20((TTNET))=20<Brian.Knoll(a)tradingtechnologies.com> ; bh=Pohlr/rNmMxAhoJs+K2wAiToqVyWS+FjsBWElnExR3E=; b=nt3EZEh7OBzi2XtXJmkhVZW3GUBjE8OeTDfYTnjF8Z0MxrgTlsRVmG5TlFgps9+3ul9RqQ TM 9Dbt1L797HdgithMACz8q8PxeI7IYBtQ+yW1Q0RUMEe4PVHiH0DHf5re; Authentication-Results: imail.cisco.com; header.From=fred(a)cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.469679C6.0052: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 X-Status: X-Keywords: NonJunk X-UID: 11 On Jul 12, 2007, at 11:42 AM, Brian Knoll ((TTNET)) wrote: > 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. or received it out of order. Yes, a tcpdump trace is the first step.

1 0

None
by None 12 Jul '07

12 Jul '07

m [65.199.113.8]) by bach.merit.edu (MOS 3.8.2-GA) with SMTP id ADV35111; Thu, 12 Jul 2007 14:42:17 -0400 (EDT) Received: from chiex01.int.tt.local ([172.17.250.113]) by chigtw01.tradingtechnologies.com (SMSSMTP 4.1.11.41) with SMTP id M200707121 3421723990 ; Thu, 12 Jul 2007 13:42:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP congestion Date: Thu, 12 Jul 2007 13:42:05 -0500 Message-ID: <D4C8D8B144E6DE49AA3FC67557D58733061F4021@chiex01> In-Reply-To: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> Thread-Topic: TCP congestion Thread-Index: AcfEsRLuJSOqGHS0SfyYW+IzLHamswAAlz9w References: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> From: "Brian Knoll \(TTNET\)" <Brian.Knoll(a)tradingtechnologies.com> To: "Philip Lavine" <source_route(a)yahoo.com>, "nanog" <nanog(a)merit.edu> Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.46967698.00D0: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 X-Status: X-Keywords: X-UID: 10 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? =20 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(a)merit.edu [mailto:owner-nanog@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?=20 Here is the situation: WAN =3D 9 Mbps ATM connection between NY and LA (70 ms delay) LAN =3D Gig Ethernet Receiver: LA server =3D Win2k3 Sender: NY server =3D Linux 2.4 Data transmission typical =3D bursty but never more that 50% of CIR Segment sizes =3D 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.=20 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 =20 ________________________________________________________________________ ____________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.=20 http://mobile.yahoo.com/go?refer=3D1GNXIC

1 0

None
by None 12 Jul '07

12 Jul '07

200.148]) by bach.merit.edu (MOS 3.8.2-GA) with SMTP id ADV33856; Thu, 12 Jul 2007 14:07:01 -0400 (EDT) Received: (qmail 28554 invoked by uid 60001); 12 Jul 2007 18:07:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type :Message-ID; b=APuO41mtUbbv7Tfogdu7M7Z+ddiGtGCzKxiCJpWXvwO7XmN2CAFEFw9HSb7LorrPXWZkNoKIp49h 8jzFCYl3gGq9gef8gW7q/ZLJlGT+MEg1L9rL2fbG6s2JrbB4PVse1gWDo6dimLY52iPHY0RZZe4tlc/D bqdScd/ltAG7MuA=; X-YMail-OSG: XhdJocUVM1mgMpKg.9cbhPFlvScQTvyLyESLUUlffJD4ymKreho8lQ9MTJLw9KYPZA- - Received: from [64.60.42.95] by web30805.mail.mud.yahoo.com via HTTP; Thu, 12 Ju l 2007 11:07:01 PDT X-Mailer: YahooMailRC/651.41 YahooMailWebService/0.7.41.16 Date: Thu, 12 Jul 2007 11:07:00 -0700 (PDT) From: Philip Lavine <source_route(a)yahoo.com> Subject: TCP congestion To: nanog <nanog(a)merit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Message-ID: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.46966E45.006D: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 X-Status: X-Keywords: X-UID: 8 Can someone explain how a TCP conversation could degenerate into congestion avoi dance on a long fat pipe if there is no packet/segment loss or out of order segm ents? 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 M bps, 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 congesti on avoidence. What is strange is there is nothing prior to the drop off that wou ld 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 Ret ransmits. 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

1 0

RE: Level(3) faux paux
by David Hubbard 12 Jul '07

12 Jul '07

From: Valdis.Kletnieks(a)vt.edu > > Or maybe past experience has shown that the two have the same > *actual* failure rate, but asking for a Level3 help is more > likely to actually get you a clueful *and* helpful engineer. This has been my experience when we've had issues with any of the five companies we purchase from; Level 3 has consistently been able to put someone on the phone that actually knows how to resolve problems without even needing to call me back; most of the others we turn our link off because I know it's going to be several hours. David

1 0

None
by None 12 Jul '07

12 Jul '07

) by bach.merit.edu (MOS 3.8.2-GA) with ESMTP id ADV30699; Thu, 12 Jul 2007 11:53:05 -0400 (EDT) Received: from turing-police.cc.vt.edu (turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.14.1/8.14.1) with ESMTP id l6CFr3ui002870; Thu, 12 Jul 2007 11:53:03 -0400 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Security Admin (NetSec)" <secadmin(a)netsecdesign.com> Cc: "nanog(a)merit.edu" <nanog(a)merit.edu> Subject: Re: Level(3) faux paux In-Reply-To: Your message of "Wed, 11 Jul 2007 22:56:32 PDT." <8D870AB38C30EC4C848A11A3F83D20D8060A3EF41A(a)exchange2007.mmicmanhom enet.local> From: Valdis.Kletnieks(a)vt.edu References: <8D870AB38C30EC4C848A11A3F83D20D8060A3EF41A(a)exchange2007.mmicmanhome net.local> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1184255583_3357P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 12 Jul 2007 11:53:03 -0400 Message-ID: <2869.1184255583(a)turing-police.cc.vt.edu> Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.46964ED9.0113: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 X-Status: X-Keywords: X-UID: 2 --==_Exmh_1184255583_3357P Content-Type: text/plain; charset=us-ascii On Wed, 11 Jul 2007 22:56:32 PDT, "Security Admin (NetSec)" said: > Am unsure whether or not this is a mis-statement, but based on NANOG posts, > Level(3) [AS3356] seems to show up mor=e often with issues than say Sprint > [AS1239]. How many places does AS3356 connect with other AS's, and how many places does AS1239 connec with other stuff? I'd expects an AS with 500 interchange points would have 25% more whoopsies than one with 400 interchanges even if they were otherwise equivalent. Another factor would be number of miles of fiber their net is run over - If backhoes per mile is a constant, a 3,000 mile link is more likely to be hit than one half as long, and so on. Or maybe Level3's network is more openly visible from outside, so it's easier to tell that they are the source of a problem than a net that's not easily debugged from outside the AS (leaving you wondering if it's them or somebody on the other side of them). Or maybe past experience has shown that the two have the same *actual* failure rate, but asking for a Level3 help is more likely to actually get you a clueful *and* helpful engineer. Plus, I don't think *any* provider gets mentioned enough on NANOG to be able to draw any realistic statistical inferences. The short-form highly inaccurate handwave is that you'd need *two* providers and at least 20-30 datapoints on *each* to draw conclusions - which would probably take you 2-3 years to collect, and at that point, changing management policies at both providers will render your results inaccurate (you'd be comparing 3-year old data to current). --==_Exmh_1184255583_3357P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFGlk5fcC3lWbTT17ARAmk/AKCZXnSlaByL67fgcrcq9UwoxVFPwQCg8Oew rHXmKfeD0Mllu5T/6JqeqMw= =HeQA -----END PGP SIGNATURE----- --==_Exmh_1184255583_3357P--

1 0