From owner-tcp-impl@grc.nasa.gov Sun Apr 20 13:14:57 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09513 for ; Sun, 20 Apr 2003 13:14:57 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 9ADCB6BA59 for ; Sun, 20 Apr 2003 13:17:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3KGv4sK013665 for tcp-impl-outgoing; Sun, 20 Apr 2003 12:57:04 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3KGv3uW013661 for ; Sun, 20 Apr 2003 12:57:03 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3KGv2bp002422 for ; Sun, 20 Apr 2003 12:57:02 -0400 (EDT) Received: from usc.edu (usc.edu [128.125.253.136]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id EA5C9689CF for ; Sun, 20 Apr 2003 12:57:01 -0400 (EDT) Received: from pollux.usc.edu (kunchanl@pollux.usc.edu [128.125.7.29]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA00156 for ; Sun, 20 Apr 2003 09:57:01 -0700 (PDT) Received: from localhost (kunchanl@localhost) by pollux.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA21046 for ; Sun, 20 Apr 2003 09:57:00 -0700 (PDT) Date: Sun, 20 Apr 2003 09:57:00 -0700 (PDT) From: kunchanl To: Subject: timeout value in TCP implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hi, I've observed quiet a few of connections in my tcpdump trace has the SYN packet re-transmitted after about 3 seconds (as the example below). I'm wondering if this 3-second is related some particular timeout value in some tcp implementaton. Can anybody shed me some light? Thanks Kun-chan Lan 1036626828.477241 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0) win 8192 (DF) 1036626831.460768 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0) win 8192 (DF) 1036626831.784822 10.0.0.1.2355 > 192.168.0.2.80: . ack 3335637810 win 8760 (DF) 1036626831.792048 10.0.0.1.2355 > 192.168.0.2.80: P 0:758(758) ack 1 win 8760 (DF) 1036626831.852406 10.0.0.1.2355 > 192.168.0.2.80: . ack 124 win 8638 (DF) 1036626831.852423 10.0.0.1.2355 > 192.168.0.2.80: R 12194065:12194065(0) win 0 (DF) From owner-tcp-impl@grc.nasa.gov Sun Apr 20 13:29:33 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09737 for ; Sun, 20 Apr 2003 13:29:33 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 4E36D6BA67 for ; Sun, 20 Apr 2003 13:31:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3KHIsEq016210 for tcp-impl-outgoing; Sun, 20 Apr 2003 13:18:54 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3KHIruW016206 for ; Sun, 20 Apr 2003 13:18:53 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3KHIqbp005213 for ; Sun, 20 Apr 2003 13:18:52 -0400 (EDT) Received: from usc.edu (usc.edu [128.125.253.136]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E0F316BA02 for ; Sun, 20 Apr 2003 13:18:51 -0400 (EDT) Received: from pollux.usc.edu (kunchanl@pollux.usc.edu [128.125.7.29]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA12198 for ; Sun, 20 Apr 2003 10:18:51 -0700 (PDT) Received: from localhost (kunchanl@localhost) by pollux.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA21352 for ; Sun, 20 Apr 2003 10:18:50 -0700 (PDT) Date: Sun, 20 Apr 2003 10:18:50 -0700 (PDT) From: kunchanl To: Subject: long delay before closing connection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hi, I've observed quiet a few connections in my tcpdump trace where the web server waits for 10-15 seconds to send out FIN packet to close up the connection (in the following example the web server waits for 10 second before sending out the FIN) I'm wondering if this is some kind of bug that ties to some particular web server or tcp implementation? or it is something normal? 1036628283.930394 10.0.0.1.3653 > 192.168.0.2.80: S 3207141408:3207141408(0) win 16384 (DF) 1036628283.931361 192.168.0.2.80 > 10.0.0.1.3653: S 2876574950:2876574950(0) ack 3207141409 win 5840 (DF) 1036628284.024387 10.0.0.1.3653 > 192.168.0.2.80: . ack 1 win 17520 (DF) 1036628284.053898 10.0.0.1.3653 > 192.168.0.2.80: P 1:388(387) ack 1 win 17520 (DF) 1036628284.055470 192.168.0.2.80 > 10.0.0.1.3653: . ack 388 win 6432 (DF) 1036628284.057227 192.168.0.2.80 > 10.0.0.1.3653: P 1:181(180) ack 388 win 6432 (DF) 1036628284.326158 10.0.0.1.3653 > 192.168.0.2.80: . ack 181 win 17340 (DF) 1036628286.367286 10.0.0.1.3653 > 192.168.0.2.80: P 388:678(290) ack 181 win 17340 (DF) 1036628286.370024 192.168.0.2.80 > 10.0.0.1.3653: P 181:512(331) ack 678 win 7504 (DF) 1036628286.577595 10.0.0.1.3653 > 192.168.0.2.80: . ack 512 win 17009 (DF) 1036628297.384645 192.168.0.2.80 > 10.0.0.1.3653: F 512:512(0) ack 678 win 7504(DF) 1036628297.405154 10.0.0.1.3653 > 192.168.0.2.80: . ack 513 win 17009 (DF) 1036628304.498357 10.0.0.1.3653 > 192.168.0.2.80: R 3207142086:3207142086(0) win 0 (DF) Thanks Kun-chan Lan From owner-tcp-impl@grc.nasa.gov Sun Apr 20 14:26:50 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10540 for ; Sun, 20 Apr 2003 14:26:50 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 0794D6BA7D for ; Sun, 20 Apr 2003 14:29:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3KIF5eO022494 for tcp-impl-outgoing; Sun, 20 Apr 2003 14:15:05 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3KIF3uW022490 for ; Sun, 20 Apr 2003 14:15:03 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3KIF2bp011917 for ; Sun, 20 Apr 2003 14:15:03 -0400 (EDT) Received: from usc.edu (usc.edu [128.125.253.136]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 2E4A26BA4C for ; Sun, 20 Apr 2003 14:15:02 -0400 (EDT) Received: from pollux.usc.edu (kunchanl@pollux.usc.edu [128.125.7.29]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA15440; Sun, 20 Apr 2003 11:15:00 -0700 (PDT) Received: from localhost (kunchanl@localhost) by pollux.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA22329; Sun, 20 Apr 2003 11:15:00 -0700 (PDT) Date: Sun, 20 Apr 2003 11:15:00 -0700 (PDT) From: kunchanl To: Bogdan Ghita Cc: "'tcp-impl@lerc.nasa.gov'" Subject: RE: timeout value in TCP implementation In-Reply-To: <3D47C08B02B6E146AA36789FE62BE9207398@jack.see.plym.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Thanks! Bogdan. Another question: I've also observed quite a number of http connections where the client waits for about 60 seconds to send out RST packet like the following example. This 60-second looks like another timeout value to me. Do you have any idea where I might be able to find some pointer for it? Regards, Kun-chan 16:42:11.722789 10.0.0.1.2214 > 192.168.0.2.80: S 53128904:53128904(0) win 65535 (DF) 16:42:11.723963 192.168.0.2.80 > 10.0.0.1.2214: S 695356871:695356871(0) ack 53128905 win 64240 (DF) 16:42:11.948538 10.0.0.1.2214 > 192.168.0.2.80: . ack 1 win 65535 (DF) 16:42:11.976663 10.0.0.1.2214 > 192.168.0.2.80: P 1:361(360) ack 1 win 65535 (DF) 16:42:11.978416 192.168.0.2.80 > 10.0.0.1.2214: P 1:142(141) ack 361 win 63880 (DF) 16:42:12.161741 10.0.0.1.2214 > 192.168.0.2.80: . ack 142 win 65394 (DF) 16:42:14.141897 10.0.0.1.2214 > 192.168.0.2.80: P 361:721(360) ack 142 win 65394 (DF) 16:42:14.143285 192.168.0.2.80 > 10.0.0.1.2214: P 142:283(141) ack 721 win 63520 (DF) 16:42:14.369179 10.0.0.1.2214 > 192.168.0.2.80: . ack 283 win 65253 (DF) 16:43:14.813957 10.0.0.1.2214 > 192.168.0.2.80: R 53129625:53129625(0) win 0 (DF) On Sun, 20 Apr 2003, Bogdan Ghita wrote: > Hello Kun-chan, > > 3 seconds is the recomended initial value for the TCP timeout timer (RTO). > See RFC1122 (section 4.2.3.1) for details. > > Cheers, > Bogdan > > > -----Original Message----- > From: kunchanl > To: tcp-impl@lerc.nasa.gov > Sent: 20/04/03 17:57 > Subject: timeout value in TCP implementation > > Hi, > > I've observed quiet a few of connections in my tcpdump trace > has the SYN packet re-transmitted after about 3 seconds (as > the example below). I'm wondering if this 3-second is related > some particular timeout value in some tcp implementaton. Can > anybody shed me some light? > > Thanks > Kun-chan Lan > > 1036626828.477241 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0) > win 8192 (DF) > 1036626831.460768 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0) > win 8192 (DF) > 1036626831.784822 10.0.0.1.2355 > 192.168.0.2.80: . ack 3335637810 win > 8760 (DF) > 1036626831.792048 10.0.0.1.2355 > 192.168.0.2.80: P 0:758(758) ack 1 win > 8760 (DF) > 1036626831.852406 10.0.0.1.2355 > 192.168.0.2.80: . ack 124 win 8638 > (DF) > 1036626831.852423 10.0.0.1.2355 > 192.168.0.2.80: R 12194065:12194065(0) > win 0 (DF) > > > From owner-tcp-impl@grc.nasa.gov Mon Apr 21 10:27:06 2003 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17932 for ; Mon, 21 Apr 2003 10:27:05 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 80A0668A1E for ; Mon, 21 Apr 2003 10:29:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3LEBoTn009253 for tcp-impl-outgoing; Mon, 21 Apr 2003 10:11:50 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3LEBnuW009241 for ; Mon, 21 Apr 2003 10:11:49 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA89438; Mon, 21 Apr 2003 10:11:48 -0400 (EDT) Message-Id: <200304211411.KAA89438@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: bodhi@jack.see.plymouth.ac.uk Subject: RE: timeout value in TCP implementation Organization: BBN Technologies/NASA GRC Song-of-the-Day: Outshine Date: Mon, 21 Apr 2003 10:11:48 -0400 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message From: Bogdan Ghita To: "'kunchanl '" Cc: "'tcp-impl@lerc.nasa.gov'" Subject: RE: timeout value in TCP implementation Date: Sun, 20 Apr 2003 18:45:56 +0100 Hello Kun-chan, 3 seconds is the recomended initial value for the TCP timeout timer (RTO). See RFC1122 (section 4.2.3.1) for details. Cheers, Bogdan - -----Original Message----- From: kunchanl To: tcp-impl@lerc.nasa.gov Sent: 20/04/03 17:57 Subject: timeout value in TCP implementation Hi, I've observed quiet a few of connections in my tcpdump trace has the SYN packet re-transmitted after about 3 seconds (as the example below). I'm wondering if this 3-second is related some particular timeout value in some tcp implementaton. Can anybody shed me some light? Thanks Kun-chan Lan 1036626828.477241 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0) win 8192 (DF) 1036626831.460768 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0) win 8192 (DF) 1036626831.784822 10.0.0.1.2355 > 192.168.0.2.80: . ack 3335637810 win 8760 (DF) 1036626831.792048 10.0.0.1.2355 > 192.168.0.2.80: P 0:758(758) ack 1 win 8760 (DF) 1036626831.852406 10.0.0.1.2355 > 192.168.0.2.80: . ack 124 win 8638 (DF) 1036626831.852423 10.0.0.1.2355 > 192.168.0.2.80: R 12194065:12194065(0) win 0 (DF) ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Apr 30 10:38:20 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06295 for ; Wed, 30 Apr 2003 10:38:19 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D36686BA9B for ; Wed, 30 Apr 2003 10:40:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3UEH2ip013307 for tcp-impl-outgoing; Wed, 30 Apr 2003 10:17:02 -0400 (EDT) Received: from lawyers.ir.bbn.com (lawyers.grc.nasa.gov [139.88.87.34]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UEH0uW013283 for ; Wed, 30 Apr 2003 10:17:00 -0400 (EDT) Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id B7DC46B2B9; Wed, 30 Apr 2003 09:34:12 -0400 (EDT) To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: Thomas Hou Subject: INFOCOM 2004 Call for Papers Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Wed, 30 Apr 2003 09:34:12 -0400 Message-Id: <20030430133412.B7DC46B2B9@lawyers.ir.bbn.com> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Call For Papers - Infocom 2004 - -------------------------------------------- IEEE INFOCOM 2004 The Conference on Computer Communications March 7 - 11, 2004, Hong Kong The Twenty-third Annual Joint Conference of the IEEE Computer and Communications Societies http://www.ieee-infocom.org/2004 Topics of Interest: - -------------------------- Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: - - Ad hoc & sensor networks - Performance evaluation - - Addressing & location management - Power control - - Capacity planning - Pricing & billing - - Cellular networks - Quality of service - - Congestion control - Resource allocation - - Content distribution - Routing - - Multicast - Scheduling & buffer management - - Multimedia protocols - Security & privacy - - Network applications & services - Service overlay networks - - Network architectures - Switches and switching - - Network control by pricing - Topology inference - - Network design & planning - Traffic analysis & control - - Network management - Traffic engineering - - Optical networks - Web performance - - Peer-to-peer communications - Wireless LANs Executive Committee - ------------------------------- General Chair: Victor O.K. Li, The University of Hong Kong Technical Program Co-Chairs: Marwan Krunz, University of Arizona Bo Li, Hong Kong University of Science and Technology International Vice Chairs: Jin-Fu Chang, National Chi-Nan University, Taiwan Jim Kurose, University of Massachusetts Amherst Lemin Li , University of Electronic Science and Technology of China Hiromi Okada , Kansai University, Japan Harry Rudin , IBM Research, Switzerland Izhak Rubin, UCLA Tutorial Co-Chairs: Wanjiun Liao, National Taiwan University, Taiwan Krishna M. Sivalingam, University of Maryland Baltimore County. Panel Co-Chairs: Kin Leung, Lucent Bell Labs Nicholas F. Maxemchuk, Columbia University. Keynote Speaker Chair: David Lee, Lucent Bell Labs, USA. Local Arrangement Co-Chairs: Paul Kwok, Open University of Hong Kong Jian-Liang Xu, Hong Kong Baptist University Finance Co-Chairs: Bruce Worthman, IEEE Comm Society Lawrence Yeung, The University of Hong Kong Publicity Co-Chairs: Mohsen Guizani, Western Michigan University Y. Thomas Hou , Virginia Tech Publication Co-Chairs: Steven Low, Caltech, USA. Zhengzhen Zhang, Waterridge Networks Internet Chair: Hui Zhang, Turin Networks Information Systems Co-Chairs: Jack Lee, The Chinese University of Hong Kong Jiangchuan Liu, Hong Kong University of Science and Technology Corporate Patrons Chair: Hailson Yu, Versitech Ltd., Hong Kong Standing Committee Officers: Harvey A. Freeman, HeatSeekers Technology Partners Mark Karol, Avaya, Inc. Kazem Sohraby, Lucent Technolgies Important Dates: - ------------------------ Full paper due: July 1, 2003 Notification of acceptance: October 30, 2003 Final version due: December 19, 2003 For information on paper submission instructions, please check http://www.ieee-infocom.org/2004 ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Apr 30 11:14:56 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08353 for ; Wed, 30 Apr 2003 11:14:55 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 0B7A36BAB5 for ; Wed, 30 Apr 2003 11:17:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3UF3lxO001969 for tcp-impl-outgoing; Wed, 30 Apr 2003 11:03:47 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UF3juW001951 for ; Wed, 30 Apr 2003 11:03:45 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UF3ibp007487 for ; Wed, 30 Apr 2003 11:03:44 -0400 (EDT) Received: from usc.edu (usc.edu [128.125.253.136]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 90048689C9 for ; Wed, 30 Apr 2003 11:03:43 -0400 (EDT) Received: from pollux.usc.edu (kunchanl@pollux.usc.edu [128.125.7.29]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA03803; Wed, 30 Apr 2003 08:03:42 -0700 (PDT) Received: from localhost (kunchanl@localhost) by pollux.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id IAA05915; Wed, 30 Apr 2003 08:03:42 -0700 (PDT) Date: Wed, 30 Apr 2003 08:03:41 -0700 (PDT) From: kunchanl To: Cc: Subject: gaps in a tcp flow In-Reply-To: <3D47C08B02B6E146AA36789FE62BE9207398@jack.see.plym.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Hi all, I've observed quite a few number of flows in my tcpdump trace where there are always some big gaps (~70ms in the example below) when the client sends back ACK to sever during initiation and close of the connection. Does anybody know what aspect of TCP (or HTTP) protocol does this? Or is this just due to some particular implementation? Thanks Kun-chan Lan 26403.250993 10.0.0.1.10098 > 10.0.0.2.80: S 727890358:727890358(0) win 65535 26403.253333 10.0.0.2.80 > 10.0.0.1.10098: S 574667003:574667003(0) ack 727890359 win 5792 26403.325641 10.0.0.1.10098 > 10.0.0.2.80: . ack 1 win 65535 <---- 26403.325866 10.0.0.1.10098 > 10.0.0.2.80: P 1:358(357) ack 1 win 65535 26403.328784 10.0.0.2.80 > 10.0.0.1.10098: . ack 358 win 6432 26403.336044 10.0.0.2.80 > 10.0.0.1.10098: . 1:1449(1448) ack 358 win 6432 26403.337361 10.0.0.2.80 > 10.0.0.1.10098: . 1449:2897(1448) ack 358 win 6432 26403.337367 10.0.0.2.80 > 10.0.0.1.10098: FP 2897:3174(277) ack 358 win 6432 26403.412212 10.0.0.1.10098 > 10.0.0.2.80: . ack 2897 win 64252 <---- 26403.412254 10.0.0.1.10098 > 10.0.0.2.80: F 358:358(0) ack 3175 win 65535 26403.415175 10.0.0.2.80 > 10.0.0.1.10098: . ack 359 win 6432 From owner-tcp-impl@grc.nasa.gov Wed Apr 30 14:26:24 2003 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15993 for ; Wed, 30 Apr 2003 14:26:23 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 5683A68A24 for ; Wed, 30 Apr 2003 14:28:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3UIAFp9028502 for tcp-impl-outgoing; Wed, 30 Apr 2003 14:10:15 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UIADuW028459 for ; Wed, 30 Apr 2003 14:10:13 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UIADbp014653 for ; Wed, 30 Apr 2003 14:10:13 -0400 (EDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 75B71689A6 for ; Wed, 30 Apr 2003 14:10:11 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3UIA6ua029100; Wed, 30 Apr 2003 11:10:06 -0700 (PDT) Received: from cisco.com (dhcp-171-69-119-61.cisco.com [171.69.119.61]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGP82147; Wed, 30 Apr 2003 11:05:41 -0700 (PDT) Message-ID: <3EB01179.BB1F9C7A@cisco.com> Date: Wed, 30 Apr 2003 11:10:01 -0700 From: Murali Bashyam X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kunchanl Cc: tcp-impl@lerc.nasa.gov, klan@usc.edu Subject: Re: gaps in a tcp flow References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit kunchanl wrote: > Hi all, > > I've observed quite a few number of flows in my tcpdump trace > where there are always some big gaps (~70ms in the example below) > when the client sends back ACK to sever during > initiation and close of the connection. > Does anybody know what aspect of TCP (or > HTTP) protocol does this? Or is this just due to some particular > implementation? The ACK for the SYN-ACK should not be delayed at all, and certainly not by 70 ms, there is no aspect of TCP protocol that specifies such a behaviour. So i'd guess that it is either the implementation or the network that's causing this behaviour, although network seems less probable. Murali > > > Thanks > Kun-chan Lan > > 26403.250993 10.0.0.1.10098 > 10.0.0.2.80: S 727890358:727890358(0) win > 65535 > 26403.253333 10.0.0.2.80 > 10.0.0.1.10098: S 574667003:574667003(0) ack > 727890359 win 5792 > 26403.325641 10.0.0.1.10098 > 10.0.0.2.80: . ack 1 win 65535 <---- > 26403.325866 10.0.0.1.10098 > 10.0.0.2.80: P 1:358(357) ack 1 win 65535 > 26403.328784 10.0.0.2.80 > 10.0.0.1.10098: . ack 358 win 6432 > 26403.336044 10.0.0.2.80 > 10.0.0.1.10098: . 1:1449(1448) ack 358 win 6432 > 26403.337361 10.0.0.2.80 > 10.0.0.1.10098: . 1449:2897(1448) ack 358 win > 6432 > 26403.337367 10.0.0.2.80 > 10.0.0.1.10098: FP 2897:3174(277) ack 358 win > 6432 > 26403.412212 10.0.0.1.10098 > 10.0.0.2.80: . ack 2897 win 64252 <---- > 26403.412254 10.0.0.1.10098 > 10.0.0.2.80: F 358:358(0) ack 3175 win 65535 > 26403.415175 10.0.0.2.80 > 10.0.0.1.10098: . ack 359 win 6432 From owner-tcp-impl@grc.nasa.gov Wed Apr 30 14:56:45 2003 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18146 for ; Wed, 30 Apr 2003 14:56:44 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 40C0468A50 for ; Wed, 30 Apr 2003 14:59:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3UIiqwc010005 for tcp-impl-outgoing; Wed, 30 Apr 2003 14:44:52 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UIipuW010001 for ; Wed, 30 Apr 2003 14:44:51 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UIiobp021444 for ; Wed, 30 Apr 2003 14:44:51 -0400 (EDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 00CA2689D3 for ; Wed, 30 Apr 2003 14:44:49 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3UIinuT280174 for ; Wed, 30 Apr 2003 14:44:49 -0400 Received: from d03nm123.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h3UIilo3072856 for ; Wed, 30 Apr 2003 12:44:48 -0600 Subject: Re: gaps in a tcp flow To: tcp-impl@lerc.nasa.gov X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: karen mclane thomas Date: Wed, 30 Apr 2003 14:45:58 -0400 X-MIMETrack: Serialize by Router on D03NM123/03/M/IBM(Release 6.0.1 [IBM]|April 4, 2003) at 04/30/2003 12:44:48 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Immediately remove the email address below from your distribution list. kmt@us.ibm.com kunchanl usc.edu> cc: Sent by: Subject: gaps in a tcp flow owner-tcp-impl@gr c.nasa.gov 04/30/2003 11:03 AM Hi all, I've observed quite a few number of flows in my tcpdump trace where there are always some big gaps (~70ms in the example below) when the client sends back ACK to sever during initiation and close of the connection. Does anybody know what aspect of TCP (or HTTP) protocol does this? Or is this just due to some particular implementation? Thanks Kun-chan Lan 26403.250993 10.0.0.1.10098 > 10.0.0.2.80: S 727890358:727890358(0) win 65535 26403.253333 10.0.0.2.80 > 10.0.0.1.10098: S 574667003:574667003(0) ack 727890359 win 5792 26403.325641 10.0.0.1.10098 > 10.0.0.2.80: . ack 1 win 65535 <---- 26403.325866 10.0.0.1.10098 > 10.0.0.2.80: P 1:358(357) ack 1 win 65535 26403.328784 10.0.0.2.80 > 10.0.0.1.10098: . ack 358 win 6432 26403.336044 10.0.0.2.80 > 10.0.0.1.10098: . 1:1449(1448) ack 358 win 6432 26403.337361 10.0.0.2.80 > 10.0.0.1.10098: . 1449:2897(1448) ack 358 win 6432 26403.337367 10.0.0.2.80 > 10.0.0.1.10098: FP 2897:3174(277) ack 358 win 6432 26403.412212 10.0.0.1.10098 > 10.0.0.2.80: . ack 2897 win 64252 <---- 26403.412254 10.0.0.1.10098 > 10.0.0.2.80: F 358:358(0) ack 3175 win 65535 26403.415175 10.0.0.2.80 > 10.0.0.1.10098: . ack 359 win 6432 From owner-tcp-impl@grc.nasa.gov Wed Apr 30 15:49:24 2003 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22063 for ; Wed, 30 Apr 2003 15:49:23 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1ECE368A73 for ; Wed, 30 Apr 2003 15:51:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3UJa9Sw025857 for tcp-impl-outgoing; Wed, 30 Apr 2003 15:36:09 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UJa8uW025853 for ; Wed, 30 Apr 2003 15:36:08 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA01712; Wed, 30 Apr 2003 15:36:08 -0400 (EDT) Message-Id: <200304301936.PAA01712@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: Rick Jones Subject: Re: gaps in a tcp flow Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Wed, 30 Apr 2003 15:36:08 -0400 Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Wed, 30 Apr 2003 12:04:12 -0700 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP To: tcp-impl@lerc.nasa.gov Subject: Re: gaps in a tcp flow > The ACK for the SYN-ACK should not be delayed at all, and certainly > not by 70 ms, there is no aspect of TCP protocol that specifies such a > behaviour. So i'd guess that it is either the implementation or the > network that's causing this behaviour, although network seems less > probable. It is entirely possible that the ACK of a SYN|ACK could be delayed. Particularly if the implementation is wanting to try to bundle the ACK with the request data. Here is a snippet of a netperf TCP_CRR test between an HP-UX 11 system (tardy) and an HP-UX 11.11 system (sweb156): 13:00:14.077265 tardy.43873 > sweb156.54430: S 217593471:217593471(0) win 32768 (DF) 13:00:14.077399 sweb156.54430 > tardy.43873: S 3147399939:3147399967(28) ack 217593472 win 4096 13:00:14.077583 tardy.43873 > sweb156.54430: P 1:2(1) ack 1 win 32768 (DF) 13:00:14.077806 sweb156.54430 > tardy.43873: P 1:2(1) ack 2 win 4096 13:00:14.077848 sweb156.54430 > tardy.43873: F 2:2(0) ack 2 win 4096 13:00:14.077888 tardy.43873 > sweb156.54430: . ack 3 win 32768 (DF) 13:00:14.077928 tardy.43873 > sweb156.54430: F 2:2(0) ack 3 win 0 (DF) Notice how the initial single byte request is piggy-backed on the ACK of the SYN|ACK from sweb156. If you examine some of IBM's AIX SPECweb99* submittals - for example: http://www.spec.org/osg/web99ssl/results/res2003q1/web99ssl-20030217-00046.html In the client notes you will see a setting that delays the ACK by the client of the SYN|ACK from the server. It does the same thing (HP-UX does not it seems from above :) for the ACK of FINs (at least according to the discussion). rick jones - -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Apr 30 19:12:20 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29103 for ; Wed, 30 Apr 2003 19:12:05 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A317E6BACD for ; Wed, 30 Apr 2003 19:14:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h3UMwfgn008732 for tcp-impl-outgoing; Wed, 30 Apr 2003 18:58:41 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UMwduW008726 for ; Wed, 30 Apr 2003 18:58:39 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h3UMwdbp005755 for ; Wed, 30 Apr 2003 18:58:39 -0400 (EDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 8CCED689D9 for ; Wed, 30 Apr 2003 18:58:38 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3UMwYuc019760; Wed, 30 Apr 2003 15:58:36 -0700 (PDT) Received: from cisco.com (mbashyam-u10.cisco.com [10.34.36.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGQ18159; Wed, 30 Apr 2003 15:54:11 -0700 (PDT) Message-ID: <3EB05519.393FBA5C@cisco.com> Date: Wed, 30 Apr 2003 15:58:33 -0700 From: Murali Bashyam Organization: Cisco Systems Inc X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rick Jones Cc: tcp-impl@grc.nasa.gov Subject: Re: gaps in a tcp flow References: <200304301936.PAA01712@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Mark Allman wrote: Doesn't this cause problems for the initial RTT estimate of the server ? And in the attached example the delay seems to be negligible so it's ok, but if the client is delaying the ACK by 70 ms to piggyback the GET request, it seems like a variant of stretch ack violation. Murali > > > ------- Forwarded Message > > Date: Wed, 30 Apr 2003 12:04:12 -0700 > From: Rick Jones > Reply-To: raj@cup.hp.com > Organization: the Unofficial HP > To: tcp-impl@lerc.nasa.gov > Subject: Re: gaps in a tcp flow > > > The ACK for the SYN-ACK should not be delayed at all, and certainly > > not by 70 ms, there is no aspect of TCP protocol that specifies such a > > behaviour. So i'd guess that it is either the implementation or the > > network that's causing this behaviour, although network seems less > > probable. > > It is entirely possible that the ACK of a SYN|ACK could be delayed. > Particularly if the implementation is wanting to try to bundle the ACK > with the request data. > > Here is a snippet of a netperf TCP_CRR test between an HP-UX 11 system > (tardy) and an HP-UX 11.11 system (sweb156): > > 13:00:14.077265 tardy.43873 > sweb156.54430: S 217593471:217593471(0) > win 32768 (DF) > 13:00:14.077399 sweb156.54430 > tardy.43873: S 3147399939:3147399967(28) > ack 217593472 win 4096 > 13:00:14.077583 tardy.43873 > sweb156.54430: P 1:2(1) ack 1 win 32768 > (DF) > 13:00:14.077806 sweb156.54430 > tardy.43873: P 1:2(1) ack 2 win 4096 > 13:00:14.077848 sweb156.54430 > tardy.43873: F 2:2(0) ack 2 win 4096 > 13:00:14.077888 tardy.43873 > sweb156.54430: . ack 3 win 32768 (DF) > 13:00:14.077928 tardy.43873 > sweb156.54430: F 2:2(0) ack 3 win 0 (DF) > > Notice how the initial single byte request is piggy-backed on the ACK of > the SYN|ACK from sweb156. > > If you examine some of IBM's AIX SPECweb99* submittals - for example: > > http://www.spec.org/osg/web99ssl/results/res2003q1/web99ssl-20030217-00046.html > > In the client notes you will see a setting that delays the ACK by the > client of the SYN|ACK from the server. It does the same thing (HP-UX > does not it seems from above :) for the ACK of FINs (at least according > to the discussion). > > rick jones > - -- > Wisdom Teeth are impacted, people are affected by the effects of events. > these opinions are mine, all mine; HP might not want them anyway... :) > feel free to post, OR email to raj in cup.hp.com but NOT BOTH... > > ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Wed Apr 30 23:27:49 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04093 for ; Wed, 30 Apr 2003 23:27:34 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 1B7E86BAD7 for ; Wed, 30 Apr 2003 23:29:41 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h413EWAH011527 for tcp-impl-outgoing; Wed, 30 Apr 2003 23:14:32 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h413EUuW011520 for ; Wed, 30 Apr 2003 23:14:30 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h413ETbp009939 for ; Wed, 30 Apr 2003 23:14:29 -0400 (EDT) Received: from lawyers.ir.bbn.com (d53-66-209.clv.wideopenwest.com [64.53.209.66]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id DAC33689E8 for ; Wed, 30 Apr 2003 23:14:27 -0400 (EDT) Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id 6F5166B2B7; Wed, 30 Apr 2003 22:59:26 -0400 (EDT) To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: raj@cup.hp.com Subject: Re: gaps in a tcp flow Organization: BBN Technologies/NASA GRC Song-of-the-Day: Dead Flowers Date: Wed, 30 Apr 2003 22:59:26 -0400 Message-Id: <20030501025926.6F5166B2B7@lawyers.ir.bbn.com> Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk ------- Forwarded Message Date: Wed, 30 Apr 2003 16:14:16 -0700 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP To: tcp-impl@grc.nasa.gov Subject: Re: gaps in a tcp flow Murali Bashyam wrote: > > Mark Allman wrote: > > Doesn't this cause problems for the initial RTT estimate of the > server ? And in the attached example the delay seems to be negligible > so it's ok, but if the client is delaying the ACK by 70 ms to > piggyback the GET request, it seems like a variant of stretch ack > violation. I'll make the embarassing statement that I'm not familiar with "stretch ack violation" and so a reference would be really nice. Apart from that, it doesn't seem all that evil if the initial RTT is a bit longer than it might be later. If anything that would seem to be "conservative" in the sense that it leads to a longer RTO and so less likely to have a spurrious RTO. On top of that, most stacks start with an intial RTO for the SYN or the SYN|ACK of something much larger than the standalone ACK timer anyway. rick - -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... ------- End of Forwarded Message