From owner-tcp-impl@lerc.nasa.gov Sat May 15 03:34:48 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25550 for ; Sat, 15 May 1999 03:34:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA28081 for tcp-impl-outgoing; Sat, 15 May 1999 00:15:46 -0400 (EDT) Received: from pneumatic-tube.sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA28075 for ; Sat, 15 May 1999 00:15:44 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA6711146 for <@external-mail-relay.sgi.com:tcp-impl@grc.nasa.gov>; Fri, 14 May 1999 21:15:35 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA89133 for <@relay.engr.sgi.com:tcp-impl@grc.nasa.gov>; Fri, 14 May 1999 21:15:34 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id VAA03266 for tcp-impl@grc.nasa.gov; Fri, 14 May 1999 21:15:33 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199905150415.VAA03266@bossette.engr.sgi.com> Subject: slow-start bit To: tcp-impl@grc.nasa.gov Date: Fri, 14 May 1999 21:15:33 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Is there any reason why it wouldn't be a good idea to use one of the free bits in the TCP header as a `slow-start' bit to enable a sender to indicate to the receiver that it is sending the first packet of a slow-start phase? This would enable the receiver to ACK immediately rather than delay the ACK, which can cause an unnecessary 200ms delay in some scenarios. Thanks, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@lerc.nasa.gov Sat May 15 04:11:40 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25728 for ; Sat, 15 May 1999 04:11:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA29268 for tcp-impl-outgoing; Sat, 15 May 1999 01:27:23 -0400 (EDT) Received: from pizda.davem.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA29260 for ; Sat, 15 May 1999 01:27:21 -0400 (EDT) Received: (from davem@localhost) by pizda.davem.net (8.9.3/8.9.3) id FAA03240; Sat, 15 May 1999 05:25:42 -0700 Date: Sat, 15 May 1999 05:25:42 -0700 Message-Id: <199905151225.FAA03240@pizda.davem.net> X-Authentication-Warning: pizda.davem.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: sm@bossette.engr.sgi.com CC: tcp-impl@grc.nasa.gov In-reply-to: <199905150415.VAA03266@bossette.engr.sgi.com> (sm@bossette.engr.sgi.com) Subject: Re: slow-start bit References: <199905150415.VAA03266@bossette.engr.sgi.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk From: sm@bossette.engr.sgi.com (Sam Manthorpe) Date: Fri, 14 May 1999 21:15:33 -0700 (PDT) Is there any reason why it wouldn't be a good idea to use one of the free bits in the TCP header as a `slow-start' bit to enable a sender to indicate to the receiver that it is sending the first packet of a slow-start phase? I would first want to test to see if other implementations will not have interoperability problems. The bits are marked as reserved now, but who knows what some TCP stack in a printer will do if they are not zero. Later, David S. Miller davem@redhat.com From owner-tcp-impl@lerc.nasa.gov Sat May 15 16:02:01 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28454 for ; Sat, 15 May 1999 16:02:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA09212 for tcp-impl-outgoing; Sat, 15 May 1999 12:49:56 -0400 (EDT) Received: from pushpak.CS.Berkeley.EDU (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA09208 for ; Sat, 15 May 1999 12:49:55 -0400 (EDT) Received: from pushpak.CS.Berkeley.EDU (localhost [127.0.0.1]) by pushpak.CS.Berkeley.EDU (8.9.1/8.9.1) with ESMTP id JAA00695; Sat, 15 May 1999 09:49:51 -0700 (PDT) Message-Id: <199905151649.JAA00695@pushpak.CS.Berkeley.EDU> To: "Eric A. Hall" cc: Sam Manthorpe , tcp-impl@grc.nasa.gov Subject: Re: slow-start bit In-reply-to: Your communique of Sat, 15 May 1999 09:29:47 PDT. <373DA0FB.EC414EC@ehsco.com> Date: Sat, 15 May 1999 09:49:51 -0700 From: Kevin Fall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > > From: "Eric A. Hall" > To: Sam Manthorpe > cc: tcp-impl@grc.nasa.gov > Subject: Re: slow-start bit > Date: Sat, 15 May 1999 09:29:47 PDT > > > > Is there any reason why it wouldn't be a good idea to use one of the > > free bits in the TCP header as a `slow-start' bit to enable a sender > > to indicate to the receiver that it is sending the first packet > > of a slow-start phase? > > I read this as "what are the mechanisms for doing circuit-setup messages > with TCP, and is it a good idea?" Right now, the only circuit-setup > message we have is the MSS option. I suppose that it would be possible > to add a flag that indicated that slow start was in effect, but why stop > there? Shouldn't we also add flags for congestion avoidance, current > retransmission timer, and so forth? All of these things will affect the > bi-directional exchange of data in some manner. > > One could define a set of bits or options that passed this info back and > forth. RFC2481 deals with this to some extent. Basically, a sender can indicate it has "reacted to congestion" in some way. This is useful in the scenario where a forward-traveling packet experiences ECN, the receiver needs to reflect this fact back in an ACK but the ACK may get lost, meaning the receiver actually echoes it back in each ack until it sees the sender's "reacted to congestion" bit. {thats the idea in a nutshell anyhow}. - K From owner-tcp-impl@lerc.nasa.gov Sat May 15 16:02:11 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28465 for ; Sat, 15 May 1999 16:02:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA08859 for tcp-impl-outgoing; Sat, 15 May 1999 12:31:03 -0400 (EDT) Received: from Arachnid.NTRG.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA08855 for ; Sat, 15 May 1999 12:31:01 -0400 (EDT) Received: from ehsco.com ([192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 495; Sat, 15 May 1999 09:29:47 -0700 Message-ID: <373DA0FB.EC414EC@ehsco.com> Date: Sat, 15 May 1999 09:29:47 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sam Manthorpe CC: tcp-impl@grc.nasa.gov Subject: Re: slow-start bit References: <199905150415.VAA03266@bossette.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Is there any reason why it wouldn't be a good idea to use one of the > free bits in the TCP header as a `slow-start' bit to enable a sender > to indicate to the receiver that it is sending the first packet > of a slow-start phase? I read this as "what are the mechanisms for doing circuit-setup messages with TCP, and is it a good idea?" Right now, the only circuit-setup message we have is the MSS option. I suppose that it would be possible to add a flag that indicated that slow start was in effect, but why stop there? Shouldn't we also add flags for congestion avoidance, current retransmission timer, and so forth? All of these things will affect the bi-directional exchange of data in some manner. One could define a set of bits or options that passed this info back and forth. This would let the sender say "I'm at multiple four with slow start" and "my retransmission timer is currently set to 28 ms" for example. Or, going even further, it would be possible for one end-point to request certain values from the other end-point, like "please use 28ms". It's early on a saturday morning and I'm just going through mail so I can't really think of a situation where that would be useful, but if it needs to be advertised then it can probably benefit from being set as well. Probably. There are lots of issues here of course. First and foremost is legacy support, which is the big thorn for all new options. It would take a really long time to update all of the existing products to use any new data in the header. Another issue is that lots of products out there don't do slow start, so passing the data would be irrelevant. I guess my feeling is that the broader issue of circuit-negotiation should definitely be addressed, but that it is sufficiently complex that it should probably be tabled for TCPng whenever that gets started. Would it make life easier or harder, and who would be affected by these messages (developers? users? admins?). I also think its time to start the work on TCPng. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Sat May 15 17:08:22 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28665 for ; Sat, 15 May 1999 17:08:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA10092 for tcp-impl-outgoing; Sat, 15 May 1999 14:05:42 -0400 (EDT) Received: from mail-relay2.yahoo.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA10088 for ; Sat, 15 May 1999 14:05:40 -0400 (EDT) Received: from borogove.yahoo.com (borogove.yahoo.com [205.216.162.65]) by mail-relay2.yahoo.com (8.9.3/8.9.3) with ESMTP id LAA21655; Sat, 15 May 1999 11:05:39 -0700 (PDT) Received: from localhost.yahoo.com (localhost.yahoo.com [127.0.0.1]) by borogove.yahoo.com (8.9.3/8.9.3) with SMTP id LAA23025; Sat, 15 May 1999 11:05:39 -0700 (PDT) Message-Id: <199905151805.LAA23025@borogove.yahoo.com> X-Authentication-Warning: borogove.yahoo.com: localhost.yahoo.com [127.0.0.1] didn't use HELO protocol To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: tcp-impl@grc.nasa.gov Subject: Re: slow-start bit In-reply-to: Your message of "Fri, 14 May 1999 21:15:33 PDT." <199905150415.VAA03266@bossette.engr.sgi.com> Date: Sat, 15 May 1999 11:05:38 -0700 From: John Hanley Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk You propose modifying sender behavior so that cooperating receivers could improve throughput. Could we achieve the same thing purely within the receiver? Going to one end of the spectrum, we might grumble "delayed ACK increases the complexity of TCP dynamics and sometimes Does The Wrong Thing," and so we modify the receiver to never delay ACK. OK, clearly not what we want; under some conditions delayed ACK is winning. So let's think about those conditions: low packet loss, high throughput, typically corresponds to LAN latencies or at least large open window. How about just causing the receiver to never delay ACK if more than `threshold' time has elapsed since the last ACK sent by the receiver? Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms. If it is much less than sender's RTO interval, then receiver would effectively suppress delayed ACK *without* the sender signaling that in an option bit. Cheers, JH From owner-tcp-impl@lerc.nasa.gov Sat May 15 17:56:17 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28793 for ; Sat, 15 May 1999 17:56:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA10761 for tcp-impl-outgoing; Sat, 15 May 1999 15:00:04 -0400 (EDT) Received: from jupiter.nal.utoronto.ca (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA10757; Sat, 15 May 1999 15:00:01 -0400 (EDT) Received: from nal.utoronto.ca by jupiter.nal.utoronto.ca (SMI-8.6/SMI-SVR4) id OAA08308; Sat, 15 May 1999 14:59:45 -0400 Message-ID: <373DC65C.5E5EFEE5@nal.utoronto.ca> Date: Sat, 15 May 1999 15:09:16 -0400 From: Raouf Boutaba Organization: University of Toronto X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Subject: MATA'99-EXTENDED DEADLINE-MAY 31 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit ================= [My apologies if you receive this more than once] ====================================================== MATA'99 First International Workshop on Mobile Agents for Telecommunication Applications http://ocri.genie.uottawa.ca/mata99 ====================================================== 6-8 October 1999, Ottawa, Canada ====================================================== Call for Papers and Participation ====================================================== Scope ========= Mobile agents refer to self-contained and identifiable computer programs that can move within the network and can act on behalf of the user or another entity. Most of the current research work on the mobile agent paradigm has two general goals: reduction of network traffic and asynchronous interaction. These two goals stem directly from the desire to reduce information overload and to efficiently use network resources. There are certainly many motivations for the use of mobile agent paradigm; however, intelligent information retrieval, network and mobility management, and network services are currently the three most cited application targets for a mobile agent system. The aim of the workshop is to provide a unique opportunity for researchers, software and application developers, and computer network technologists to discuss new developments on the mobile agent technology and applications. The workshop will focus on mobile agent issues across the areas of network management, mobile applications, Nomadic computing, feature interactions, Internet applications, QoS management, policy-based management, interactive multimedia, Tele-learning applications, and Computer Telephony Integration. Call for Papers, Tutorials, Panels and Exhibits ==================================================== Contributions describing original research, surveys and applications in the following areas are solicited: · Mobile Agent Architecture and Models · Agent Identification, Tracking and Persistence · Agent-based Mobility Management in Mobile Networks · Web Agent Systems · Agent Integration with CORBA and TINA · Active Networks and Mobile Agents · Feature Interaction and Agents · Mobile Agents Communication Language · Security in Mobile Agent Systems · Interactive Multimedia Presentation Agents · Agent -based Electronic Commerce · Agent-based Access to Legacy Services · Managing QoS with agents · Information Discovery and Gathering using agents · Data Mining Agents · Network Management Agents · Policy-based Management using Mobile Agents · Education and Applications of Mobile Agents · Prototypes and Experience with Mobile Agents · Seamless Messaging and Mobile Agents Authors are invited to submit papers (6,000 words) on completed research or work in progress to the MATA'99 Workshop Chair (Send 5 copies of the full manuscript): Prof. Ahmed Karmouch MATA'99 Workshop Chair School of Information Technology & Engineering University of Ottawa 161, Louis Pasteur Ottawa, Ontario, Canada, K1N 6N5 Tel. (613) 562-5800 x6203 Fax. (613) 562-5175 email: Karmouch @site.uottawa.ca Important Dates Full Paper due 31 May 1999 Proposals for Tutorials 30 May 1999 Notice of Acceptance 1 July 1999 Camera-ready paper due 1 August 1999 Electronic submission by Email is preferred. Alternatively, you may use our ftp server (user: ftp, psw: email), under . (Please send a note by email specifying name, type, and contents of the file). All paper submissions should have a cover page containing the title, names, email address and complete postal addresses (including telephone and fax numbers) for all authors. Please indicate the main author for the purpose of correspondence. The cover page should also provide an abstract (150 words maximum), and a list of keywords. Please include a statement stating that "when accepted, one of the authors will attend the Workshop to present the paper". Tutorials, panels and prototype demonstrations are also invited. More information on MATA'99 is available at http://ocri.genie.uottawa.ca/mata99 From owner-tcp-impl@lerc.nasa.gov Sun May 16 01:38:30 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07566 for ; Sun, 16 May 1999 01:38:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA15919 for tcp-impl-outgoing; Sat, 15 May 1999 22:08:31 -0400 (EDT) Received: from pneumatic-tube.sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA15915 for ; Sat, 15 May 1999 22:08:29 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA6028731; Sat, 15 May 1999 19:08:17 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA69861; Sat, 15 May 1999 19:08:16 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA08291; Sat, 15 May 1999 19:08:03 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199905160208.TAA08291@bossette.engr.sgi.com> Subject: Re: slow-start bit To: jh@yahoo-inc.com (John Hanley) Date: Sat, 15 May 1999 19:08:03 -0700 (PDT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <199905151805.LAA23025@borogove.yahoo.com> from "John Hanley" at May 15, 99 11:05:38 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit John Hanley wrote: > > You propose modifying sender behavior so that cooperating receivers > could improve throughput. Could we achieve the same thing purely within > the receiver? I'm not sure. It would certainly be desirable but I haven't been able to think of a _simple_ way of doing it and that is an important criteria for me. > So let's think about those conditions: low packet loss, high throughput, > typically corresponds to LAN latencies or at least large open window. > How about just causing the receiver to never delay ACK if more than > `threshold' time has elapsed since the last ACK sent by the receiver? > Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms. Wouldn't this be bad for slow, high latency connections? This would effectively switch off delayed-ack altogether since it wouldn't be too hard to have a connection where the inter-packet-arrival time at the receiver is greater than 50ms. > If it is much less than sender's RTO interval, then receiver would effectively > suppress delayed ACK *without* the sender signaling that in an option bit. How can the receiver know the sender's RTO? It could estimate it, but I can't think of any simple mechanism that would give a reliable enough estimate. Time between acking byte x and receiving byte x+1 wouldn't work because the receiver can't be sure that the sender's congestion window is such that sending byte x+1 requires byte x being acked. I would want to avoid any excessive complexity in the TCP stack since this is bad for low network latency, high bandwidth situations where performance is CPU and memory-access speed bound. The simplicity of the `slow-start-bit' appeals to me. I don't know how big of an issue the implementations using the reserved bits that David brough up is. This would also be an issue for ECN then. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@lerc.nasa.gov Sun May 16 01:38:31 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07570 for ; Sun, 16 May 1999 01:38:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA16157 for tcp-impl-outgoing; Sat, 15 May 1999 22:16:22 -0400 (EDT) Received: from smtprtp (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA16153 for ; Sat, 15 May 1999 22:16:21 -0400 (EDT) Received: from zrtps008 by smtprtp; Sat, 15 May 1999 22:15:59 -0400 Received: from wcars0d7.us.nortel.com (actually wcars0d7.ca.nortel.com) by zrtps008; Sat, 15 May 1999 22:14:28 -0400 Received: from localhost by wcars0d7.us.nortel.com (SMI-8.6/SMI-SVR4 CUE5.1) id WAA29692; Sat, 15 May 1999 22:18:05 -0400 Date: Sat, 15 May 1999 22:18:04 -0400 (EDT) From: "Jamal Hadi Salim" X-Sender: hadi@wcars0d7 To: "David S. Miller" cc: sm@bossette.engr.sgi.com, tcp-impl@grc.nasa.gov Subject: Re: slow-start bit In-Reply-To: <199905151225.FAA03240@pizda.davem.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sat, 15 May 1999, David S. Miller wrote: > > I would first want to test to see if other implementations will not > have interoperability problems. The bits are marked as reserved now, > but who knows what some TCP stack in a printer will do if they are not > zero. > ECN (RFC2481), for example, tests by setting two of the bits during the SYN exchange. If the remote end responds with the same bit set then it is highly likely that it is lying. You can use a combination of such tricks. In the established state, it would be very tricky to catch any misuse of the reserved bits. cheers, jamal Computing Technology Labs (CTL), Nortel From owner-tcp-impl@lerc.nasa.gov Sun May 16 01:42:29 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08040 for ; Sun, 16 May 1999 01:42:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA15986 for tcp-impl-outgoing; Sat, 15 May 1999 22:11:44 -0400 (EDT) Received: from pneumatic-tube.sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA15982 for ; Sat, 15 May 1999 22:11:43 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA5289090; Sat, 15 May 1999 19:11:40 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA39468; Sat, 15 May 1999 19:11:40 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA08335; Sat, 15 May 1999 19:11:39 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199905160211.TAA08335@bossette.engr.sgi.com> Subject: Re: slow-start bit To: davem@redhat.com (David S. Miller) Date: Sat, 15 May 1999 19:11:39 -0700 (PDT) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <199905151225.FAA03240@pizda.davem.net> from "David S. Miller" at May 15, 99 05:25:42 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit David S. Miller wrote: > > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > Date: Fri, 14 May 1999 21:15:33 -0700 (PDT) > > Is there any reason why it wouldn't be a good idea to use one of > the free bits in the TCP header as a `slow-start' bit to enable a > sender to indicate to the receiver that it is sending the first > packet of a slow-start phase? > > I would first want to test to see if other implementations will not > have interoperability problems. The bits are marked as reserved now, > but who knows what some TCP stack in a printer will do if they are not > zero. This is impossible to thoroughly test prior to software release, isn't it. I would introduce a systuneable to enable/disable the feature, default on, so you could switch it off if your LAN has hosts with broken stacks. This would also be an issue for RFC 2481. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@lerc.nasa.gov Sun May 16 02:31:30 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15627 for ; Sun, 16 May 1999 02:31:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA16967 for tcp-impl-outgoing; Sat, 15 May 1999 23:22:54 -0400 (EDT) Received: from smtprtp (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id XAA16963 for ; Sat, 15 May 1999 23:22:53 -0400 (EDT) Received: from zrchb213.us.nortel.com (actually 47.100.128.42) by smtprtp; Sat, 15 May 1999 23:22:24 -0400 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Sat, 15 May 1999 22:22:23 -0500 Message-ID: <7DF44F4DE801D31198620000F80930C10326CA@zrchb214.us.nortel.com> From: "Spencer Dawkins" To: "'David S. Miller'" , sm@bossette.engr.sgi.com Cc: tcp-impl@grc.nasa.gov Subject: RE: slow-start bit Date: Sat, 15 May 1999 22:22:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The I-D http://search.ietf.org/internet-drafts/draft-montenegro-pilc-ltn-01.txt (soon to be 02, but hasn't made it onto the web site yet) talks about some aspects of larger initial windows and ACK-first/ACK-every strategies in 4.3.1 and 4.3.2. The target environment for this draft isn't just HTTP, but we were thinking about HTTP, and it bothered us that the default was to do a delayed-ACK timeout at the server if the HTTP request is bigger than a single segment, followed by a delayed-ACK timeout at the client if the HTTP response is bigger than a single segment - as it almost certainly would be. We were pretty sure that ACK-first was safe, because it doesn't increase the traffic level on the network (you send the ACK immediately instead of delaying it, but it's the same ACK). This draft is being discussed in the PILC working group (although it won't be a WG output), but we would love to hear your thoughts as well. Spencer > -----Original Message----- > From: David S. Miller [SMTP:davem@redhat.com] > Sent: Saturday, May 15, 1999 7:26 AM > To: sm@bossette.engr.sgi.com > Cc: tcp-impl@grc.nasa.gov > Subject: Re: slow-start bit > > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > Date: Fri, 14 May 1999 21:15:33 -0700 (PDT) > > Is there any reason why it wouldn't be a good idea to use one of > the free bits in the TCP header as a `slow-start' bit to enable a > sender to indicate to the receiver that it is sending the first > packet of a slow-start phase? > > I would first want to test to see if other implementations will not > have interoperability problems. The bits are marked as reserved now, > but who knows what some TCP stack in a printer will do if they are not > zero. > > Later, > David S. Miller > davem@redhat.com From owner-tcp-impl@lerc.nasa.gov Sun May 16 20:58:04 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28878 for ; Sun, 16 May 1999 20:58:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA00509 for tcp-impl-outgoing; Sun, 16 May 1999 17:49:49 -0400 (EDT) Received: from saba.cs.washington.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA00505 for ; Sun, 16 May 1999 17:49:47 -0400 (EDT) Received: from localhost (cardwell@localhost) by saba.cs.washington.edu (8.8.8+CS/7.2ws+) with SMTP id OAA15478 for ; Sun, 16 May 1999 14:49:46 -0700 Date: Sun, 16 May 1999 14:49:46 -0700 (PDT) From: Neal Cardwell To: tcp-impl@grc.nasa.gov Subject: RE: slow-start bit In-Reply-To: <7DF44F4DE801D31198620000F80930C10326CA@zrchb214.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On a related note, delayed ACKs can hurt performance even after the first few RTTs of slow start. Whether in congestion avoidance or slow start, a sender that uses any Vegas-like bandwidth estimation scheme incoporating delay as a congestion signal will work much better if either o the receiver does not delay ACKs o the receiver tells the sender (with, say, a TCP option) by how much an ACK was delayed Currently, Vegas and other bandwidth estimation schemes are forced to jump through hoops to filter out the effect of delayed ACKs because they introduce delays that look similar to queuing delay. neal From owner-tcp-impl@lerc.nasa.gov Mon May 17 16:24:42 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04049 for ; Mon, 17 May 1999 16:24:39 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24138 for tcp-impl-outgoing; Mon, 17 May 1999 12:59:42 -0400 (EDT) Received: from sabre.sjf.novell.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA24132 for ; Mon, 17 May 1999 12:59:37 -0400 (EDT) Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.1/8.9.1) id KAA30226; Mon, 17 May 1999 10:11:57 -0700 Reply-To: mahdavi@novell.com To: tcp-impl@grc.nasa.gov Subject: Re: slow-start bit References: <199905150415.VAA03266@bossette.engr.sgi.com> From: Jamshid Mahdavi Date: 17 May 1999 10:11:56 -0700 In-Reply-To: sm@bossette.engr.sgi.com's message of "Fri, 14 May 1999 21:15:33 -0700 (PDT)" Message-ID: Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk sm@bossette.engr.sgi.com (Sam Manthorpe) writes: > Hi, > > Is there any reason why it wouldn't be a good idea to use one of the > free bits in the TCP header as a `slow-start' bit to enable a sender > to indicate to the receiver that it is sending the first packet > of a slow-start phase? This would enable the receiver to ACK > immediately rather than delay the ACK, which can cause an unnecessary > 200ms delay in some scenarios. Note that RFC2414 allows 2, 3, or 4 packets on initial slowstart, which alleviates the specific problem you are concerned with. Some of the other concerns which people brought up might still be interesting to consider. The increased initial window doesn't apply after a timeout, but generally you've already been waiting for ~ 1 sec on a timeout anyway, so saving the 200 msec in that case may not be as important to you. --J From owner-tcp-impl@lerc.nasa.gov Mon May 17 16:33:28 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04159 for ; Mon, 17 May 1999 16:33:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA26266 for tcp-impl-outgoing; Mon, 17 May 1999 13:17:51 -0400 (EDT) Received: from frantic.bsdi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA26258 for ; Mon, 17 May 1999 13:17:49 -0400 (EDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id MAA04837; Mon, 17 May 1999 12:15:39 -0500 (CDT) Date: Mon, 17 May 1999 12:15:39 -0500 (CDT) From: David Borman Message-Id: <199905171715.MAA04837@frantic.bsdi.com> To: jh@yahoo-inc.com, sm@bossette.engr.sgi.com Subject: Re: slow-start bit Cc: tcp-impl@grc.nasa.gov Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk John, > Subject: Re: slow-start bit > Date: Sat, 15 May 1999 11:05:38 -0700 > From: John Hanley > ... > How about just causing the receiver to never delay ACK if more than > `threshold' time has elapsed since the last ACK sent by the receiver? > Certainly `threshold' would be < 200ms; I'm thinking around 100ms or 50ms. > If it is much less than sender's RTO interval, then receiver would effectively > suppress delayed ACK *without* the sender signaling that in an option bit. Many years ago I put the slow-start code into UNICOS. The poor interaction between the initial packet during slow-start and the delayed ACK/ACK every other packet stratagey became quite obvious, both at connection startup and after the connection had been idle for awhile and the sender restarted slow-start. There are two ways to address this. Either the receiver doesn't delay ACKs during slow-start, or the sender sends more than 1 packet to get past the ack every other packet strategy. I figured that I couldn't change all the other TCPs out there, and since either one will improve throughput, I implemented the reciever changes. When a connection was first opened, I immediatly acked the first N packets (actually, first N*maxseg bytes) , and then went back to the ack-every-other-packet strategy. I chose N=8 for no particular reason, other than it was a power of 2, and 16 seemed too big. I didn't just use N=2, because it helps to get through slow-start when you ACK every packet, and with N=8 you can get through a couple of round-trip times before going back to ack-every-other-packet. It worked fine, so there never was any reason to change it. The actual implementation took IRS and added N*maxseg to it. As long as data arrived with a seq number less than that, it was immediatly acked. Once we passed that point, the pointer was pulled along equal to seg.rcv_next. Then, in TCP input, if the idle counter got large enough to kick in slow-start, I reset the value to seg.rcv_next + N*maxseg, so that packets would be immediatly ACKed again. The nice thing was that with these changes our throughput improved both in Cray->Cray transfers, and other->Cray transfers. Combine those receiver changes with the new initial window of 4K, (see RFC 2414), and you can eliminate a lot of the artificial delays due to bad delayed ACK interaction. I don't see a need for a "slow start" bit. Effectivly it would be a "please ACK immediatly" bit, and would be ripe for abuse by setting it in every packet, in which case you'd have to put in code to determine whether or not the bit is legitimate, which by the way would be similar code to what I've just described, so just skip the bit. -David Borman, dab@bsdi.com From owner-tcp-impl@lerc.nasa.gov Mon May 17 18:15:54 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04987 for ; Mon, 17 May 1999 18:15:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12780 for tcp-impl-outgoing; Mon, 17 May 1999 15:30:43 -0400 (EDT) Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA12772 for ; Mon, 17 May 1999 15:30:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12916 for ; Mon, 17 May 1999 12:30:39 -0700 (PDT) Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA21767 for ; Mon, 17 May 1999 12:30:32 -0700 (PDT) Received: from shield (shield [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id MAA05156 for ; Mon, 17 May 1999 12:30:20 -0700 (PDT) Date: Mon, 17 May 1999 12:30:20 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: slow-start bit To: tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" <199905171715.MAA04837@frantic.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > The actual implementation took IRS and added N*maxseg to it. As long > as data arrived with a seq number less than that, it was immediatly > acked. Once we passed that point, the pointer was pulled along > equal to seg.rcv_next. Then, in TCP input, if the idle counter > got large enough to kick in slow-start, I reset the value to > seg.rcv_next + N*maxseg, so that packets would be immediatly ACKed > again. Just curious, besides UNICOS, have you put it into other stacks, like BSDI? I am wondering how common this is, and if it is a good idea for people to implement that. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Mon May 17 18:20:17 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05022 for ; Mon, 17 May 1999 18:20:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12018 for tcp-impl-outgoing; Mon, 17 May 1999 15:24:48 -0400 (EDT) Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA12010 for ; Mon, 17 May 1999 15:24:43 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10157 for ; Mon, 17 May 1999 12:24:41 -0700 (PDT) Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA13324 for ; Mon, 17 May 1999 12:24:40 -0700 (PDT) Received: from shield (shield [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id MAA05152 for ; Mon, 17 May 1999 12:24:40 -0700 (PDT) Date: Mon, 17 May 1999 12:24:40 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: slow-start bit To: tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" <199905150415.VAA03266@bossette.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Is there any reason why it wouldn't be a good idea to use one of the > free bits in the TCP header as a `slow-start' bit to enable a sender > to indicate to the receiver that it is sending the first packet > of a slow-start phase? This would enable the receiver to ACK > immediately rather than delay the ACK, which can cause an unnecessary > 200ms delay in some scenarios. First of all, I think most stacks now default to have a larger initial window according to RFC2414. But let's assume otherwise. TCP does slow start in 3 cases, initial slow start, slow start after idle, and slow start after a retransmission timeout. In the first case, if a receiver acks immediately for the first segment, there will be no delay ack. In the third case, it is quite probable that the first segment will be out of order, unless all the segments in the last window are lost. The receiver should ack immediately. So I guess the slow start bit is most useful in the second case. But because of an implementation artifact (use last receive time to do idle check), most stacks do not perform slow start after idle in many cases, like HTTP requests. Again there will be no delay ack. It seems to me that the slow start bit may not be very useful in the context of the problem you described above, even with stacks which do not support RFC2414. Well, I assume that most stacks ack immediatley at least for the first segment and slow start after timeout is likely to trigger an immediate ack... There can be other uses of slow start bit. But I do not think it is a good idea to use it to solve the delay ack problem you described. Larger initial window is better solution. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Mon May 17 19:48:02 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05387 for ; Mon, 17 May 1999 19:48:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA22461 for tcp-impl-outgoing; Mon, 17 May 1999 17:01:19 -0400 (EDT) Received: from atlrel2.hp.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA22457 for ; Mon, 17 May 1999 17:01:16 -0400 (EDT) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.8.80.103]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id RAA22769; Mon, 17 May 1999 17:01:11 -0400 (EDT) Received: from cup.hp.com (raj@loiter [15.8.80.103]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id OAA05279; Mon, 17 May 1999 14:01:11 -0700 (PDT) Message-ID: <37408397.D419771A@cup.hp.com> Date: Mon, 17 May 1999 14:01:11 -0700 From: Rick Jones Organization: SNSL X-Mailer: Mozilla 4.08 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: Kacheong Poon CC: tcp-impl@grc.nasa.gov Subject: Re: slow-start bit References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Just curious, besides UNICOS, have you put it into other stacks, like BSDI? > I am wondering how common this is, and if it is a good idea for people to > implement that. I've seen evidence that perhap sLinux and HP-UX 11 will immediately ack at least the first segment received. I've not looked for anything beyond that. rick jones -- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Mon May 17 21:11:38 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05861 for ; Mon, 17 May 1999 21:11:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA26906 for tcp-impl-outgoing; Mon, 17 May 1999 18:13:23 -0400 (EDT) Received: from pizda.davem.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA26894 for ; Mon, 17 May 1999 18:13:21 -0400 (EDT) Received: (from davem@localhost) by pizda.davem.net (8.9.3/8.9.3) id PAA02104; Mon, 17 May 1999 15:08:31 -0700 Date: Mon, 17 May 1999 15:08:31 -0700 Message-Id: <199905172208.PAA02104@pizda.davem.net> X-Authentication-Warning: pizda.davem.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: raj@cup.hp.com CC: kacheong.poon@Eng.Sun.COM, tcp-impl@grc.nasa.gov In-reply-to: <37408397.D419771A@cup.hp.com> (message from Rick Jones on Mon, 17 May 1999 14:01:11 -0700) Subject: Re: slow-start bit References: <37408397.D419771A@cup.hp.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Date: Mon, 17 May 1999 14:01:11 -0700 From: Rick Jones > Just curious, besides UNICOS, have you put it into other stacks, > like BSDI? I am wondering how common this is, and if it is a > good idea for people to implement that. I've seen evidence that perhap sLinux and HP-UX 11 will immediately ack at least the first segment received. I've not looked for anything beyond that. On Linux we implemented things this way because if hosts handle the initial congestion window values correctly (ie. don't advance it for the initial SYN, unfortunately almost all stacks do) this is quite desirable behavior. Later, David S. Miller davem@redhat.com From owner-tcp-impl@lerc.nasa.gov Mon May 17 21:12:02 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05872 for ; Mon, 17 May 1999 21:12:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA27467 for tcp-impl-outgoing; Mon, 17 May 1999 18:28:00 -0400 (EDT) Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA27461 for ; Mon, 17 May 1999 18:27:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08752 for ; Mon, 17 May 1999 15:27:53 -0700 (PDT) Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA06783 for ; Mon, 17 May 1999 15:27:53 -0700 (PDT) Received: from shield (shield [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA05294 for ; Mon, 17 May 1999 15:27:52 -0700 (PDT) Date: Mon, 17 May 1999 15:27:52 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: slow-start bit To: tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" <199905172208.PAA02104@pizda.davem.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I've seen evidence that perhap sLinux and HP-UX 11 will immediately > ack at least the first segment received. I've not looked for > anything beyond that. > > On Linux we implemented things this way because if hosts handle the > initial congestion window values correctly (ie. don't advance it for > the initial SYN, unfortunately almost all stacks do) this is quite > desirable behavior. Oh, I was not just asking if TCP would ack the first segment. I think many stacks already did that. David changed UNICOS not to delay any ack for the first N=8 segments. This I do not believe is quite common. Is it? K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Mon May 17 22:27:35 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07132 for ; Mon, 17 May 1999 22:27:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA29936 for tcp-impl-outgoing; Mon, 17 May 1999 19:42:36 -0400 (EDT) Received: from pizda.davem.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA29932 for ; Mon, 17 May 1999 19:42:33 -0400 (EDT) Received: (from davem@localhost) by pizda.davem.net (8.9.3/8.9.3) id QAA07315; Mon, 17 May 1999 16:42:05 -0700 Date: Mon, 17 May 1999 16:42:05 -0700 Message-Id: <199905172342.QAA07315@pizda.davem.net> X-Authentication-Warning: pizda.davem.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: kacheong.poon@Eng.Sun.COM CC: tcp-impl@grc.nasa.gov In-reply-to: (message from Kacheong Poon on Mon, 17 May 1999 15:27:52 -0700 (PDT)) Subject: Re: slow-start bit References: Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Date: Mon, 17 May 1999 15:27:52 -0700 (PDT) From: Kacheong Poon > On Linux we implemented things this way because if hosts handle > the initial congestion window values correctly (ie. don't advance > it for the initial SYN, unfortunately almost all stacks do) this > is quite desirable behavior. Oh, I was not just asking if TCP would ack the first segment. I think many stacks already did that. I believe several also do not, to match up with the "SYN congestion window" bug. David changed UNICOS not to delay any ack for the first N=8 segments. This I do not believe is quite common. Is it? This is not common as far as I am aware. Perhaps it is done to jack up the congestion window quickly over high speed links? Later, David S. Miller davem@redhat.com From owner-tcp-impl@lerc.nasa.gov Tue May 18 00:29:47 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09323 for ; Tue, 18 May 1999 00:29:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA03360 for tcp-impl-outgoing; Mon, 17 May 1999 21:50:44 -0400 (EDT) Received: from fred.muc.de (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA03356 for ; Mon, 17 May 1999 21:50:42 -0400 (EDT) Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 10jZ1o-0000JY-00; Tue, 18 May 1999 03:50:44 +0200 Date: Tue, 18 May 1999 03:50:44 +0200 From: Andi Kleen To: Kacheong Poon Cc: tcp-impl@grc.nasa.gov Subject: Re: slow-start bit Message-ID: <19990518035044.A1041@fred.muc.de> References: <199905172208.PAA02104@pizda.davem.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Kacheong Poon on Tue, May 18, 1999 at 12:27:52AM +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Tue, May 18, 1999 at 12:27:52AM +0200, Kacheong Poon wrote: > > I've seen evidence that perhap sLinux and HP-UX 11 will immediately > > ack at least the first segment received. I've not looked for > > anything beyond that. > > > > On Linux we implemented things this way because if hosts handle the > > initial congestion window values correctly (ie. don't advance it for > > the initial SYN, unfortunately almost all stacks do) this is quite > > desirable behavior. > > Oh, I was not just asking if TCP would ack the first segment. I think many > stacks already did that. David changed UNICOS not to delay any ack for the > first N=8 segments. This I do not believe is quite common. Is it? Linux 2.2 acks the first segment after slow start (this means at the beginning or when an ooo or old segment has been seen) -Andi -- This is like TV. I don't like TV. From owner-tcp-impl@lerc.nasa.gov Wed May 19 15:11:05 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26360 for ; Wed, 19 May 1999 15:11:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA15717 for tcp-impl-outgoing; Wed, 19 May 1999 12:01:50 -0400 (EDT) Received: from sabre.sjf.novell.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA15713 for ; Wed, 19 May 1999 12:01:48 -0400 (EDT) Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.1/8.9.1) id JAA31706; Wed, 19 May 1999 09:14:40 -0700 Reply-To: mahdavi@novell.com To: tcp-impl@grc.nasa.gov Subject: Re: Retransmissions without explanation References: <3104310CE765D211A66E00104B87219F105FC4@NTVICRJ07> From: Jamshid Mahdavi Date: 19 May 1999 09:14:39 -0700 In-Reply-To: Jaques Rechtand's message of "Tue, 18 May 1999 15:46:27 -0300" Message-ID: Lines: 45 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk [This is in response to a note on tcpsat about retransmit timers firing too early on long connections.] I have seen unwanted retransmit timouts (i.e. bugs) of this nature in two other implementations as well. All of these implementations have in common more accurate timers. I suspect it would be useful to have more detailed documentation on the use of timers and computation of RTO. However, it isn't clear to me that there is a lot of consensus on a number of the issues. Here are some issues which I think are unresolved, or could use better documentation: - How to modify the RTO calculation when doing 1323 timestamps. The idea here is that you are getting measurements more quickly, so you might want to adjust the moving average calculation. - Running with fine-grained clocks. 1. Should you? 2. Are adjustments to the computations needed? (Remember delayed ack might tack on 200msec). - Always time the RTO from the last packet in flight. - Should there be a minimum RTO? - Should there be a minimum deviation? Interestingly, I see no discussion of these issues in the TCPSAT drafts, and I don't believe I have seen them covered in any of the other relevant places either (i.e. pilc or tcl-impl). I'd be happy to pull together ideas on this subject if people are interested in seeing such a document. --Jamshid PS. On a process note, I'm thinking this belongs under tcp-impl, so I've sent this note to tcp-impl and BCC'd tcpsat (where the conversation started). From owner-tcp-impl@lerc.nasa.gov Thu May 20 07:38:49 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18744 for ; Thu, 20 May 1999 07:38:49 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA08296 for tcp-impl-outgoing; Thu, 20 May 1999 04:21:34 -0400 (EDT) Received: from seeyes.seeyes.co.in (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA08290 for ; Thu, 20 May 1999 04:21:28 -0400 (EDT) Received: from seeyes.seeyes.co.in ([10.1.5.116]) by seeyes.seeyes.co.in (8.8.7/8.8.5) with ESMTP id OAA00526; Thu, 20 May 1999 14:03:48 +0530 Message-Id: <199905200833.OAA00526@seeyes.seeyes.co.in> From: "Umesh Mallugari" To: Cc: Subject: Re: Retransmissions without explanation Date: Thu, 20 May 1999 14:07:09 +0530 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Yes, Jamshid, this is a practical issue that has been out of thought for a long time. I think the following points you mentioned are related. > - Running with fine-grained clocks. > 1. Should you? > 2. Are adjustments to the computations needed? (Remember delayed > ack might tack on 200msec). > > - Always time the RTO from the last packet in flight. And, I vote for the idea that adjustment/computation should be based on the last packet in flight because it is more related to the current network conditions. At the same time, there should be a minimum. So, the following points are also worth the thought. > - Should there be a minimum RTO? > > - Should there be a minimum deviation? However, attention to speed must be kept in mind while implementing these. -Umesh. ---------- > From: Jamshid Mahdavi > To: tcp-impl@grc.nasa.gov > Subject: Re: Retransmissions without explanation > Date: Wednesday, May 19, 1999 9:44 PM > > > [This is in response to a note on tcpsat about retransmit timers > firing too early on long connections.] > > I have seen unwanted retransmit timouts (i.e. bugs) of this nature in > two other implementations as well. All of these implementations have > in common more accurate timers. I suspect it would be useful to have > more detailed documentation on the use of timers and computation of > RTO. However, it isn't clear to me that there is a lot of consensus > on a number of the issues. > > Here are some issues which I think are unresolved, or could use better > documentation: > > - How to modify the RTO calculation when doing 1323 timestamps. The > idea here is that you are getting measurements more quickly, so you > might want to adjust the moving average calculation. > > - Running with fine-grained clocks. > 1. Should you? > 2. Are adjustments to the computations needed? (Remember delayed > ack might tack on 200msec). > > - Always time the RTO from the last packet in flight. > > - Should there be a minimum RTO? > > - Should there be a minimum deviation? > > Interestingly, I see no discussion of these issues in the TCPSAT > drafts, and I don't believe I have seen them covered in any of the > other relevant places either (i.e. pilc or tcl-impl). > > I'd be happy to pull together ideas on this subject if people are > interested in seeing such a document. > > --Jamshid > > PS. On a process note, I'm thinking this belongs under tcp-impl, so > I've sent this note to tcp-impl and BCC'd tcpsat (where the > conversation started). > > From owner-tcp-impl@lerc.nasa.gov Thu May 20 14:00:26 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01626 for ; Thu, 20 May 1999 14:00:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA05247 for tcp-impl-outgoing; Thu, 20 May 1999 10:48:33 -0400 (EDT) Received: from ptnt4ln.pensionstrust.smtp.co.uk (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA05241 for ; Thu, 20 May 1999 10:48:32 -0400 (EDT) Received: by PT_NT4_LN with Internet Mail Service (5.5.2448.0) id ; Thu, 20 May 1999 15:49:58 +0100 Message-ID: <990CE6A8D31FD2118BCE00A0245506C733904B@PT_NT1> From: Steve Nice To: "'tcp-impl@lerc.nasa.gov'" Subject: Test Date: Thu, 20 May 1999 15:49:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a test. Please ignore. From owner-tcp-impl@lerc.nasa.gov Thu May 20 19:29:52 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05745 for ; Thu, 20 May 1999 19:29:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA12946 for tcp-impl-outgoing; Thu, 20 May 1999 16:16:03 -0400 (EDT) Received: from daffy.ee.lbl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA12938; Thu, 20 May 1999 16:16:01 -0400 (EDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id NAA00424; Thu, 20 May 1999 13:15:59 -0700 (PDT) Message-Id: <199905202015.NAA00424@daffy.ee.lbl.gov> To: mahdavi@novell.com Cc: tcp-impl@grc.nasa.gov, mallman@grc.nasa.gov Subject: Re: Retransmissions without explanation In-reply-to: Your message of 19 May 1999 09:14:39 PDT. Date: Thu, 20 May 1999 13:15:59 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Here are some issues which I think are unresolved, or could use better > documentation: > > - How to modify the RTO calculation when doing 1323 timestamps. The > idea here is that you are getting measurements more quickly, so you > might want to adjust the moving average calculation. > > - Running with fine-grained clocks. > 1. Should you? > 2. Are adjustments to the computations needed? (Remember delayed > ack might tack on 200msec). > > - Always time the RTO from the last packet in flight. > > - Should there be a minimum RTO? > > - Should there be a minimum deviation? Mark Allman and I are just finishing final copy for a paper to appear in SIGCOMM '99 that looks in detail at a number of these tradeoffs. We'll send an announcement to the list within a couple of days. The brief version is: (1) The moving average coefficients don't matter, so even though you're running a lot more measurements through it with RTTM than previously, that has little effect on the effectiveness of the RTO computation. (2) Finer granularity clocks are a win primarily because there's less chance of the deviation being computed as 0 ticks (your last point above). Below 100 msec you get diminishing benefit as you make the granularity finer. (3) You don't really have to worry about things like timing the last packet in flight because RTO has an implicit last-RTT term added into it (because the timer is restarted as new data is sent; pointed out by Reiner Ludwig). (4) The #1 biggest effect on how well the estimator performs is its minimum value - there definitely should be a minimum RTO. - Vern From owner-tcp-impl@lerc.nasa.gov Thu May 20 20:08:16 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06067 for ; Thu, 20 May 1999 20:08:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA17935 for tcp-impl-outgoing; Thu, 20 May 1999 17:14:51 -0400 (EDT) Received: from sabre.sjf.novell.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA17931 for ; Thu, 20 May 1999 17:14:49 -0400 (EDT) Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.1/8.9.1) id OAA32763; Thu, 20 May 1999 14:28:06 -0700 Reply-To: mahdavi@novell.com To: tcp-impl@grc.nasa.gov Subject: Re: Retransmissions without explanation References: <199905202015.NAA00424@daffy.ee.lbl.gov> From: Jamshid Mahdavi Date: 20 May 1999 14:28:05 -0700 In-Reply-To: Vern Paxson's message of "Thu, 20 May 1999 13:15:59 PDT" Message-ID: Lines: 42 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Mark Allman and I are just finishing final copy for a paper to appear in > SIGCOMM '99 that looks in detail at a number of these tradeoffs. We'll send > an announcement to the list within a couple of days. The brief version is: > > (1) The moving average coefficients don't matter, so even though > you're running a lot more measurements through it with RTTM > than previously, that has little effect on the effectiveness of > the RTO computation. Hmmm, I wonder if that statement holds in both senses: does doing all of the extra measurements also not *improve* the quality of the RTO computation? I'd imagine that the key factor here would be transients such as initial slowstart or path changes. > (2) Finer granularity clocks are a win primarily because there's > less chance of the deviation being computed as 0 ticks (your > last point above). Below 100 msec you get diminishing benefit > as you make the granularity finer. > > (3) You don't really have to worry about things like timing the > last packet in flight because RTO has an implicit last-RTT term > added into it (because the timer is restarted as new data is > sent; pointed out by Reiner Ludwig). I'm pretty sure that I've seen at least one implementation which doesn't do this. To be honest, I was never quite able to figure out how you could *not* do this. But the point which I thought was worth putting in writing somewhere is that you should only take a timeout if you believe *all* the packets in flight have been dropped. As opposed to beleiving that *some* packet in flight was dropped. > (4) The #1 biggest effect on how well the estimator performs is its > minimum value - there definitely should be a minimum RTO. Good to hear this. I've been looking at this on and off for a little while now and was pretty convinced that there needed to be either a min RTO or a min deviation. To my mind, the deviation term makes more sense to impose a minimum on, because even on long paths I believe you could still see the occasional spike in delay. --J From owner-tcp-impl@lerc.nasa.gov Thu May 20 21:13:31 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06483 for ; Thu, 20 May 1999 21:13:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA22594 for tcp-impl-outgoing; Thu, 20 May 1999 18:30:44 -0400 (EDT) Received: from palrel3.hp.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA22589 for ; Thu, 20 May 1999 18:30:41 -0400 (EDT) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.8.80.103]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id PAA26547 for ; Thu, 20 May 1999 15:30:34 -0700 (PDT) Received: from cup.hp.com (raj@loiter [15.8.80.103]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id PAA10645 for ; Thu, 20 May 1999 15:30:30 -0700 (PDT) Message-ID: <37448D05.70348432@cup.hp.com> Date: Thu, 20 May 1999 15:30:29 -0700 From: Rick Jones Organization: SNSL X-Mailer: Mozilla 4.08 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Retransmissions without explanation References: <199905202015.NAA00424@daffy.ee.lbl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > But the point which I thought was worth > putting in writing somewhere is that you should only take a timeout if > you believe *all* the packets in flight have been dropped. As opposed > to beleiving that *some* packet in flight was dropped. Shouldn't that be "if you think enough packets have been dropped such that you will not trigger fast rtx?" How one divines that is currently beyond me :) rick jones -- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@lerc.nasa.gov Thu May 20 22:39:21 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08615 for ; Thu, 20 May 1999 22:39:20 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25174 for tcp-impl-outgoing; Thu, 20 May 1999 19:57:50 -0400 (EDT) Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA25170 for ; Thu, 20 May 1999 19:57:49 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22913 for ; Thu, 20 May 1999 16:57:48 -0700 (PDT) Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA07101 for ; Thu, 20 May 1999 16:57:46 -0700 (PDT) Received: from shield (shield [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id QAA07955 for ; Thu, 20 May 1999 16:57:45 -0700 (PDT) Date: Thu, 20 May 1999 16:57:45 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: Retransmissions without explanation To: tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Hmmm, I wonder if that statement holds in both senses: does doing all > of the extra measurements also not *improve* the quality of the RTO > computation? I'd imagine that the key factor here would be transients > such as initial slowstart or path changes. In BSD TCP, I'd say taking more measurements does not improve the quality of RTO computation. The reason is that the minimum is already 1s. With normal terrestrial links, this is usually more than enough to guarantee that a segment has been lost. So I guess the question should be asked in the context of TCP using fine grain timer. > I'm pretty sure that I've seen at least one implementation which > doesn't do this. To be honest, I was never quite able to figure out > how you could *not* do this. But the point which I thought was worth > putting in writing somewhere is that you should only take a timeout if > you believe *all* the packets in flight have been dropped. As opposed > to beleiving that *some* packet in flight was dropped. I think this may not be a good idea. Look at an hypothetical example. If TCP used your notion, and a connection just sent a segment out every 0.5 RTO, then the timer would never fire even TCP did not get any acks at all! From a robustness point of view, I don't think this is a good practise. > Good to hear this. I've been looking at this on and off for a little > while now and was pretty convinced that there needed to be either a > min RTO or a min deviation. To my mind, the deviation term makes more > sense to impose a minimum on, because even on long paths I believe you > could still see the occasional spike in delay. I agree with this. This is what we did in Solaris 7. We put a minimum on the deviation. And that is why I suggest people to set tcp_rexmit_interval_extra in Solaris 2.6, instead of setting tcp_rexmit_interval_min. In 2.6, the smoothed deviation can go too low to be effective at all. And there is the 200ms delay ack timer which can be triggered after a long run of segments, when smoothed deviation can be much lower than 200ms. Thus I suggest the minimum should be at least 200ms. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu May 20 22:47:22 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08715 for ; Thu, 20 May 1999 22:47:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA25549 for tcp-impl-outgoing; Thu, 20 May 1999 20:12:05 -0400 (EDT) Received: from daffy.ee.lbl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA25545; Thu, 20 May 1999 20:12:02 -0400 (EDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id RAA04296; Thu, 20 May 1999 17:11:59 -0700 (PDT) Message-Id: <199905210011.RAA04296@daffy.ee.lbl.gov> To: mahdavi@novell.com Cc: tcp-impl@grc.nasa.gov, mallman@grc.nasa.gov Subject: Re: Retransmissions without explanation In-reply-to: Your message of 20 May 1999 14:28:05 PDT. Date: Thu, 20 May 1999 17:11:59 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Hmmm, I wonder if that statement holds in both senses: does doing all > of the extra measurements also not *improve* the quality of the RTO > computation? The surprising answer is No. In a nutshell, the reason is that there's no good RTO setting (no real sweet spot) - you're always trading off waiting longer vs. retransmitting unnecessarily. Related to this, another surprising finding is that an RTO timer that "adapts" by just using the first RTT measurement of a connection often does almost as well as those that attempt to track the RTT evolution. (Of course, in some circumstances that estimator will be disastrous.) But perhaps further discussion should be deferred until we put the paper on-line, which should be sometime tomorrow. Vern From owner-tcp-impl@lerc.nasa.gov Fri May 21 08:21:11 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26801 for ; Fri, 21 May 1999 08:21:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA06798 for tcp-impl-outgoing; Fri, 21 May 1999 04:15:43 -0400 (EDT) Received: from ptnt4ln.pensionstrust.smtp.co.uk (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA06792 for ; Fri, 21 May 1999 04:15:33 -0400 (EDT) Received: by PT_NT4_LN with Internet Mail Service (5.5.2448.0) id ; Fri, 21 May 1999 09:17:00 +0100 Message-ID: <990CE6A8D31FD2118BCE00A0245506C7339050@PT_NT1> From: Steve Nice To: "'tcp-impl@lerc.nasa.gov'" Subject: Performance Problems. Date: Fri, 21 May 1999 09:16:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEA362.4C72A2BA" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEA362.4C72A2BA Content-Type: text/plain This is my first email to this list, and I am not sure whether this list is for this kind of problem. I am not an expert, so I'm hoping the experts who do use this list can help me. I have a problem with an application running over a WAN. I have captured the packets for this. Looking at the trace I can see the delay. What I do not know is whether the server (HP) is waiting for an acknowledgement from the client or whether the server is slow producing the data. I have included an extract from the trace. You can see a few packets to and from the client and then a gap (packets filtered) before the packets start transmitting again. If anyone can help me, I am very grateful. If list is not for this sort of enquiry then I apologise for wasting your time. Thanks Steve Nice <> ------_=_NextPart_000_01BEA362.4C72A2BA Content-Type: text/plain; name="extract from trace.txt" Content-Disposition: attachment; filename="extract from trace.txt" Content-Transfer-Encoding: quoted-printable packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= =0A= ^^^^^^^^^^^^^^^^^^^^^^^^^^100 Mb/s LAN/9000 = Networking^^^^^^^^^^^^^^^^^^^^^^@#%=0A= Timestamp : Wed May 19 BST 1999 13:12:30.250509=0A= Process ID : [ICS] Subsystem : = LAN100=0A= User ID ( UID ) : -1 Trace Kind : PDU IN = TRACE=0A= Device ID : 1 Path ID : 8023=0A= Connection ID : 0=0A= Location : 00123=0A= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source : 00-10-7b-92-4e-a1 [I] [ ] =0A= Dest : 08-00-09-d8-70-d5 [I] [HP ] TRACED LEN: 60=0A= Date : Wed May 19 13:12:30.025050 BST 1999=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D IP Header (inbound -- [ICS]) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source: 199.0.76.81(C) Dest: 199.0.74.22(C)=0A= len: 40 ttl: 126 proto: 6 cksum: 0xc018 id: = 0x583f=0A= flags: NONE tos: 0x10 hdrlen: 20 offset: 0x0 optlen: 0 = =0A= -------------------------------- TCP Header = ----------------------------------=0A= sport: 675 --> dport: 2224 flags: ACK =0A= seq: 0x2a4b3 urp: 0x0 chksum: 0x79e9 data len: 0 = =0A= ack: 0x4c48f2f9 win: 0x2238 optlen: 0 =0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= =0A= ^^^^^^^^^^^^^^^^^^^^^^^^^^100 Mb/s LAN/9000 = Networking^^^^^^^^^^^^^^^^^^^^^^@#%=0A= Timestamp : Wed May 19 BST 1999 13:12:30.253282=0A= Process ID : [ICS] Subsystem : = LAN100=0A= User ID ( UID ) : -1 Trace Kind : PDU IN = TRACE=0A= Device ID : 1 Path ID : 8023=0A= Connection ID : 0=0A= Location : 00123=0A= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source : 00-10-7b-92-4e-a1 [I] [ ] =0A= Dest : 08-00-09-d8-70-d5 [I] [HP ] TRACED LEN: 60=0A= Date : Wed May 19 13:12:30.025328 BST 1999=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D IP Header (inbound -- [ICS]) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source: 199.0.76.81(C) Dest: 199.0.74.22(C)=0A= len: 40 ttl: 126 proto: 6 cksum: 0xbf18 id: = 0x593f=0A= flags: NONE tos: 0x10 hdrlen: 20 offset: 0x0 optlen: 0 = =0A= -------------------------------- TCP Header = ----------------------------------=0A= sport: 675 --> dport: 2224 flags: ACK =0A= seq: 0x2a4b3 urp: 0x0 chksum: 0x75b1 data len: 0 = =0A= ack: 0x4c48f731 win: 0x2238 optlen: 0 =0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= =0A= ^^^^^^^^^^^^^^^^^^^^^^^^^^100 Mb/s LAN/9000 = Networking^^^^^^^^^^^^^^^^^^^^^^@#%=0A= Timestamp : Wed May 19 BST 1999 13:12:30.417217=0A= Process ID : [ICS] Subsystem : = LAN100=0A= User ID ( UID ) : -1 Trace Kind : PDU IN = TRACE=0A= Device ID : 1 Path ID : 8023=0A= Connection ID : 0=0A= Location : 00123=0A= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source : 00-10-7b-92-4e-a1 [I] [ ] =0A= Dest : 08-00-09-d8-70-d5 [I] [HP ] TRACED LEN: 60=0A= Date : Wed May 19 13:12:30.041721 BST 1999=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D IP Header (inbound -- [ICS]) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source: 199.0.76.81(C) Dest: 199.0.74.22(C)=0A= len: 40 ttl: 126 proto: 6 cksum: 0xb618 id: = 0x623f=0A= flags: NONE tos: 0x10 hdrlen: 20 offset: 0x0 optlen: 0 = =0A= -------------------------------- TCP Header = ----------------------------------=0A= sport: 675 --> dport: 2224 flags: ACK =0A= seq: 0x2a4b3 urp: 0x0 chksum: 0x722d data len: 0 = =0A= ack: 0x4c48fab5 win: 0x2238 optlen: 0 =0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= =0A= ^^^^^^^^^^^^^^^^^^^^^^^^^^100 Mb/s LAN/9000 = Networking^^^^^^^^^^^^^^^^^^^^^^@#%=0A= Timestamp : Wed May 19 BST 1999 13:12:31.198627=0A= Process ID : [ICS] Subsystem : = LAN100=0A= User ID ( UID ) : -1 Trace Kind : PDU IN = TRACE=0A= Device ID : 1 Path ID : 8023=0A= Connection ID : 0=0A= Location : 00123=0A= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source : 00-10-7b-92-4e-a1 [I] [ ] =0A= Dest : 08-00-09-d8-70-d5 [I] [HP ] TRACED LEN: 138=0A= Date : Wed May 19 13:12:31.019862 BST 1999=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D IP Header (inbound -- [ICS]) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source: 199.0.76.81(C) Dest: 199.0.74.22(C)=0A= len: 124 ttl: 126 proto: 6 cksum: 0x83c4 id: = 0x943f=0A= flags: NONE tos: 0x10 hdrlen: 20 offset: 0x0 optlen: 0 = =0A= -------------------------------- TCP Header = ----------------------------------=0A= sport: 675 --> dport: 2224 flags: PUSH ACK =0A= seq: 0x2a4b3 urp: 0x0 chksum: 0x7d7a data len: 84 = =0A= ack: 0x4c48fab5 win: 0x2238 optlen: 0 =0A= -------------------------------- RPC Call = ------------------------------------=0A= trans id: 0xe2ca4e37 rpc version: 2 prog: 391434 version: 2 = proc: 12=0A= auth type: 4 auth length: 8 =0A= verf type: 4 verf length: 16=0A= -------------------------------- INGSQLD Call = --------------------------------=0A= 0: 00 00 00 01 00 00 00 2e 00 00 00 01 00 00 00 00 = ................=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= packet filtered out=0A= =0A= vvvvvvvvvvvvvvvvvvvvvvvvvv100 Mb/s LAN/9000 = Networkingvvvvvvvvvvvvvvvvvvvvvv@#%=0A= Timestamp : Wed May 19 BST 1999 13:12:31.207367=0A= Process ID : 14648 Subsystem : = LAN100=0A= User ID ( UID ) : 201 Trace Kind : PDU OUT = TRACE=0A= Device ID : 1 Path ID : 8023=0A= Connection ID : 0=0A= Location : 00123=0A= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source : 08-00-09-d8-70-d5 [I] [HP ] =0A= Dest : 00-10-7b-92-4e-a1 [I] [ ] TRACED LEN: 1520=0A= Date : Wed May 19 13:12:31.020736 BST 1999=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D IP Header (outbound -- pid: 14648) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source: 199.0.74.22(C) Dest: 199.0.76.81(C)=0A= len: 1500 ttl: 64 proto: 6 cksum: 0x4036 id: = 0xd07d=0A= flags: DF tos: 0x0 hdrlen: 20 offset: 0x0 optlen: 0 = =0A= -------------------------------- TCP Header = ----------------------------------=0A= sport: 2224 --> dport: 675 flags: ACK =0A= seq: 0x4c48fab5 urp: 0x0 chksum: 0x550b data len: 1460 = =0A= ack: 0x2a507 win: 0x8000 optlen: 0 =0A= -------------------------------- RPC Reply = -----------------------------------=0A= trans id: 0xe2ca4e37 Accepted verif type: 4 verif = length: 16=0A= -------------------------------- INGSQLD Reply = -------------------------------=0A= 0: 00 00 00 00 00 00 00 2e 00 00 00 0e 00 00 00 00 = ................=0A= 16: 00 00 57 b0 00 00 57 b0 00 00 57 b0 00 00 57 b0 = ..W...W...W...W.=0A= < printing suppressed for one or more repetitions of the previous line = >=0A= 96: 00 00 57 b0 00 00 58 54 00 00 58 54 00 00 58 b1 = ..W...XT..XT..X.=0A= 112: 00 00 58 b1 00 00 58 b1 00 00 58 b1 00 00 58 b1 = ..X...X...X...X.=0A= < printing suppressed for one or more repetitions of the previous line = >=0A= 192: 00 00 58 b1 00 00 58 b1 00 00 00 00 00 01 25 79 = ..X...X.......%y=0A= 208: 00 01 25 7e 00 01 25 7f 00 01 25 89 00 01 25 9b = ..%~..%...%...%.=0A= 224: 00 01 25 9c 00 01 26 28 00 01 32 e6 00 01 40 64 = ..%...&(..2...@d=0A= 240: 00 01 4c fe 00 01 4d 13 00 01 4d 19 00 01 4d 30 = ..L...M...M...M0=0A= 256: 00 01 4d 30 00 01 4d 33 00 01 4d 33 00 01 4d 34 = ..M0..M3..M3..M4=0A= 272: 00 01 4d 34 00 01 4d 35 00 01 4d 36 00 01 4d 36 = ..M4..M5..M6..M6=0A= 288: 00 01 4c fe 00 01 4c fe 00 00 bc 35 00 00 bc 36 = ..L...L....5...6=0A= 304: 00 00 bc 37 00 00 bc 38 00 00 bc 5c 00 00 bd 7a = ...7...8...\...z=0A= 320: 00 00 be 05 00 00 c8 04 00 00 ce 30 00 00 ce 31 = ...........0...1=0A= 336: 00 00 ce 32 00 00 ce 33 00 00 ce 34 00 00 ce 35 = ...2...3...4...5=0A= 352: 00 00 ce 36 00 00 ce 37 00 00 ce 48 00 00 ce 61 = ...6...7...H...a=0A= 368: 00 00 ce 62 00 00 cf 57 00 00 cf 66 00 00 cf 67 = ...b...W...f...g=0A= 384: 00 00 cf 69 00 00 00 00 00 01 23 bf 00 01 23 c0 = ...i......#...#.=0A= 400: 00 01 23 c1 00 01 23 be 00 01 23 bb 00 01 23 bc = ..#...#...#...#.=0A= 416: 00 01 23 bd 00 01 32 11 00 01 32 10 00 01 32 12 = ..#...2...2...2.=0A= 432: 00 01 32 09 00 01 32 0f 00 00 dd 74 00 01 32 0c = ..2...2....t..2.=0A= 448: 00 00 dd 80 00 01 32 0d 00 00 dd 8a 00 01 32 0e = ......2.......2.=0A= 464: 00 01 32 0a 00 00 dd 68 00 01 32 0b 00 01 27 73 = ..2....h..2...'s=0A= 480: 00 01 27 74 00 00 0e e5 00 00 0e e6 00 00 0e e7 = ..'t............=0A= 496: 00 00 0e e8 00 00 0e e4 00 00 0e e3 00 00 0e e1 = ................=0A= 512: 00 00 0e e2 00 00 0e ea 00 00 0e eb 00 00 0e ec = ................=0A= 528: 00 00 0e ed 00 00 0e ee 00 00 0e ef 00 00 0e f0 = ................=0A= 544: 00 00 0e f1 00 00 0e e0 00 00 0e de 00 00 0e df = ................=0A= 560: 00 00 0e f2 00 00 0e f3 00 00 0e f4 00 00 0e f6 = ................=0A= 576: 00 00 00 00 30 30 30 00 30 30 30 00 30 30 30 00 = ....000.000.000.=0A= 592: 30 30 30 00 30 30 30 00 30 30 30 00 30 30 30 00 = 000.000.000.000.=0A= < printing suppressed for one or more repetitions of the previous line = >=0A= 752: 30 30 30 00 30 30 30 00 30 30 30 00 00 00 00 00 = 000.000.000.....=0A= 768: 30 33 30 00 30 33 30 00 30 33 30 00 30 33 30 00 = 030.030.030.030.=0A= < printing suppressed for one or more repetitions of the previous line = >=0A= 944: 30 33 30 00 30 33 30 00 00 00 00 00 31 39 38 36 = 030.030.....1986=0A= 960: 2d 30 38 2d 31 39 20 30 30 3a 30 30 3a 30 30 00 -08-19 = 00:00:00.=0A= 976: 31 39 38 36 2d 30 35 2d 31 39 20 30 30 3a 30 30 1986-05-19 = 00:00=0A= 992: 3a 30 30 00 31 39 38 36 2d 30 32 2d 31 39 20 30 :00.1986-02-19 = 0=0A= 1008: 30 3a 30 30 3a 30 30 00 31 39 38 37 2d 30 31 2d = 0:00:00.1987-01-=0A= 1024: 31 39 20 30 30 3a 30 30 3a 30 30 00 31 39 38 37 19 = 00:00:00.1987=0A= 1040: 2d 30 38 2d 31 39 20 30 30 3a 30 30 3a 30 30 00 -08-19 = 00:00:00.=0A= 1056: 31 39 38 37 2d 30 35 2d 31 39 20 30 30 3a 30 30 1987-05-19 = 00:00=0A= 1072: 3a 30 30 00 31 39 38 37 2d 30 32 2d 31 39 20 30 :00.1987-02-19 = 0=0A= 1088: 30 3a 30 30 3a 30 30 00 31 39 38 35 2d 30 39 2d = 0:00:00.1985-09-=0A= 1104: 33 30 20 30 30 3a 30 30 3a 30 30 00 31 39 38 36 30 = 00:00:00.1986=0A= 1120: 2d 30 39 2d 33 30 20 30 30 3a 30 30 3a 30 30 00 -09-30 = 00:00:00.=0A= 1136: 31 39 39 38 2d 30 39 2d 33 30 20 30 30 3a 30 30 1998-09-30 = 00:00=0A= 1152: 3a 30 30 00 31 39 39 33 2d 30 39 2d 33 30 20 30 :00.1993-09-30 = 0=0A= 1168: 30 3a 30 30 3a 30 30 00 31 39 38 37 2d 30 39 2d = 0:00:00.1987-09-=0A= 1184: 33 30 20 30 30 3a 30 30 3a 30 30 00 31 39 39 30 30 = 00:00:00.1990=0A= 1200: 2d 31 30 2d 31 39 20 30 30 3a 30 30 3a 30 30 00 -10-19 = 00:00:00.=0A= 1216: 31 39 39 30 2d 30 39 2d 33 30 20 30 30 3a 30 30 1990-09-30 = 00:00=0A= 1232: 3a 30 30 00 31 39 38 39 2d 31 30 2d 31 39 20 30 :00.1989-10-19 = 0=0A= 1248: 30 3a 30 30 3a 30 30 00 31 39 38 39 2d 30 39 2d = 0:00:00.1989-09-=0A= 1264: 33 30 20 30 30 3a 30 30 3a 30 30 00 31 39 38 38 30 = 00:00:00.1988=0A= 1280: 2d 31 30 2d 31 39 20 30 30 3a 30 30 3a 30 30 00 -10-19 = 00:00:00.=0A= 1296: 31 39 38 38 2d 30 39 2d 33 30 20 30 30 3a 30 30 1988-09-30 = 00:00=0A= 1312: 3a 30 30 00 31 39 39 32 2d 30 39 2d 33 30 20 30 :00.1992-09-30 = 0=0A= 1328: 30 3a 30 30 3a 30 30 00 31 39 39 31 2d 31 30 2d = 0:00:00.1991-10-=0A= 1344: 31 39 20 30 30 3a 30 30 3a 30 30 00 31 39 39 31 19 = 00:00:00.1991=0A= 1360: 2d 30 39 2d 33 30 20 30 30 3a 30 30 3a 30 30 00 -09-30 = 00:00:00.=0A= 1376: 31 39 39 38 2d 30 39 2d 33 30 20 30 30 3a 30 30 1998-09-30 = 00:00=0A= 1392: 3a 30 30 00 31 39 39 38 2d 30 39 2d 33 30 20 30 :00.1998-09-30 = 0=0A= 1408: 30 3a 30 30 3a 30 30 00 -- -- -- -- -- -- -- -- = 0:00:00.........=0A= =0A= vvvvvvvvvvvvvvvvvvvvvvvvvv100 Mb/s LAN/9000 = Networkingvvvvvvvvvvvvvvvvvvvvvv@#%=0A= Timestamp : Wed May 19 BST 1999 13:12:31.207465=0A= Process ID : 14648 Subsystem : = LAN100=0A= User ID ( UID ) : 201 Trace Kind : PDU OUT = TRACE=0A= Device ID : 1 Path ID : 8023=0A= Connection ID : 0=0A= Location : 00123=0A= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ethernet = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source : 08-00-09-d8-70-d5 [I] [HP ] =0A= Dest : 00-10-7b-92-4e-a1 [I] [ ] TRACED LEN: 1520=0A= Date : Wed May 19 13:12:31.020746 BST 1999=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D IP Header (outbound -- pid: 14648) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= Source: 199.0.74.22(C) Dest: 199.0.76.81(C)=0A= len: 1500 ttl: 64 proto: 6 cksum: 0x4035 id: = 0xd07e=0A= flags: DF tos: 0x0 hdrlen: 20 offset: 0x0 optlen: 0 = =0A= -------------------------------- TCP Header = ----------------------------------=0A= sport: 2224 --> dport: 675 flags: ACK =0A= seq: 0x4c490069 urp: 0x0 chksum: 0x88d1 data len: 1460 = =0A= ack: 0x2a507 win: 0x8000 optlen: 0 =0A= -------------------------------- RPC Header = ---------------------------------- ------_=_NextPart_000_01BEA362.4C72A2BA-- From owner-tcp-impl@lerc.nasa.gov Fri May 21 17:15:41 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07677 for ; Fri, 21 May 1999 17:15:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA22912 for tcp-impl-outgoing; Fri, 21 May 1999 14:16:20 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA22900; Fri, 21 May 1999 14:16:14 -0400 (EDT) Received: from guns.lerc.nasa.gov by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA17415; Fri, 21 May 1999 14:16:13 -0400 (EDT) Message-Id: <199905211816.OAA17415@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: Vern Paxson , mahdavi@novell.com Subject: Re: Retransmissions without explanation Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Back in the Saddle Date: Fri, 21 May 1999 14:16:13 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk As Vern mentioned yesterday, we have recently put together a paper that may be of interest to folks on this list. The abstract and a pointer to the paper are attached below. Please let us know if you have any comments! allman --- Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. ACM SIGCOMM, September 1999. To appear. The more information about current network conditions available to a transport protocol, the more efficiently it can use the network to transfer its data. In networks such as the Internet, the transport protocol must often form its own estimates of network properties based on measurements performed by the connection endpoints. We consider two basic transport estimation problems: determining the setting of the retransmission timer (RTO) for a reliable protocol, and estimating the bandwidth available to a connection as it begins. We look at both of these problems in the context of TCP, using a large TCP measurement set [Pax97b] for trace-driven simulations. For RTO estimation, we evaluate a number of different algorithms, finding that the performance of the estimators is dominated by their minimum values, and to a lesser extent, the timer granularity, while being virtually unaffected by how often round-trip time measurements are made or the settings of the parameters in the exponentially-weighted moving average estimators commonly used. For bandwidth estimation, we explore techniques previously sketched in the literature [Hoe96,AD98] and find that in practice they perform less well than anticipated. We then develop a receiver-side algorithm that performs significantly better. From owner-tcp-impl@lerc.nasa.gov Fri May 21 17:15:44 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07688 for ; Fri, 21 May 1999 17:15:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA23831 for tcp-impl-outgoing; Fri, 21 May 1999 14:24:29 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA23812; Fri, 21 May 1999 14:24:25 -0400 (EDT) Received: from guns.lerc.nasa.gov by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA17590; Fri, 21 May 1999 14:24:25 -0400 (EDT) Message-Id: <199905211824.OAA17590@guns.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov Cc: "Vern Paxson" , mahdavi@novell.com From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: Retransmissions without explanation Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Back in the Saddle Date: Fri, 21 May 1999 14:24:24 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Sorry for the extra mail... I forgot to include a pointer to the paper... > Mark Allman, Vern Paxson. On Estimating End-to-End Network Path > Properties. ACM SIGCOMM, September 1999. To appear. http://roland.grc.nasa.gov/~mallman/papers/estimation.ps allman From owner-tcp-impl@lerc.nasa.gov Fri May 21 20:13:44 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09157 for ; Fri, 21 May 1999 20:13:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA09214 for tcp-impl-outgoing; Fri, 21 May 1999 17:33:24 -0400 (EDT) Received: from zephyr.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA09210 for ; Fri, 21 May 1999 17:33:18 -0400 (EDT) From: braden@ISI.EDU Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id OAA12742; Fri, 21 May 1999 14:33:15 -0700 (PDT) Date: Fri, 21 May 1999 14:33:14 -0700 Posted-Date: Fri, 21 May 1999 14:33:14 -0700 Message-Id: <199905212133.AA18729@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Fri, 21 May 1999 14:33:14 -0700 To: tcp-impl@grc.nasa.gov Subject: Re: Retransmissions without explanation Cc: braden@ISI.EDU Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk As I recall, Van's basic argument for making as many RTT measurements as possible was to defeat possible "aliasing" effects. Aliasing, as I understand it, refers to sampling a periodic signal using a sampling rate that is approximately a multiple of the period of the signal. This can clearly give completely bogus results. One sample per RTT could fall into that trap, since traffic effects might be periodic of the same order. Please correct me if I have misunderstood this. Bob Braden From owner-tcp-impl@lerc.nasa.gov Sat May 22 08:44:43 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28205 for ; Sat, 22 May 1999 08:44:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA24223 for tcp-impl-outgoing; Sat, 22 May 1999 05:45:04 -0400 (EDT) Received: from fly.cnuce.cnr.it (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA24219 for ; Sat, 22 May 1999 05:45:02 -0400 (EDT) Received: by fly.cnuce.cnr.it id m10l8Kx-001i1aC (Debian Smail-3.2.0.102 1998-Aug-2 #2); Sat, 22 May 1999 11:44:59 +0200 (CEST) Message-Id: Date: Sat, 22 May 1999 11:44:59 +0200 (CEST) From: Francesco Potorti` To: braden@ISI.EDU CC: tcp-impl@grc.nasa.gov In-reply-to: <199905212133.AA18729@gra.isi.edu> (braden@ISI.EDU) Subject: Re: Retransmissions without explanation Organization: CNUCE-CNR, Via S.Maria 36, Pisa - Italy +39-050-593211 References: <199905212133.AA18729@gra.isi.edu> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk As I recall, Van's basic argument for making as many RTT measurements as possible was to defeat possible "aliasing" effects. Aliasing, as I understand it, refers to sampling a periodic signal using a sampling rate that is approximately a multiple of the period of the signal. More precisely, a signal which is reconstructed by sampling has bogus features not found in the original signal (aliasing) if the sampling frequency is less than twice the highest frequency present in the sampled signal. -- Francesco Potort́ (researcher) Voice: +39-050-593 203 (op. 211) Computer Networks Group Fax: +39-050-904052 CNUCE-CNR, Via Santa Maria 36 Email: F.Potorti@cnuce.cnr.it 56126 Pisa - Italy Web: http://fly.cnuce.cnr.it/ From owner-tcp-impl@lerc.nasa.gov Sat May 22 08:54:00 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28204 for ; Sat, 22 May 1999 08:44:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA24327 for tcp-impl-outgoing; Sat, 22 May 1999 05:55:34 -0400 (EDT) Received: from netlab.snu.ac.kr (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA24323 for ; Sat, 22 May 1999 05:55:32 -0400 (EDT) Received: from netlab.snu.ac.kr ([147.46.116.86]) by netlab.snu.ac.kr (8.8.8/8.8.8) with ESMTP id TAA29118 for ; Sat, 22 May 1999 19:05:16 +0900 Message-ID: <37467F96.DF62037E@netlab.snu.ac.kr> Date: Sat, 22 May 1999 18:57:42 +0900 From: Joo Change-hee X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Retransmissions without explanation References: <199905212133.AA18729@gra.isi.edu> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit braden@ISI.EDU wrote: > As I recall, Van's basic argument for making as many RTT measurements > as possible was to defeat possible "aliasing" effects. Aliasing, as I > understand it, refers to sampling a periodic signal using a sampling > rate that is approximately a multiple of the period of the signal. > This can clearly give completely bogus results. One sample per RTT > could fall into that trap, since traffic effects might be periodic of > the same order. I don't think that a RTT measurement for one RTT is a simple periodic sampling but a filtered sampling. For a example, it does not contain RTT measurements after a packet drop until fast recovery ends. Because the RTT measurements has peak value during one RTT before a drop dectection, a measurement for one RTT has smaller value than every measurement for packets like timestamp option. As a result, TCP usually has a smaller timeout value with a measurement for one RTT. If TCP with timestamp option is used in a dedicated line, the sender's averaged RTT has a overshoot before its stable value at the end of slow-start period.TCP(slow-start)'s excessive probing packets makes the network queue overflow. But the averaged RTT of TCP without timestamp option usually doesnot has this overshoot. (If it has, it is smaller than that of TCP with timestamp option.) I show this measurement difference only in a simualtion, so it can be different in a real network. From owner-tcp-impl@lerc.nasa.gov Thu May 27 22:05:47 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07749 for ; Thu, 27 May 1999 22:05:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA05779 for tcp-impl-outgoing; Thu, 27 May 1999 19:02:07 -0400 (EDT) Received: from berserkly.bsdi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA05775 for ; Thu, 27 May 1999 19:02:04 -0400 (EDT) Received: from berserkly.bsdi.com (localhost.bsdi.com [127.0.0.1]) by berserkly.bsdi.com (8.9.0/8.9.0) with ESMTP id AAA20868 for ; Fri, 28 May 1999 00:59:05 +0200 (CEST) Message-Id: <199905272259.AAA20868@berserkly.bsdi.com> To: tcp-impl@grc.nasa.gov Subject: Comments on draft-ietf-tcpimpl-pmtud-01.txt From: Geert Jan de Groot Date: Fri, 28 May 1999 00:58:11 +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I would like to make a couple of comments on the Path MTU Discovery Problems draft, and perhaps have a little discussion on it. First, a quicky at the end of the document: >3.3. Determining MSS from PMTU ... > The MSS advertised at the start of a connection should be based on ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the MTU of the interfaces on the system. Some systems use PMTUD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > determined values to determine the MSS to advertise. > This results in an advertised MSS that is smaller than the largest > MTU the system can receive. I would like to change the marked sentence with: The MSS advertised at the start of a connection should be based on the largest MTU of all interfaces on the system. Rationale: assume a TCP connect happens over an ethernet interface. While the TCP session is alive, routing changes and the session is now routed over an FDDI interface. If mss would have been 1460 (ethernet), we would see micrograms on the FDDI interface unneccesary. I just want to make the original text more explicit, that's all. Then the real issue: >3.1. Black Hole Detection ... > Path MTU Discovery (PMTUD) works by sending out as large a packet > as possible, with the Don't Fragment (DF) bit set in the IP header. > If the packet is too large for a router to forward on to a particu- > lar link, the router must send an ICMP Destination Unreachable -- > Fragmentation Needed message to the source address. > > As was pointed out in [RFC1435], routers don't always do this cor- > rectly -- many routers fail to send the ICMP messages, for a vari- > ety of reasons ranging from kernel bugs to configuration problems. > Firewalls are often misconfigured to supress all ICMP messages. > > PMTUD, as documented in [RFC1191], fails when confronted with this > problem. The upper-layer protocol continues to try to send large > packets and, without the ICMP messages, never discovers that it > needs to reduce the size of those packets. Its packets are disap- > pearing into a PMTUD black hole. I would like to make things more explicit by adding another scenario, one that I'm seeing every few weeks, and which IMHO warrants either explicit mentioning in an RFC. This is a typical scenario: - Many ISP's now run with MTU~4470 in their cloud, also on serial lines to their customers; - An uncreasing number of webfarms apperently allow this large an MTU all the way to the web server; - Assume a typical customer of such an ISP, using a Cisco box with Cisco-HDLC framing (which apperently doesn't catch MTU mismatches). Customer has a cache box with ethernet (to the Cisco), and FDDI (to the internal network), and hence MSS = 4352 - 40 = 4312 bytes. - Note that the default MTU on Cisco serial lines is 1500 bytes. If the customer surfs to such a high-MTU site, we see the SYN exchange, the HTTP request gets sent, but data never arrives at the cache. Investigation reveals that large packets are sent on the serial line to the customer router, however because it's configured for smaller MTU, this packet overruns the input buffer, so the packet is dropped (and the giants error counter is bumped up). It is important to note that, since the packet is not received correctly, no ICMP message is sent, and therefore we have a blackhole scenario. In defense I must mention that if the ISP sets up the customer router, the serial line is configured with the correct MTU, however chances are that the customer sets up the router himself, the configuration is lost at an upgrade or otherwise. We see this kind of problem as a support case every few weeks; I have poked a bit around and there are numerous places where this potential problem currently exists (but is masked in practive by a 1500-MTU hop somewhere in the field). >Implications > This failure is especially difficult to debug, as pings and some > interactive TCP connections to the destination host work. Bulk > transfers fail with the first large packet and the connection even- > tually times out. Note however, that it is possible to diagnose this by pinging with large packets: from the customer, try to ping the Cisco, then ping with 32K packets. If this all succeeds, repeat both tests with the ISP end of the serial line. If the large packet ping test fails, you have the problem (though for completeness, the test should be run from both ends) > TCP should notice that the connection is timing out. After several > timeouts, TCP should attempt to send smaller packets, perhaps turn- > ing off the DF flag for each packet. If this succeeds, it should > continue to turn off PMTUD for the connection for some reasonable > period of time, after which it should probe again to try to deter- > mine if the path has changed. I am not sure if I agree with this. First, there is a huge performance impact; second, there is ambiguity between packets dropped because of MTU problems and packets dropped because of congestion. The side effect of the suggestion above is that congestion might lead to sending micrograms unneccesary. Second, this requires changes in the web server config, while it's the _client_ path that's broken. I see no big incentive for webserver maintainers to install this workaround if it becomes available. So, my questions are: - Is it appropiate to document the scenario above explicitely? - Should it be documented in a tcpimpl document (it's not a tcpimpl issue!) - I don't agree with the blackhole workaround, and believe it should not be recommended. Comments? Geert Jan From owner-tcp-impl@lerc.nasa.gov Fri May 28 00:08:22 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09690 for ; Fri, 28 May 1999 00:08:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA09563 for tcp-impl-outgoing; Thu, 27 May 1999 21:11:44 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA09559 for ; Thu, 27 May 1999 21:11:42 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id TAA24706 env-from ; Thu, 27 May 1999 19:11:31 -0600 (MDT) Date: Thu, 27 May 1999 19:11:31 -0600 (MDT) From: Vernon Schryver Message-Id: <199905280111.TAA24706@calcite.rhyolite.com> To: GeertJan.deGroot@bsdi.com, tcp-impl@grc.nasa.gov Subject: Re: Comments on draft-ietf-tcpimpl-pmtud-01.txt Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > To: tcp-impl@grc.nasa.gov > Subject: Comments on draft-ietf-tcpimpl-pmtud-01.txt > From: Geert Jan de Groot > >3.3. Determining MSS from PMTU > ... > > The MSS advertised at the start of a connection should be based on > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the MTU of the interfaces on the system. Some systems use PMTUD > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > determined values to determine the MSS to advertise. > > This results in an advertised MSS that is smaller than the largest > > MTU the system can receive. > > I would like to change the marked sentence with: > The MSS advertised at the start of a connection should be based on > the largest MTU of all interfaces on the system. > > Rationale: assume a TCP connect happens over an ethernet interface. > While the TCP session is alive, routing changes and the session is > now routed over an FDDI interface. If mss would have been 1460 (ethernet), > we would see micrograms on the FDDI interface unneccesary. > I just want to make the original text more explicit, that's all. > ... I disagree. In real life, the initial interface is almost always the only interface used during the life of a TCP connection. With the proposal, almost every TCP connection to a multi-homed host using and an interface with a smaller MTU would suffer the overhead PMTU probing throughout the life of the connection. That is because people generally try to arrange routing so that their big MTU interfaces are prefered. Since most TCP connections are local and high speed, the proposal would have eggregious effects on performance in the common case. The proposal would solve a rare problem at the cost of significant harm to the common case (Yes, of course, both rare and common modulo the rarity of mult-homed hosts). The better solution is to do what most people already do, and arrange to have uniform-MTU interfaces on a system, or arranging routing (e.g. by router discovery) to prefer routes though big-MTU interfaces. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Fri May 28 00:51:36 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09882 for ; Fri, 28 May 1999 00:51:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA11523 for tcp-impl-outgoing; Thu, 27 May 1999 22:20:52 -0400 (EDT) Received: from caliper.sjf.novell.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA11517 for ; Thu, 27 May 1999 22:20:50 -0400 (EDT) Received: (from kml@localhost) by caliper.sjf.novell.com (8.8.8/8.8.8) id TAA01113; Thu, 27 May 1999 19:19:54 -0700 (PDT) Message-Id: <199905280219.TAA01113@caliper.sjf.novell.com> To: Geert Jan de Groot cc: tcp-impl@grc.nasa.gov Subject: Re: Comments on draft-ietf-tcpimpl-pmtud-01.txt In-reply-to: Your message of "Fri, 28 May 1999 00:58:11 +0200." <199905272259.AAA20868@berserkly.bsdi.com> From: "Kevin Lahey" Date: Thu, 27 May 1999 19:19:54 -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In message <199905272259.AAA20868@berserkly.bsdi.com>Geert Jan de Groot writes > >> The MSS advertised at the start of a connection should be based on > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> the MTU of the interfaces on the system. Some systems use PMTUD > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I would like to change the marked sentence with: >The MSS advertised at the start of a connection should be based on >the largest MTU of all interfaces on the system. Right, that's what was suggested in RFC 1191. I changed NetBSD to work this way, and got my share of flack for it. I'd love to see every MSS advertised as 64KB; if there is ever a TCPng, I'd hope that MSS goes away. I had the impression that this was a contentious issue in the past; if no one objects, I'd be delighted to change it. >Then the real issue: >[Black Hole Detection] >I would like to make things more explicit by adding another scenario, >one that I'm seeing every few weeks, and which IMHO warrants either >explicit mentioning in an RFC. This is a typical scenario: I'd be happy to add it, especially if lots of folks are seeing it. Matt Mathis has mentioned similar scenarios. >> TCP should notice that the connection is timing out. After several >> timeouts, TCP should attempt to send smaller packets, perhaps turn- >> ing off the DF flag for each packet. If this succeeds, it should >> continue to turn off PMTUD for the connection for some reasonable >> period of time, after which it should probe again to try to deter- >> mine if the path has changed. > >I am not sure if I agree with this. First, there is a huge performance >impact; second, there is ambiguity between packets dropped because of >MTU problems and packets dropped because of congestion. The side effect >of the suggestion above is that congestion might lead to sending >micrograms unneccesary. It seemed like there was some consensus on this list that dealing with the ambiguity was worthwhile if it meant that packets would continue to flow. >Second, this requires changes in the web server config, while it's >the _client_ path that's broken. I see no big incentive for webserver >maintainers to install this workaround if it becomes available. Right, but the webserver maintainers are the ones who'd like the clients to be able to receive the packets, and are the folks who can do something about it. The client side can only suffer and wonder at the delay... >So, my questions are: >- Is it appropiate to document the scenario above explicitely? >- Should it be documented in a tcpimpl document (it's not a tcpimpl issue!) >- I don't agree with the blackhole workaround, and believe it should > not be recommended. I'm not sure about the real answers, but now you've at least heard my best guesses. Cheers, Kevin kml@novell.com From owner-tcp-impl@lerc.nasa.gov Fri May 28 03:47:58 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23480 for ; Fri, 28 May 1999 03:47:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA15220 for tcp-impl-outgoing; Fri, 28 May 1999 00:44:19 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA15216 for ; Fri, 28 May 1999 00:44:18 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id WAA00321 for tcp-impl@grc.nasa.gov env-from ; Thu, 27 May 1999 22:44:17 -0600 (MDT) Date: Thu, 27 May 1999 22:44:17 -0600 (MDT) From: Vernon Schryver Message-Id: <199905280444.WAA00321@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Comments on draft-ietf-tcpimpl-pmtud-01.txt Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk A universal 64K MSS? wow. Does no one else see the contradictions in simultaneously - proposing something that would significantly increase the use of PTMU Discovery and in cases where it is almost always a useless almost always a performance hit, - in a document that is largely concerned with problems in PMTU Discovery that have no pleasant solutions - and also arguing against one of the not entirely pleasing hacks to deal with PMTU Discovery problems but in favor of manual diagnostic techniques - while adding get another stanza to the litany of real life problems of PMTU Discovery. Perhaps I don't understand what's being said, but if I do, it seems to me people ought to step back and look at the whole picture before fomenting TCP standards changes. I think PMTU Discovery is a Good Thing(tm), but too much of a Good Thing(tm) is often a Bad Thing(tm). Vernon Schryver vjs@rhyolite.com