From owner-tcp-impl@cthulhu.engr.sgi.com Wed Oct 7 18:18:06 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA20219 for ; Wed, 7 Oct 1998 18:18:05 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA26502; Wed, 7 Oct 1998 15:15:26 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id PAA01994; Wed, 7 Oct 1998 15:17:03 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA08513; Wed, 7 Oct 1998 15:16:49 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA80911 for tcp-impl-list; Wed, 7 Oct 1998 15:08:16 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA43727 for ; Wed, 7 Oct 1998 15:08:14 -0700 (PDT) mail_from (ahughes@ISI.EDU) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA03616 for ; Wed, 7 Oct 1998 15:08:12 -0700 (PDT) mail_from (ahughes@ISI.EDU) Received: from ale.isi.edu (ale-e.isi.edu [128.9.160.90]) by venera.isi.edu (8.8.7/8.8.6) with SMTP id PAA20421 for ; Wed, 7 Oct 1998 15:08:10 -0700 (PDT) Message-ID: <361BE64C.42877E5C@isi.edu> Date: Wed, 07 Oct 1998 15:08:12 -0700 From: "Amy S. Hughes" X-Mailer: Mozilla 3.03Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: tcp-impl@cthulhu.engr.sgi.com Subject: tcp-impl archives? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Where can I find archives for the tcp-impl mailing list? The official one listed in the charter, ftp://ftp.sgi.com/other/tcp-impl/mail.archive only has posts upto April 1997. I need to look for some more recent than that. thanks, Amy S. Hughes From owner-tcp-impl@cthulhu.engr.sgi.com Wed Oct 7 19:03:11 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA20606 for ; Wed, 7 Oct 1998 19:03:10 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA07401; Wed, 7 Oct 1998 16:01:03 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA15372; Wed, 7 Oct 1998 16:02:39 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA08782; Wed, 7 Oct 1998 16:02:32 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA96015 for tcp-impl-list; Wed, 7 Oct 1998 15:58:06 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA20649 for ; Wed, 7 Oct 1998 15:58:04 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA05461 for ; Wed, 7 Oct 1998 15:58:03 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id PAA14371; Wed, 7 Oct 1998 15:58:02 -0700 (PDT) Message-Id: <199810072258.PAA14371@daffy.ee.lbl.gov> To: "Amy S. Hughes" Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: tcp-impl archives? In-reply-to: Your message of Wed, 07 Oct 1998 15:08:12 PDT. Date: Wed, 07 Oct 1998 15:58:02 PDT From: Vern Paxson Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk The word from the folks at SGI is that this is going to take some time to sort out. If you have a particular search string you want to send me, I'll see what I have in my private archive, it has 1,000+ tcp-impl messages in it. Vern From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 8 18:49:19 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA13974 for ; Thu, 8 Oct 1998 18:49:19 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA06762; Thu, 8 Oct 1998 15:46:27 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id PAA29623; Thu, 8 Oct 1998 15:48:05 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA02494; Thu, 8 Oct 1998 15:47:55 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA97921 for tcp-impl-list; Thu, 8 Oct 1998 15:39:37 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA38511 for ; Thu, 8 Oct 1998 15:39:35 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA05803 for ; Thu, 8 Oct 1998 15:39:35 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id PAA20057; Thu, 8 Oct 1998 15:39:29 -0700 (PDT) Message-Id: <199810082239.PAA20057@daffy.ee.lbl.gov> To: tcp-impl@cthulhu.engr.sgi.com Subject: draft minutes for Chicago meeting Cc: mallman@lerc.nasa.gov Date: Thu, 08 Oct 1998 15:39:28 PDT From: Vern Paxson Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Sorry these are so late ... Please send us comments over the next few days and then we'll finalize them. Vern TCPIMPL minutes 42nd IETF, Chicago August 28, 1998 Reported by Evi Nemeth, with editing by the chairs & Sally Floyd. Agenda: 1. Agenda bashing 2. Scott Bradner, intellectual property rights 3. Status 4. Known problems I-D 5. Security problems 6. RFC 2001 revision (congestion control) 7. WG closing after Orlando -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 1. Agenda bashing: No changes to the agenda. 2. IPR (intellectual property rights) issues: Scott Bradner reminded the group that if you know of intellectual property issues in your company on a topic and don't say so, then you cannot participate in the discussion and decisions regarding that topic. This is outlined in RFC 2028. 3. Status The testing tools document is done, RFC 2398. The larger initial window documents have been approved by IESG, and the 3 drafts will soon become RFCs. Regarding the restart of idle connections, see draft-ietf-tcpimpl-restart, which Joe Touch reports will soon be revised for publication. 4. Known problems 7 new ones have been documented since the LA meeting. Bill Fenner described a new bug: if during a bi-directional transfer you are sending and so is the other end, but you're not reading the incoming data very fast, you can end up deadlocked with a full buffer. For example, a multithreaded client-server where one thread is sending a lot, another is receiving a lot, but using one tcp connection. The fix is to change an unsigned to an int and recognize -1 as a valid value. Bill will explain it better and submit it. There are 3 others which are less serious and also not yet addressed. The document will be forwarded to the IESG without outlining these bugs. 5. Security problems There is a list of known problems: Predictable initial sequence number SYN flooding Land attack Phil Karn noted that the latter two are really denial of service attacks, and questioned the title of the section. 6. RFC 2001 revision High-level sketch of the revisions: - removed ambiguities - fixes for fast retransmit and fast recovery - added discussion of SACK - added larger initial window pointer The discussion of the 2001 revision was a little chaotic at this point and went back and forth between several topics. The comments about each topic have been grouped together for the minutes, and therefore the comments are somewhat out-of-order. Sally Floyd described two separate modifications to the Fast Retransmit and Fast Recovery algorithms in RFC 2001. The first modification is the NewReno algorithm, introduced in Janey Hoe's SIGCOMM 96 paper, which improves TCP's response to a "partial ack" received during Fast Recovery, acknowledging some but not all of the packets sent before Fast Recovery was initiated. The preferred TCP algorithms would be those of Sack TCP. However, when the SACK option is not available, the NewReno algorithm was described as a small but important change to make to Reno TCP, avoiding Reno TCP's well-documented problems with retransmit timeouts when multiple packets are dropped from a window of data. The second modification described was the bugfix algorithm for avoiding unnecessary multiple fast retransmits. This problem occurs in Reno when, after a retransmit timeout, packets are retransmitted that have already been received at the receiver. When the TCP sender receives three duplicate ACKs acknowledging three retransmitted packets, the sender can incorrectly interpret this as a new instance of congestion. Simulations showed that the NewReno algorighm and the bugfix for avoiding-multiple-fast-retransmits are orthogonal - it is possible to implement one and not the other. However, while it is possible to create scenarios with Reno or NewReno TCP where the bugfix for avoiding-multiple-fast-retransmits would be helpful, it is not possible to create the pathological scenarios that can occur with Tahoe TCP (e.g., TCP with Fast Retransmit but without Fast Recovery). Sally's slides can be found at: "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" (postscript), and "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf" (PDF). The chairs think that NewReno is a good thing; folks should implement it (solaris 2.6 might already) and put out an experimental RFC or include it (all or part) in 2001. The decision was made to take this discussion to the mailing list and do an experimental RFC with NewReno, rather than include it in the bugs list in RFC 2001. There was then discussion of whether to include Sally's Reno modification for avoiding-multiple-fast-retransmits in the RFC 2001 revision - how much experience with it do we need to include it? Vern suggested that an experimental document with Sally's modification could come out at the same time, and be referenced by 2001. Kacheong Poon (Sun) confirmed that some implementations of NewReno can behave like stop and go during retransmission (like in Janey Hoe's paper). This occurs when multiple packets are dropped from a window of data, and NewReno TCP recovers by retransmitting at most one dropped packet per roundtrip time. Sally said it is possible to implement NewReno with "stop and go" behavior, but that in an alternate implementation, included as an option in the NS simulator, the retransmit timer is reset on only the first retransmission. In this case, instead of slowly recovering by retransmitting at most one dropped packet per roundtrip time, eventually the retransmit timer times out and the sender slow-starts. The first-order fix for problems with multiple packets dropped from a window of data is to use Sack, but when Sack is not available, NewReno with this implementation should not perform worse than Reno. Sally and Kacheong Poon agreed to confer on different possible implementations of NewReno. Phil Karn asked if we want to make TCP more aggressive in the face of multiple packets dropped. Sally answered: multiple packets dropped in a window of data is one instance of congestion. So cut the window in half, do one retransmit; if retransmitted packets get lost, then it's more serious and do slow start. The RFC 2001 discussion continued with a discussion of ACKing every second full sized segment being a MUST and not a SHOULD. A wording tweak is needed: that ACKing is *at least* every second full-sized packet, since some systems ACK every segment, and that's allowed. Another issue arose concerning ACK every 2nd full sized segment -- there's no way for the receiver to really know if the segments arriving are full-sized. Resolution: loosen the language but word it so that today's TCPs are ok. A question regarding definition of 3 duplicate ACKs - must they be consecutive? Answer: yes, they need to be consecutive, but it's rare that they're not, so should not cause an implementation to be labeled non-conformant. 7. WG closing after Orlando 2001 is almost done if NewReno is not included. The plan is to close the working group after the next meeting (in Orlando). However, in discussion after adjournment, the issue was raised of documenting PMTU discovery issues, which may merit keeping the WG active for one more meeting. From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 13 19:17:30 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA04984 for ; Tue, 13 Oct 1998 19:17:29 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA28831; Tue, 13 Oct 1998 16:15:43 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA10731; Tue, 13 Oct 1998 16:17:25 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA01413; Tue, 13 Oct 1998 16:17:02 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA49052 for tcp-impl-list; Tue, 13 Oct 1998 16:10:15 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA33129 for ; Tue, 13 Oct 1998 16:10:14 -0700 (PDT) mail_from (floyd@owl.ee.lbl.gov) Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA03449 for ; Tue, 13 Oct 1998 16:10:13 -0700 (PDT) mail_from (floyd@owl.ee.lbl.gov) Received: (from floyd@localhost) by owl.ee.lbl.gov (8.9.1/8.9.1) id QAA22234; Tue, 13 Oct 1998 16:10:11 -0700 (PDT) Message-Id: <199810132310.QAA22234@owl.ee.lbl.gov> To: mallman@lerc.nasa.gov cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: NewReno and the 2001 Revision Date: Tue, 13 Oct 1998 16:10:11 PDT From: Sally Floyd Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > So, it seems to >me that the appropriate approach is to outline the general >principles that should guide the development of SACK-based >algorithms, in order to prevent such algorithms from hurting the >network and contributing to congestion collapse. However, it seems >less important to try to decide which SACK-based algorithm is the >best and standardize it (at least at this time). Actually, I would agree with this approach on a wide range of issues regarding TCP implementations, not just about SACK algorithms. I think it is important to make sure that TCP implementations follow such basic congestion control principles as slow-start, cutting the congestion control window in half in response to a packet drop or in response to Explicit Congestion Notification, etc. I also think it is important to list clear bugs such as those catalogued in the tcpimpl documents. However, I don't know of any reason why TCP responses have to be standardized in complete detail, even without considering SACK. There are a number of areas that it seems to me don't involve interoperability, dangers of congestion collapse, dangers of inexcuseably poor performance for the user, etc., and therefore could perfectly safely be left to the discretion of the implementor. I am going to try to write something up making this position more clear... - Sally From owner-tcp-impl@cthulhu.engr.sgi.com Sun Oct 18 23:47:30 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA14372 for ; Sun, 18 Oct 1998 23:47:28 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA01976; Sun, 18 Oct 1998 20:45:06 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA05335 for tcp-impl-list; Sun, 18 Oct 1998 20:34:43 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA97636 for ; Sun, 18 Oct 1998 20:34:42 -0700 (PDT) mail_from (motzartk626@hotmail.com) Received: from mars.mosby.com (mars.Mosby.COM [204.233.129.35]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA08210 for ; Sun, 18 Oct 1998 20:34:41 -0700 (PDT) mail_from (motzartk626@hotmail.com) From: motzartk626@hotmail.com Received: from default (1Cust197.tnt1.nyc3.da.uu.net [153.37.105.197]) by mars.mosby.com (8.9.1/8.9.1) with SMTP id WAA20272; Sun, 18 Oct 1998 22:34:24 -0500 (CDT) Date: Sun, 18 Oct 1998 22:34:24 -0500 (CDT) Message-Id: <199810190334.WAA20272@mars.mosby.com> To: motzartk626@hotmail.com Subject: FREE Equipment Buyers Guide... Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk ----------------------------------------------------------- "The Equipment Buyers Guide". Mpls. MN.55438. This message is sent in compliance of the new e-mail bill: SECTION301 Sender:EBG S.Wyoming#157 Mpls. MN .55438 Hours M-F 9-5 612.914.0494email:<> Section 301,Paragraph (a)(2)(C) of s. 618 ------------------------------------------------------------ Just released......... We invite you to try out the new "Equipment Buyers Guide Catalog" absolutely free! ================================================ This catalog is a beta version of the new buyers guide .It contains literally hundreds of business related products and services. We are distributing this free beta copy to test market the new format before we put it into mass production. We would simply appreciate your feedback on how you like it. To keep the test results as valid as possible, we are sending this only to people we believe have an interest in items such as rack, conveyor shelving, forklifts, office equipment and other kinds of material handling equipment.. ============================================= PLUS....A BONUS! . A special free gift for helping us test market the catalog. We'll send you a special URL to the hottest "Insiders Monthly Liquidation Web Site" on the net! This is insider information that will amaze co-workers. You'll find and buy deals that will have your competitors green with envy. It's really cool. ============================================= Here's all you need to do.. #1) Print out this registration form. #2) Fill in the appropriate mailing information #3) Fax to EBG test promo offer OC2-90K 10-17 at 1-320-485-4860. That's it! You're done. It only takes 30 seconds of your time. You'll receive your free info pack in 3 to 5 days. COMPANY:_______________________________________ NAME:__________________________________________ TITLE:__________________________________________ ADDRESS:_______________________________________ CITY:_______________STATE:________ZIP:____________ PHONE:______________________FAX:________________ E-MAIL ADDRESS:_________________________________________ MAIN BIZ ITEMS OF INTEREST? ________________________________________ Remove instructions: We have made every attempt to avoid mailing to those who do not qualify for or have interest in this offer. To be permanently removed from this and any future lists, send a reply to <> with REMOVE in the subject line. From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 20 12:29:36 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA24333 for ; Tue, 20 Oct 1998 12:29:35 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA02936; Tue, 20 Oct 1998 09:22:41 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA38244 for tcp-impl-list; Tue, 20 Oct 1998 09:14:47 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA38341 for ; Tue, 20 Oct 1998 09:14:45 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA03564 for ; Tue, 20 Oct 1998 09:14:44 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAAFD8 for ; Tue, 20 Oct 1998 09:14:42 -0700 Message-ID: <362CB6EB.17C81BBD@ehsco.com> Date: Tue, 20 Oct 1998 09:14:35 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@cthulhu.engr.sgi.com Subject: question about TCP checksums Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Hi, I hope this is the right place to ask this question. Various documents seem to be at odds with each other regarding the proper behavior for responding to a TCP segment that has an invalid checksum. Although STD 7 states that the segment should be discarded, it doesn't state what should happen next. Some material suggests that the recipient shouldn't do anything, waiting for the sender to timeout and retransmit. Conversely, other materials suggest sending an ACK for the last successfully-received segment. Either method would seem to work, with the benefit depending on the exact scenario. The question is: what's the position of the group as to which method is the enforcable STANDARD method? Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 20 12:34:42 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA24660 for ; Tue, 20 Oct 1998 12:34:41 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08002; Tue, 20 Oct 1998 09:32:33 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA43018 for tcp-impl-list; Tue, 20 Oct 1998 09:27:52 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA43231 for ; Tue, 20 Oct 1998 09:27:51 -0700 (PDT) mail_from (aron@cs.rice.edu) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA05285 for ; Tue, 20 Oct 1998 09:27:42 -0700 (PDT) mail_from (aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id LAA16495; Tue, 20 Oct 1998 11:27:39 -0500 (CDT) From: Mohit Aron Message-Id: <199810201627.LAA16495@cs.rice.edu> Subject: Re: question about TCP checksums To: ehall@ehsco.com (Eric A. Hall) Date: Tue, 20 Oct 1998 11:27:39 -0500 (CDT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <362CB6EB.17C81BBD@ehsco.com> from "Eric A. Hall" at Oct 20, 98 09:14:35 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > Various documents seem to be at odds with each other regarding the > proper behavior for responding to a TCP segment that has an invalid > checksum. Although STD 7 states that the segment should be discarded, it > doesn't state what should happen next. > > Some material suggests that the recipient shouldn't do anything, waiting > for the sender to timeout and retransmit. Conversely, other materials > suggest sending an ACK for the last successfully-received segment. > Either method would seem to work, with the benefit depending on the > exact scenario. > If the checksumming fails, then the recipient cannot be sure of which connection the TCP segment belongs to. The appropriate behavior then should be not to do anything. - Mohit Aron aron@cs.rice.edu From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 20 12:51:05 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA25594 for ; Tue, 20 Oct 1998 12:51:03 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04048; Tue, 20 Oct 1998 09:47:44 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA48057 for tcp-impl-list; Tue, 20 Oct 1998 09:43:14 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA46162 for ; Tue, 20 Oct 1998 09:43:12 -0700 (PDT) mail_from (dab@frantic.bsdi.com) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA07973 for ; Tue, 20 Oct 1998 09:43:11 -0700 (PDT) mail_from (dab@frantic.bsdi.com) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id LAA07555; Tue, 20 Oct 1998 11:42:58 -0500 (CDT) Date: Tue, 20 Oct 1998 11:42:58 -0500 (CDT) From: David Borman Message-Id: <199810201642.LAA07555@frantic.bsdi.com> To: ehall@ehsco.com, tcp-impl@cthulhu.engr.sgi.com Subject: Re: question about TCP checksums Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Date: Tue, 20 Oct 1998 09:14:35 -0700 > From: "Eric A. Hall" > Subject: question about TCP checksums > ... > Various documents seem to be at odds with each other regarding the > proper behavior for responding to a TCP segment that has an invalid > checksum. Although STD 7 states that the segment should be discarded, it > doesn't state what should happen next. Nothing, other than noting the fact in local statistics. > Some material suggests that the recipient shouldn't do anything, waiting > for the sender to timeout and retransmit. Conversely, other materials Yes. > suggest sending an ACK for the last successfully-received segment. > Either method would seem to work, with the benefit depending on the > exact scenario. The "other" scenario is wrong. Though you know that the IP source and destination addresses are correct (since they are part of the IP header, and IP would have tossed the packet if the IP checksum was bad), you don't know that the TCP source/destination ports are correct, because the TCP checksum is bad. Thus, you can't be 100% sure that you would even know who to send the ACK to. > The question is: what's the position of the group as to which method is > the enforcable STANDARD method? Silently drop the packet, since when you have a TCP checksum error you can't be 100% sure that you know for which connection the packet was destined. TCP will retransmit the dropped data. > Thanks > > -- > Eric A. Hall ehall@ehsco.com > +1-650-685-0557 http://www.ehsco.com -David Borman, dab@bsdi.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 04:26:22 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA16680 for ; Thu, 22 Oct 1998 04:26:21 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA00195; Thu, 22 Oct 1998 01:22:48 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id BAA73616 for tcp-impl-list; Thu, 22 Oct 1998 01:09:24 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id BAA29125 for ; Thu, 22 Oct 1998 01:09:22 -0700 (PDT) mail_from (esok@hyowon.cc.pusan.ac.kr) Received: from hyowon.cc.pusan.ac.kr (hyowon.cc.pusan.ac.kr [164.125.9.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA08627 for ; Thu, 22 Oct 1998 01:09:21 -0700 (PDT) mail_from (esok@hyowon.cc.pusan.ac.kr) Received: from iami ([164.125.69.18]) by hyowon.cc.pusan.ac.kr (8.8.8H1/8.8.8) with SMTP id RAA15892 for ; Thu, 22 Oct 1998 17:10:12 +0900 (KST) Message-ID: <000901bdfd93$3470f600$12457da4@iami.ce.pusan.ac.kr> From: "¿ÁÀ»¼®" To: Subject: add my E-mail to Mailing List Date: Thu, 22 Oct 1998 17:08:51 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BDFDDE.A4063840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BDFDDE.A4063840 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SSBhbSBhIHN0dWRlbnQgLi4uIGluIEtvcmVhLi4NCg0KcGxlYXplLi4NCg0KYWRkIG15IEUtbWFp bCB0byBNYWlsaW5nIExpc3QuLi4uDQoNCmVzb2tAaHlvd29uLmNjLnB1c2FuLmFjLmtyDQoNClRo YW5rcy4gaW4gYWR2YW5jZQ0KDQo= ------=_NextPart_000_0006_01BDFDDE.A4063840 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjIxMDYuMTEiJyBuYW1lPUdFTkVSQVRPUj4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZm Zj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgYW0gYSBzdHVkZW50IC4uLiBpbiBLb3JlYS4uPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+cGxlYXplLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hZGQgbXkgRS1tYWlsIHRvIE1haWxpbmcg TGlzdC4uLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48QSANCmhyZWY9Im1haWx0bzplc29rQGh5b3dvbi5jYy5w dXNhbi5hYy5rciI+ZXNva0BoeW93b24uY2MucHVzYW4uYWMua3I8L0E+PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ VGhhbmtzLiBpbiBhZHZhbmNlPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0006_01BDFDDE.A4063840-- From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 10:38:13 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20682 for ; Thu, 22 Oct 1998 10:38:12 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA08596; Thu, 22 Oct 1998 07:34:15 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA33921 for tcp-impl-list; Thu, 22 Oct 1998 07:27:30 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA33331 for ; Thu, 22 Oct 1998 07:27:28 -0700 (PDT) mail_from (ofersado@aquanet.co.il) Received: from main.aquanet.co.il (main.aquanet.co.il [192.117.240.10]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA09880 for ; Thu, 22 Oct 1998 07:27:24 -0700 (PDT) mail_from (ofersado@aquanet.co.il) From: ofersado@aquanet.co.il Received: from aquanet.co.il (unassigned.aquanet.co.il [192.117.250.12] (may be forged)) by main.aquanet.co.il (8.8.7/8.8.7) with SMTP id QAA30248; Thu, 22 Oct 1998 16:26:59 +0200 Date: Thu, 22 Oct 1998 16:26:59 +0200 Message-Id: <199810221426.QAA30248@main.aquanet.co.il> To: ofersado@aquanet.co.il Subject: Advertisig Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk We invite you to visit on the best xxx site on the net on http://192.117.250.10/ /////////////////////////////////////////////////////////////////////////////// If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. //////////////////////////////////////////////////////////////////////////////// We just want to notify you that this kind of e-mail is LEGAL even if you don't "like" it. From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 15:03:58 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA02215 for ; Thu, 22 Oct 1998 15:03:56 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09744; Thu, 22 Oct 1998 11:59:07 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA46969 for tcp-impl-list; Thu, 22 Oct 1998 11:48:01 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA44954; Thu, 22 Oct 1998 11:47:25 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02721; Thu, 22 Oct 1998 11:47:24 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA01101; Thu, 22 Oct 1998 11:47:22 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id LAA21538; Thu, 22 Oct 1998 11:47:21 -0700 (PDT) Date: Thu, 22 Oct 1998 11:47:21 -0700 (PDT) Message-Id: <199810221847.LAA21538@rum.isi.edu> To: tcp-impl@cthulhu.engr.sgi.com, rags@bapuji.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Cc: ahughes@ISI.EDU, touch@ISI.EDU, johnh@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From rags@bapuji.engr.sgi.com Thu Oct 22 11:37:39 1998 > From: rags@bapuji.engr.sgi.com (Raghu Mallena) > Subject: 'Slow-Start Restart after Idle' draft > To: tcp-impl@cthulhu.engr.sgi.com > Date: Thu, 22 Oct 1998 11:36:20 -0700 (PDT) > Cc: ahughes@ISI.EDU, touch@ISI.EDU, johnh@ISI.EDU, > rags@bapuji.engr.sgi.com (Raghu Mallena) > > > I have a couple of questions on draft-ietf-tcpimpl-restart-00.txt > (Issues in TCP Slow-Start Restart After Idle) and I was hoping > that either the authors(Amy Hughes, Joe Touch, John Hiedemann) > or someone else on the tcp-impl group who read it or implemented > it can clarify this for me. > > My main question is about the Congestion Window Monitoring (CWM) > solution proposed to avoid bursts. The draft talks about > replacing the following lines in tcp_output(): > > idle = (snd_max == snd_una); > if (idle && now - lastrcv >= rto) > cwnd = 1; > > with > maxwin = 4 + snd_nxt - snd_una; > if (cwnd > maxwin) > cwnd = maxwin; > > This proposal does burst control as expected, but I wanted to make > sure that it does not undercut the regular slow-start algorithm > during normal start up. It would be really bad if it did because > exponential window growth is highly desirable for high speed LAN > connections so that the stable max window size can be reached > as soon as possible. > > I took some traces and noticed that the initial slow-start behaviour > will not be compromised *if* Delayed Ack works as expected. ... > But what if Delayed Ack does not work as well and you start getting > one Ack for every N packets with N>2? That algorithm does not work well when ACKs are lost, or when 'delayed acks' is not correctly being followed (i.e., sending less ACKs is not correct behavior; receiving less ACKs may occur, however). > One reason I can think of why the smooth 2-for-1 Ack flow > might not happen is because of the way some of the BSD-derived > stacks are implemented. Have you seen this behavior, or is this a thought-experiment? > In Header Prediction mode, tcp_input() > routine does not call tcp_output() directly which means that > an ACK will not be sent out for the second packet immediately. > Instead, the input routine wakes up the socket and the > thread that wakes up then calls tcp_output() after removing > the data from the socket buffer. In the mean time, if there > were a bunch of other packets that came in, all of them are > ACKed *at once* in the output routine. 'delayed ACKS' would require that there were at least one ACK for every two full segments received correctly, regardless of what other data arrived in the meantime. This would result in an ACK burst. > Any comments? The fact that CWM can backfire if the > ACKs dont come in smoothly is quite subtle. Should the draft > talk about this dependence? Any real world experience from > implementors who have incorporated CWM into their stack? We have a modification in progress, which merges the best aspects of CWM and Floyd's Maxburst. It avoids the effect you observed above, where ACK losses cause CWM to reduce its window unnecessarily. However, it is also clear that most of the algorithms considered encourage interleaving of send and receive processing. Stalling that interleave generates bursts; these bursts are what we are trying to avoid, regardless of the reason. Joe From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 15:10:42 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA02413 for ; Thu, 22 Oct 1998 15:10:41 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA01957; Thu, 22 Oct 1998 12:04:47 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA40852 for tcp-impl-list; Thu, 22 Oct 1998 11:37:38 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from bapuji.engr.sgi.com (bapuji.engr.sgi.com [150.166.61.13]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA38668; Thu, 22 Oct 1998 11:37:35 -0700 (PDT) mail_from (rags@bapuji.engr.sgi.com) Received: (from rags@localhost) by bapuji.engr.sgi.com (980327.SGI.8.8.8/970903.SGI.AUTOCF) id LAA03945; Thu, 22 Oct 1998 11:36:20 -0700 (PDT) From: rags@bapuji.engr.sgi.com (Raghu Mallena) Message-Id: <199810221836.LAA03945@bapuji.engr.sgi.com> Subject: 'Slow-Start Restart after Idle' draft To: tcp-impl@cthulhu.engr.sgi.com Date: Thu, 22 Oct 1998 11:36:20 -0700 (PDT) Cc: ahughes@ISI.EDU, touch@ISI.EDU, johnh@ISI.EDU, rags@bapuji.engr.sgi.com (Raghu Mallena) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk I have a couple of questions on draft-ietf-tcpimpl-restart-00.txt (Issues in TCP Slow-Start Restart After Idle) and I was hoping that either the authors(Amy Hughes, Joe Touch, John Hiedemann) or someone else on the tcp-impl group who read it or implemented it can clarify this for me. My main question is about the Congestion Window Monitoring (CWM) solution proposed to avoid bursts. The draft talks about replacing the following lines in tcp_output(): idle = (snd_max == snd_una); if (idle && now - lastrcv >= rto) cwnd = 1; with maxwin = 4 + snd_nxt - snd_una; if (cwnd > maxwin) cwnd = maxwin; This proposal does burst control as expected, but I wanted to make sure that it does not undercut the regular slow-start algorithm during normal start up. It would be really bad if it did because exponential window growth is highly desirable for high speed LAN connections so that the stable max window size can be reached as soon as possible. I took some traces and noticed that the initial slow-start behaviour will not be compromised *if* Delayed Ack works as expected. i.e as long as we have an ACK coming in for every other packet sent out (or one ACK per every packet if Delayed Ack is disabled), then "maxwin" above is always more than "cwnd" (which is the cwnd computed using Slow Start when the last ACK came in) and we will still be in the exponential growth mode. This is because "snd_nxt - snd_una" roughly corresponds to "cwnd - 2" (2 comes from the fact that snd_una would have moved by 2 in tcp_input() when the last delayed ACK came in) and the comparison of 'cwnd > maxwin' always fails. But what if Delayed Ack does not work as well and you start getting one Ack for every N packets with N>2? In this case, the CWM proposal could lower the cwnd below the existing value and then slow start starts pushing it up again resulting in an osciallting behaviour. In a pathelogical case, you could get one ACK for all the outstanding unacknowledged packets which will make snd_una=snd_nxt and cwnd will now be set all the way down to 4 from whatever its current value is. One reason I can think of why the smooth 2-for-1 Ack flow might not happen is because of the way some of the BSD-derived stacks are implemented. In Header Prediction mode, tcp_input() routine does not call tcp_output() directly which means that an ACK will not be sent out for the second packet immediately. Instead, the input routine wakes up the socket and the thread that wakes up then calls tcp_output() after removing the data from the socket buffer. In the mean time, if there were a bunch of other packets that came in, all of them are ACKed *at once* in the output routine. This could happen quite often on high speed networks (even more so, if combined with a relatively slower cpu). Any comments? The fact that CWM can backfire if the ACKs dont come in smoothly is quite subtle. Should the draft talk about this dependence? Any real world experience from implementors who have incorporated CWM into their stack? Thanks Raghu From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 16:08:32 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA03935 for ; Thu, 22 Oct 1998 16:08:31 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05683; Thu, 22 Oct 1998 13:01:39 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA77275 for tcp-impl-list; Thu, 22 Oct 1998 12:54:48 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from bapuji.engr.sgi.com (bapuji.engr.sgi.com [150.166.61.13]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA61074; Thu, 22 Oct 1998 12:54:46 -0700 (PDT) mail_from (rags@bapuji.engr.sgi.com) Received: (from rags@localhost) by bapuji.engr.sgi.com (980327.SGI.8.8.8/970903.SGI.AUTOCF) id MAA04092; Thu, 22 Oct 1998 12:53:20 -0700 (PDT) From: rags@bapuji.engr.sgi.com (Raghu Mallena) Message-Id: <199810221953.MAA04092@bapuji.engr.sgi.com> Subject: Re: 'Slow-Start Restart after Idle' draft In-Reply-To: <199810221847.LAA21538@rum.isi.edu> from Joe Touch at "Oct 22, 98 11:47:21 am" To: touch@ISI.EDU (Joe Touch) Date: Thu, 22 Oct 1998 12:53:20 -0700 (PDT) Cc: tcp-impl@cthulhu.engr.sgi.com, ahughes@ISI.EDU, touch@ISI.EDU, johnh@ISI.EDU MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > > One reason I can think of why the smooth 2-for-1 Ack flow > > might not happen is because of the way some of the BSD-derived > > stacks are implemented. > > Have you seen this behavior, or is this a thought-experiment? Not a thought-experiment. I have seen this happen very often while working on Gigabit Ethernet driver and TCP/IP performance tuning over it. If I recollect correctly, some traces showed one ACK for about every 10 packets or so at times. This was with no packet loss of any sort. > > > In Header Prediction mode, tcp_input() > > routine does not call tcp_output() directly which means that > > an ACK will not be sent out for the second packet immediately. > > Instead, the input routine wakes up the socket and the > > thread that wakes up then calls tcp_output() after removing > > the data from the socket buffer. In the mean time, if there > > were a bunch of other packets that came in, all of them are > > ACKed *at once* in the output routine. > > 'delayed ACKS' would require that there were at least one ACK > for every two full segments received correctly, regardless of > what other data arrived in the meantime. This would result in > an ACK burst. Host Requirements RFC (rfc1122) that describes Delayed Ack says that "there SHOULD be an ACK for at least every second segment". Note that its a SHOULD and not a MUST. So its not really incorrect behaviour for stacks to send a single ACK for all the data received during the time the stack spends in processing the second segment. (i.e wake up the socket etc as I described above). I know atleast two stacks that do this and I wont be surprised if there are more. ( For reference, Steven's TCP/IP vol-II describes a similar scheme as well). > > > Any comments? The fact that CWM can backfire if the > > ACKs dont come in smoothly is quite subtle. Should the draft > > talk about this dependence? Any real world experience from > > implementors who have incorporated CWM into their stack? > > We have a modification in progress, which merges the best aspects > of CWM and Floyd's Maxburst. It avoids the effect you observed above, > where ACK losses cause CWM to reduce its window unnecessarily. > Cool! I will give it a shot when its ready. > However, it is also clear that most of the algorithms considered > encourage interleaving of send and receive processing. Stalling > that interleave generates bursts; these bursts are what we are trying > to avoid, regardless of the reason. > > Joe > I am not sure that what I described above can be considered a burst. Anyway, I just wanted to point out the dependency that CWM has on Delayed Ack implementations so the authors are aware of it incase this needs a mention in the draft. - raghu From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 16:14:57 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04070 for ; Thu, 22 Oct 1998 16:14:56 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA04808; Thu, 22 Oct 1998 13:10:19 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA73992 for tcp-impl-list; Thu, 22 Oct 1998 13:05:07 -0700 (PDT) mail_from (owner-tcp-impl@relay.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 NAA78931; Thu, 22 Oct 1998 13:05:06 -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 NAA01200; Thu, 22 Oct 1998 13:05:05 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810222005.NAA01200@bossette.engr.sgi.com> Subject: Re: 'Slow-Start Restart after Idle' draft To: touch@ISI.EDU (Joe Touch) Date: Thu, 22 Oct 1998 13:05:05 -0700 (PDT) Cc: tcp-impl@cthulhu.engr.sgi.com, rags@bapuji.engr.sgi.com, ahughes@ISI.EDU, touch@ISI.EDU, johnh@ISI.EDU In-Reply-To: <199810221847.LAA21538@rum.isi.edu> from "Joe Touch" at Oct 22, 98 11:47:21 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@cthulhu.engr.sgi.com Precedence: bulk Joe Touch wrote: > 'delayed ACKS' would require that there were at least one ACK > for every two full segments received correctly, regardless of > what other data arrived in the meantime. This would result in > an ACK burst. The way I read it RFC-1122 does not `require' this, but rather recommends it: A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 16:33:05 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04398 for ; Thu, 22 Oct 1998 16:33:04 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01073; Thu, 22 Oct 1998 13:29:12 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA83955 for tcp-impl-list; Thu, 22 Oct 1998 13:24:21 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA88344; Thu, 22 Oct 1998 13:24:08 -0700 (PDT) mail_from (mallman@guns.lerc.nasa.gov) Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08121; Thu, 22 Oct 1998 13:24:06 -0700 (PDT) mail_from (mallman@guns.lerc.nasa.gov) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by assateague.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA05307; Thu, 22 Oct 1998 16:24:00 -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 QAA05686; Thu, 22 Oct 1998 16:22:49 -0400 (EDT) Message-Id: <199810222022.QAA05686@guns.lerc.nasa.gov> To: rags@bapuji.engr.sgi.com (Raghu Mallena) From: Mark Allman Reply-To: mallman@lerc.nasa.gov cc: touch@ISI.EDU (Joe Touch), tcp-impl@cthulhu.engr.sgi.com, ahughes@ISI.EDU, johnh@ISI.EDU Subject: Re: 'Slow-Start Restart after Idle' draft Organization: Late Night Hackers, NASA LeRC, Cleveland, Ohio Song-of-the-Day: Nobody Told Me Date: Thu, 22 Oct 1998 16:22:48 -0400 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Host Requirements RFC (rfc1122) that describes Delayed Ack says > that "there SHOULD be an ACK for at least every second segment". > Note that its a SHOULD and not a MUST. Actually, I think it is a SHOULD in one place in 1122 and a MUST in another. In 2001.bis (draft-ietf-tcpimpl-cong-control-00.txt) we unambiguously say that you SHOULD implement delayed ACKs and if you do, you MUST ACK every second full-sized segment (with some hedges as far as what a full-sized segment is, per Matt Mathis comments to the list before the last IETF meeting). allman --- http://gigahertz.lerc.nasa.gov/~mallman/ From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 16:35:50 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04470 for ; Thu, 22 Oct 1998 16:35:49 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06128; Thu, 22 Oct 1998 13:29:12 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA85974 for tcp-impl-list; Thu, 22 Oct 1998 13:22:56 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA84488; Thu, 22 Oct 1998 13:22:40 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA07652; Thu, 22 Oct 1998 13:22:39 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA14734; Thu, 22 Oct 1998 13:22:38 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id NAA24143; Thu, 22 Oct 1998 13:22:36 -0700 (PDT) Date: Thu, 22 Oct 1998 13:22:36 -0700 (PDT) Message-Id: <199810222022.NAA24143@rum.isi.edu> To: touch@ISI.EDU, rags@bapuji.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Cc: tcp-impl@cthulhu.engr.sgi.com, ahughes@ISI.EDU, johnh@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From rags@bapuji.engr.sgi.com Thu Oct 22 12:54:49 1998 > From: rags@bapuji.engr.sgi.com (Raghu Mallena) > Subject: Re: 'Slow-Start Restart after Idle' draft > To: touch@ISI.EDU (Joe Touch) > Date: Thu, 22 Oct 1998 12:53:20 -0700 (PDT) > Cc: tcp-impl@cthulhu.engr.sgi.com, ahughes@ISI.EDU, touch@ISI.EDU, > johnh@ISI.EDU > > > > > > One reason I can think of why the smooth 2-for-1 Ack flow > > > might not happen is because of the way some of the BSD-derived > > > stacks are implemented. > > > > Have you seen this behavior, or is this a thought-experiment? > > Not a thought-experiment. I have seen this happen very often while > working on Gigabit Ethernet driver and TCP/IP performance > tuning over it. If I recollect correctly, some traces > showed one ACK for about every 10 packets or so at times. This > was with no packet loss of any sort. This might be an effect of the bundled-transmission of packets that gigabit ethernet uses. > > 'delayed ACKS' would require that there were at least one ACK > > for every two full segments received correctly, regardless of > > what other data arrived in the meantime. This would result in > > an ACK burst. > > Host Requirements RFC (rfc1122) that describes Delayed Ack says > that "there SHOULD be an ACK for at least every second segment". > Note that its a SHOULD and not a MUST. So its not really This is called "stretch ACK violation" in draft-ietf-tcpimpl-prob-04.txt, and there it's listed as a MUST. It appears that's a bug in the draft, unless it has been upgraded to a MUST elsewhere (??) Joe From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 17:02:49 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05034 for ; Thu, 22 Oct 1998 17:02:48 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA02327; Thu, 22 Oct 1998 13:55:24 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA98595 for tcp-impl-list; Thu, 22 Oct 1998 13:49:12 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA99409 for ; Thu, 22 Oct 1998 13:49:10 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06016 for ; Thu, 22 Oct 1998 13:49:09 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA11C6 for ; Thu, 22 Oct 1998 13:49:07 -0700 Message-ID: <362F9A25.EF45EF68@ehsco.com> Date: Thu, 22 Oct 1998 13:48:37 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810222022.QAA05686@guns.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk [Ignorant mode on.] > In 2001.bis (draft-ietf-tcpimpl-cong-control-00.txt) we unambiguously > say that you SHOULD implement delayed ACKs and if you do, you MUST > ACK every second full-sized segment My Caldera 1.3 system here sends one ACK for every seven segments, with no apparent loss in performance. I take it the benefit of frequent ACKs is most pronounced when timing is a problem. What is the benefit to increasing the ACK frequency if the timing is solid? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 17:12:20 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05289 for ; Thu, 22 Oct 1998 17:12:19 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA00948; Thu, 22 Oct 1998 14:06:52 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA69575 for tcp-impl-list; Thu, 22 Oct 1998 13:59:32 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA92138 for ; Thu, 22 Oct 1998 13:59:29 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA07112 for ; Thu, 22 Oct 1998 13:59:28 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA18755; Thu, 22 Oct 1998 13:59:26 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id NAA25053; Thu, 22 Oct 1998 13:59:24 -0700 (PDT) Date: Thu, 22 Oct 1998 13:59:24 -0700 (PDT) Message-Id: <199810222059.NAA25053@rum.isi.edu> To: tcp-impl@cthulhu.engr.sgi.com, ehall@ehsco.com Subject: Re: 'Slow-Start Restart after Idle' draft X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 13:53:24 1998 > Date: Thu, 22 Oct 1998 13:48:37 -0700 > From: "Eric A. Hall" > X-Accept-Language: en > To: tcp-impl@cthulhu.engr.sgi.com > Subject: Re: 'Slow-Start Restart after Idle' draft > > > [Ignorant mode on.] > > > In 2001.bis (draft-ietf-tcpimpl-cong-control-00.txt) we unambiguously > > say that you SHOULD implement delayed ACKs and if you do, you MUST > > ACK every second full-sized segment > > My Caldera 1.3 system here sends one ACK for every seven segments, with > no apparent loss in performance. > > I take it the benefit of frequent ACKs is most pronounced when timing is > a problem. What is the benefit to increasing the ACK frequency if the > timing is solid? ACK clocking is a pacing-like side-effect of producing ACKs on a consistent basis. Sending reduced numbers of ACKs can generate line-rate bursts, for the same reason as losing them, or allowing the window to accumulate 'rights to send' without using it. Joe From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 17:14:50 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05355 for ; Thu, 22 Oct 1998 17:14:49 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08970; Thu, 22 Oct 1998 14:09:15 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA05868 for tcp-impl-list; Thu, 22 Oct 1998 14:04:59 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA03259 for ; Thu, 22 Oct 1998 14:04:57 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA07239 for ; Thu, 22 Oct 1998 14:04:57 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA11CA for ; Thu, 22 Oct 1998 14:04:54 -0700 Message-ID: <362F9DD8.608E21FA@ehsco.com> Date: Thu, 22 Oct 1998 14:04:25 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810222059.NAA25053@rum.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Sending reduced numbers of ACKs can generate line-rate bursts, "Can" is the operative word here. This assumes that throughput or other factors will cause the processing cycles to get out-of-synch. But what if the network is running great? It seems that if the recipient can ACK every six or seven segments without the two end-points getting out of synch, it should be allowed to do so. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 17:28:48 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05604 for ; Thu, 22 Oct 1998 17:28:47 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA06623; Thu, 22 Oct 1998 14:23:05 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA90253 for tcp-impl-list; Thu, 22 Oct 1998 14:16:13 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA99791; Thu, 22 Oct 1998 14:16:00 -0700 (PDT) mail_from (sob@newdev.harvard.edu) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05893; Thu, 22 Oct 1998 14:15:59 -0700 (PDT) mail_from (sob@newdev.harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.8.8/8.8.5) id RAA15182; Thu, 22 Oct 1998 17:15:49 -0400 (EDT) Date: Thu, 22 Oct 1998 17:15:49 -0400 (EDT) From: Scott Bradner Message-Id: <199810222115.RAA15182@newdev.harvard.edu> To: rags@bapuji.engr.sgi.com, touch@ISI.EDU Subject: Re: 'Slow-Start Restart after Idle' draft Cc: ahughes@ISI.EDU, johnh@ISI.EDU, tcp-impl@cthulhu.engr.sgi.com Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > This might be an effect of the bundled-transmission of packets > that gigabit ethernet uses. Gigabit Ethernet only uses bundled-transmission if its running in half duplex mode (as far as I know) and there are few if any products that support halk-duplex gigabit Ethernet Scott From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 17:50:30 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05876 for ; Thu, 22 Oct 1998 17:50:29 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA09983; Thu, 22 Oct 1998 14:41:18 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA22481 for tcp-impl-list; Thu, 22 Oct 1998 14:34:02 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA20718 for ; Thu, 22 Oct 1998 14:34:00 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA06132 for ; Thu, 22 Oct 1998 14:33:56 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA11DE for ; Thu, 22 Oct 1998 14:33:47 -0700 Message-ID: <362FA49D.3F1C22B3@ehsco.com> Date: Thu, 22 Oct 1998 14:33:17 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810222059.NAA25053@rum.isi.edu> <362F9DD8.608E21FA@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > It seems that if the recipient can ACK every six or seven segments > without the two end-points getting out of synch, it should be allowed > to do so. It seems like the need for ACKs is a function of the RTT and the size of the receive buffer. ACKs should only be required if (a) the receive buffer is half it's normal capacity or (b) if the time required to deliver the ACK would cause the sender to stop transmitting before the ACK was received. Fixing the value to two seems kind of arbitrary. [Ignorant mode is still on, btw]. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 17:51:43 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05910 for ; Thu, 22 Oct 1998 17:51:41 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08155; Thu, 22 Oct 1998 14:41:18 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA15051 for tcp-impl-list; Thu, 22 Oct 1998 14:36:25 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA14066 for ; Thu, 22 Oct 1998 14:36:20 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA07077 for ; Thu, 22 Oct 1998 14:36:04 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id PAA14252 for tcp-impl@cthulhu.engr.sgi.com env-from ; Thu, 22 Oct 1998 15:36:00 -0600 (MDT) Date: Thu, 22 Oct 1998 15:36:00 -0600 (MDT) From: Vernon Schryver Message-Id: <199810222136.PAA14252@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk I doubt the intrinsic burstiness of Gbit Ethernet is responsible for the reduced ACKs reported here this morning. While the Ethernet driver might know that a bunch of IP packets arrived not merely during the servicing of a single interrupt but were a concatenated burst, the upper layers know only that a bunch of TCP segments arrived in a short time. Such things happen for many causes, including the system being busy dealing with other work. > From: Joe Touch > ... > Sending reduced numbers of ACKs can generate line-rate bursts, > ... Line-rate bursts can be bad, for example when you are talking to a LAN that is the first hop in a long and slow link. However, line-rate bursts are necessary, desirable, and inevitable on LANs if you want to approach the 100% utilization. That is obvious on token rings such as FDDI. If your system has not had the token for a while, it has received more than one Ack while it was waiting, and your system is not amone the lame and halt, then it will send a bunch of TCP segments in a burst at a somewhat more than 98 Mbit/sec. (The speed of light for TCP/IP/FDDI on a small ring with 4K segments and 2:1 segments:ACKs is 98 Mbit/sec of user data.) Between a pair of hosts on <= 100MHz Ethernet, similar effects exist, although they are perhaps less obvious. Ignoring those effects, and with BEB instead of BLAM, you really want line-rate bursts that are long but not too long, and you want to reduce the number of ACKs to about one per burst in order to avoid or minimize the effects of the Ethernet capture effect. Traffic that consists of alternating line-rate bursts of several dozen full sized segments in one direction and bursts of half that many ACKs in the other direction not only looks stupid on a monitor, but is measurably slower than the obvious alternative. Because of the line-rate burst facts of life on LANs, any standard that tries to outlaw line-rate bursts is hopeless in LANs, even if implementors do not choose to ignore it to improve the benchmark numbers that matter most. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 18:47:24 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07113 for ; Thu, 22 Oct 1998 18:47:23 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA04476; Thu, 22 Oct 1998 15:40:03 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA34688 for tcp-impl-list; Thu, 22 Oct 1998 15:30:11 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA45530 for ; Thu, 22 Oct 1998 15:30:09 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA01253 for ; Thu, 22 Oct 1998 15:30:05 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id PAA07979; Thu, 22 Oct 1998 15:29:59 -0700 (PDT) Message-Id: <199810222229.PAA07979@daffy.ee.lbl.gov> To: "Eric A. Hall" Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft In-reply-to: Your message of Thu, 22 Oct 1998 13:48:37 PDT. Date: Thu, 22 Oct 1998 15:29:58 PDT From: Vern Paxson Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > I take it the benefit of frequent ACKs is most pronounced when timing is > a problem. What is the benefit to increasing the ACK frequency if the > timing is solid? Along with the points Joe made, two other problems are that infrequent acks open the congestion window more slowly during slow start, and if acks are rare then if there's loss along the reverse path, connections are more likely to suffer from timeouts because they're starved for acks. Vern From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 19:04:13 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07383 for ; Thu, 22 Oct 1998 19:04:12 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA02735; Thu, 22 Oct 1998 15:58:22 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA54532 for tcp-impl-list; Thu, 22 Oct 1998 15:51:45 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA51343 for ; Thu, 22 Oct 1998 15:51:44 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA08127 for ; Thu, 22 Oct 1998 15:51:42 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA03022; Thu, 22 Oct 1998 15:51:39 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id PAA27887; Thu, 22 Oct 1998 15:51:39 -0700 (PDT) Date: Thu, 22 Oct 1998 15:51:39 -0700 (PDT) Message-Id: <199810222251.PAA27887@rum.isi.edu> To: tcp-impl@cthulhu.engr.sgi.com, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Date: Thu, 22 Oct 1998 15:36:00 -0600 (MDT) > From: Vernon Schryver > To: tcp-impl@cthulhu.engr.sgi.com > Subject: Re: 'Slow-Start Restart after Idle' draft > ... > > From: Joe Touch > > > ... > > Sending reduced numbers of ACKs can generate line-rate bursts, > > ... > > Line-rate bursts can be bad, for example when you are talking to a LAN > that is the first hop in a long and slow link. > > However, line-rate bursts are necessary, desirable, and inevitable on LANs > if you want to approach the 100% utilization. That is obvious on token ... The caveat is that these mechanisms, like slow-start restart, should be disabled on a LAN. We hadn't put that in the latest draft, but it is in the revision. It's the same check as slow-start - if the net prefixes match, ignore the code. Joe From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 19:12:24 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07534 for ; Thu, 22 Oct 1998 19:12:22 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA03795; Thu, 22 Oct 1998 16:06:04 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA52469 for tcp-impl-list; Thu, 22 Oct 1998 16:00:36 -0700 (PDT) mail_from (owner-tcp-impl@relay.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 QAA05018; Thu, 22 Oct 1998 16:00: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 QAA01993; Thu, 22 Oct 1998 16:00:31 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810222300.QAA01993@bossette.engr.sgi.com> Subject: Re: 'Slow-Start Restart after Idle' draft To: ehall@ehsco.com (Eric A. Hall) Date: Thu, 22 Oct 1998 16:00:31 -0700 (PDT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <362FA49D.3F1C22B3@ehsco.com> from "Eric A. Hall" at Oct 22, 98 02:33:17 pm 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@cthulhu.engr.sgi.com Precedence: bulk Eric A. Hall wrote: > > > > It seems that if the recipient can ACK every six or seven segments > > without the two end-points getting out of synch, it should be allowed > > to do so. > > It seems like the need for ACKs is a function of the RTT and the size of > the receive buffer. ACKs should only be required if (a) the receive > buffer is half it's normal capacity or (b) if the time required to > deliver the ACK would cause the sender to stop transmitting before the > ACK was received. > > Fixing the value to two seems kind of arbitrary. I beleive the reason for the value two is to avoid the situation where the rate at which the congestion window increase during slow-start and congestion avoidance is limited to one increment every 200ms (i.e. when the delayed-ack timer expires). If we don't force acks and simply rely on the delayed-ack timer then we can see very serious performance degradation during slow-start. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 19:29:01 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07742 for ; Thu, 22 Oct 1998 19:29:00 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06720; Thu, 22 Oct 1998 16:21:33 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA64446 for tcp-impl-list; Thu, 22 Oct 1998 16:13:16 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA27502 for ; Thu, 22 Oct 1998 16:13:14 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA07413 for ; Thu, 22 Oct 1998 16:13:12 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id RAA14541 for tcp-impl@cthulhu.engr.sgi.com env-from ; Thu, 22 Oct 1998 17:13:11 -0600 (MDT) Date: Thu, 22 Oct 1998 17:13:11 -0600 (MDT) From: Vernon Schryver Message-Id: <199810222313.RAA14541@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Joe Touch > ... > > However, line-rate bursts are necessary, desirable, and inevitable on LANs > > if you want to approach the 100% utilization. That is obvious on token > ... > > The caveat is that these mechanisms, like slow-start restart, > should be disabled on a LAN. We hadn't put that in the latest > draft, but it is in the revision. It's the same check as slow-start - > if the net prefixes match, ignore the code. That's a big improvement and I wish it were enough. I don't think it is. A pair of hosts can tell only that they are on the same IP network by looking at prefixes, and cannot even get that right with some flavors of variable length subnet masking. If they assume there are no boxes acting as forwarders between them and turn off the usual mechanisms, then they might be right and they might be wrong. Consider the literally millions of hosts that are either bridged over very slow links (e.g. ISDN TA's) or that have intentionally bogus network masks and rely on prox-ARP or other hacks at the "PPP server" side of a modem or ISDN PPP link. Those cases need slow-start more than many others on the Internet, and probably more than most of the tests rigs in which such things are tested, but their network prefixes will tell them to turn off slow-start when talking to hosts (e.g. DNS, NNTP, and email servers) at their ISP. Then consider a pair of hosts that are on different <=100 Mbit/sec LANs, but where the LANs are interconnected with fast mechanisms of one sort or another (>= 100 Mbps, e.g. ATM, short-haul SONET, FC, or HIPPI), and where they should be in fast-break-the-rules mode. There needs to be a test that detects a super fast, almost zero delay, practically zero loss link between a pair of hosts to turn off slow-start etc., but I think those examples show that network prefixesis not good enough. Instead of matching network prefixes, why not look at the RTT? Regardless of prefixes, if the RTT is less than 10 milliseconds, it's probably a good idea enter go-fast mode. If the RTT is more than 10 ms, go-fast mode won't gain anything and slow-start is a good idea, again regardless of prefixes. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 19:29:45 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07759 for ; Thu, 22 Oct 1998 19:29:44 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA03953; Thu, 22 Oct 1998 16:25:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA57067 for tcp-impl-list; Thu, 22 Oct 1998 16:18:49 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA36677 for ; Thu, 22 Oct 1998 16:18:47 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA05471 for ; Thu, 22 Oct 1998 16:18:46 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA120B for ; Thu, 22 Oct 1998 16:18:41 -0700 Message-ID: <362FBD32.2330FFD8@ehsco.com> Date: Thu, 22 Oct 1998 16:18:11 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810222300.QAA01993@bossette.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > I beleive the reason for the value two is to avoid the situation where > the rate at which the congestion window increase during slow-start My comments are in regard to post-start. IE, once slow-start has brought the two end-points up to full throttle. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 19:30:47 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07822 for ; Thu, 22 Oct 1998 19:30:46 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA05935; Thu, 22 Oct 1998 16:25:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA68828 for tcp-impl-list; Thu, 22 Oct 1998 16:20:24 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA69595 for ; Thu, 22 Oct 1998 16:20:23 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA08908 for ; Thu, 22 Oct 1998 16:20:19 -0700 (PDT) mail_from (kaos@ocs.com.au) Received: (qmail 5411 invoked by uid 502); 22 Oct 1998 23:20:15 -0000 Message-ID: <19981022232015.5410.qmail@mail.ocs.com.au> Received: (qmail 5405 invoked from network); 22 Oct 1998 23:20:14 -0000 Received: from router-6.ocs.com.au (HELO ocs4.ocs-net) (203.34.97.6) by mail.ocs.com.au with SMTP; 22 Oct 1998 23:20:14 -0000 From: Keith Owens To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft In-reply-to: Your message of "Thu, 22 Oct 1998 15:51:39 MST." <199810222251.PAA27887@rum.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Oct 1998 09:20:13 +1000 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk On Thu, 22 Oct 1998 15:51:39 -0700 (PDT), Joe Touch wrote: >[ACK-burst stuff] >The caveat is that these mechanisms, like slow-start restart, >should be disabled on a LAN. We hadn't put that in the latest >draft, but it is in the revision. It's the same check as slow-start - >if the net prefixes match, ignore the code. Not having seen the revision yet, what happens if the "LAN" has stubs behind slower links that are reached using proxy ARP? Network prefixes will match, turn off all the congestion mechanisms and overload the slow links. Of course we could break our nice flat backbone into lots of subnets and reprogram all the desktop configurations ... From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 21:16:47 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA09127 for ; Thu, 22 Oct 1998 21:16:46 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA08729; Thu, 22 Oct 1998 18:12:28 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA13638 for tcp-impl-list; Thu, 22 Oct 1998 18:05:33 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA05298 for ; Thu, 22 Oct 1998 18:05:31 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA09351 for ; Thu, 22 Oct 1998 18:05:29 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA14432; Thu, 22 Oct 1998 18:05:28 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id SAA28479; Thu, 22 Oct 1998 18:05:27 -0700 (PDT) Date: Thu, 22 Oct 1998 18:05:27 -0700 (PDT) Message-Id: <199810230105.SAA28479@rum.isi.edu> To: kaos@ocs.com.au, tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Cc: touch@ISI.EDU Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk I agree that there is a problem with intra-LAN links, and the detection thereof. Whatever that solution, it should be applied equally to avoiding slow-start and slow-start restart. The current code makes an assumption, that the network address indicates intra-LAN if it coincides with an existing interface address. That assumption generates false positives and negatives. Can anyone suggest a general solution? (in the meantime, I'd consider the "is_local" a placeholder for a more correct function - and otherwise not address it separately in the slow-start-restart doc...) Joe From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 22 21:47:14 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA09321 for ; Thu, 22 Oct 1998 21:47:13 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA04235; Thu, 22 Oct 1998 18:42:33 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA23532 for tcp-impl-list; Thu, 22 Oct 1998 18:35:54 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA14028 for ; Thu, 22 Oct 1998 18:35:52 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA00336 for ; Thu, 22 Oct 1998 18:35:51 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id TAA14971 for tcp-impl@cthulhu.engr.sgi.com env-from ; Thu, 22 Oct 1998 19:35:50 -0600 (MDT) Date: Thu, 22 Oct 1998 19:35:50 -0600 (MDT) From: Vernon Schryver Message-Id: <199810230135.TAA14971@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Joe Touch > I agree that there is a problem with intra-LAN links, and > the detection thereof. > > Whatever that solution, it should be applied equally to > avoiding slow-start and slow-start restart. > > The current code makes an assumption, that the network > address indicates intra-LAN if it coincides with an > existing interface address. That assumption generates false > positives and negatives. > > Can anyone suggest a general solution? > ... What about what I just said? You want to avoid slow-start and slow-restart and relax the 2:1 segment:ACK ratio exactly when the hosts are close to each other, which to say, when the RTT is small. 10 milliseconds is about the right dividing line, since round trips on reasonable LANs are less than 10 ms, and any long haul link with an RTT of less than 10 is forced by the speed of light to be fast and short enough to treat like a LAN. The only problem with using the measured RTT to know when to drop fancy stuff is that a new TCP connection does not know it immediately. To fix that, use the mechanisms that have been suggested for priming the RTT on long haul lines. Cache it however you cache the discovered path MTU. You might use the round trip time on the 3-way handshake instead of the smoothed RTT. Hosts that should start with slow-start off are likely to receive the SYN-ACK within 10 ms of sending the SYN, and the first data within 10 ms of sending the SYN-ACK. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 01:06:54 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA18754 for ; Fri, 23 Oct 1998 01:06:53 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA04047; Thu, 22 Oct 1998 22:03:29 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id VAA33781 for tcp-impl-list; Thu, 22 Oct 1998 21:57:06 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA62025 for ; Thu, 22 Oct 1998 21:57:05 -0700 (PDT) mail_from (luigi@labinfo.iet.unipi.it) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id VAA07226 for ; Thu, 22 Oct 1998 21:57:03 -0700 (PDT) mail_from (luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id EAA13915; Fri, 23 Oct 1998 04:01:03 +0100 From: Luigi Rizzo Message-Id: <199810230301.EAA13915@labinfo.iet.unipi.it> Subject: Re: 'Slow-Start Restart after Idle' draft To: touch@ISI.EDU (Joe Touch) Date: Fri, 23 Oct 1998 04:01:02 +0100 (MET) Cc: tcp-impl@cthulhu.engr.sgi.com, vjs@calcite.rhyolite.com In-Reply-To: <199810222251.PAA27887@rum.isi.edu> from "Joe Touch" at Oct 22, 98 03:51:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > Line-rate bursts can be bad, for example when you are talking to a LAN > > that is the first hop in a long and slow link. > > > > However, line-rate bursts are necessary, desirable, and inevitable on LANs > > if you want to approach the 100% utilization. That is obvious on token > ... > > The caveat is that these mechanisms, like slow-start restart, > should be disabled on a LAN. We hadn't put that in the latest > draft, but it is in the revision. It's the same check as slow-start - > if the net prefixes match, ignore the code. FreeBSD does this as a side effect of the introduction of TTCP, but this is very bad (and i recently introduced a sysctl variable to control this behaviour) because in many cases the address block is further segmented downstream and the sender is unaware of that. Think of a machine acting as a ppp server by allocating addresses from the same range as the primary interface and doing proxy arp. in my opinion, just checking netmasks is very prone to failute and ignoring slowstart should be explicitly configured if desired. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 04:10:53 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA20378 for ; Fri, 23 Oct 1998 04:10:52 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA09753; Fri, 23 Oct 1998 01:06:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id AAA38586 for tcp-impl-list; Fri, 23 Oct 1998 00:56:37 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id AAA92749 for ; Fri, 23 Oct 1998 00:56:34 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA08064 for ; Fri, 23 Oct 1998 00:56:31 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id AAA05891; Fri, 23 Oct 1998 00:56:26 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id AAA28828; Fri, 23 Oct 1998 00:56:25 -0700 (PDT) Date: Fri, 23 Oct 1998 00:56:25 -0700 (PDT) Message-Id: <199810230756.AAA28828@rum.isi.edu> To: tcp-impl@cthulhu.engr.sgi.com, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Vernon Schryver > To: tcp-impl@cthulhu.engr.sgi.com > Subject: Re: 'Slow-Start Restart after Idle' draft > > > From: Joe Touch ... > > Can anyone suggest a general solution? ... > What about what I just said? > > You want to avoid slow-start and slow-restart and relax the 2:1 > segment:ACK ratio exactly when the hosts are close to each other, > which to say, when the RTT is small. RTT may be correlated (it is debatable how closely); hopcount is much more meaningful. If you can get there in 0 hops, then there is no router, and you shouldn't be doing these tricks. That would require a traceroute-like test, out-of-band to the regular TCP packets. Closeness is not an issue - if I have a direct satellite link, the RTT can be 500 ms but I still want to do the bursting, since there is no router to overload. Joe From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 06:46:44 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA21369 for ; Fri, 23 Oct 1998 06:46:43 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA08257; Fri, 23 Oct 1998 03:42:34 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id DAA84962 for tcp-impl-list; Fri, 23 Oct 1998 03:29:40 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id DAA83853 for ; Fri, 23 Oct 1998 03:29:38 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: from sean.ebone.net (sean.ebone.net [130.228.11.231]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA02368 for ; Fri, 23 Oct 1998 03:29:36 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: (from smd@localhost) by sean.ebone.net (8.8.8/8.8.5) id MAA23878; Fri, 23 Oct 1998 12:29:34 +0200 (CEST) Date: Fri, 23 Oct 1998 12:29:34 +0200 (CEST) From: Sean Doran Message-Id: <199810231029.MAA23878@sean.ebone.net> To: tcp-impl@cthulhu.engr.sgi.com, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Vernon Schryver wrote: | A pair of hosts can tell only that they are on the same IP network by | looking at prefixes, and cannot even get that right with some flavors of | variable length subnet masking. Well, yes and no: ARP or ES-IS usually breaks when there is a serious mask mismatch. The bigger concern is LISes which are bridged. Unfortunately, there is stuff like that out in the world, and so making assumptions based only on the IP address seems pretty dangerous. One might also consider the case where a large server is on the "outside" of a NAT, and is sending data to a host on the "inside" (where, for example, it has an RFC-1918 address). If the server and the NAT are in the same LIS (or on the same LAN) then disabling congestion-avoidance mechanisms on the assumption that no non-local infrastructure will be involved is a mistake, despite the fact that the receiver address, from the perspective of the "outside" server, is the NAT itself. Finally, as Vernon notes, even where a LAN really is a LAN and retransmissions are cheap, it seems fair to wonder if it's smart to dump traffic into them in an non-congestion-avoiding way for the sake of performance. After all, the medium may be shared by other users, and they may see a performance decrease as the result of traffic being blasted into the LAN. | There needs to be a test that detects a super fast, almost zero delay, | practically zero loss link between a pair of hosts to turn off slow-start | etc., but I think those examples show that network prefixesis not good | enough. The only thing that seems to make sense would be recent observations of performance between the two things that may be super-fast-losslessly- connected to each other. Sean. From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 07:19:59 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA21846 for ; Fri, 23 Oct 1998 07:19:59 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA06188; Fri, 23 Oct 1998 04:14:00 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id EAA91696 for tcp-impl-list; Fri, 23 Oct 1998 04:03:05 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id EAA90738 for ; Fri, 23 Oct 1998 04:03:03 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: from sean.ebone.net (sean.ebone.net [130.228.11.231]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA02472 for ; Fri, 23 Oct 1998 04:03:01 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: (from smd@localhost) by sean.ebone.net (8.8.8/8.8.5) id NAA23937; Fri, 23 Oct 1998 13:03:00 +0200 (CEST) Date: Fri, 23 Oct 1998 13:03:00 +0200 (CEST) From: Sean Doran Message-Id: <199810231103.NAA23937@sean.ebone.net> To: tcp-impl@cthulhu.engr.sgi.com, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Vernon Schryver wrote: | Instead of matching network prefixes, why not look at the RTT? Regardless | of prefixes, if the RTT is less than 10 milliseconds, it's probably a good | idea enter go-fast mode. If the RTT is more than 10 ms, go-fast mode | won't gain anything and slow-start is a good idea, again regardless of | prefixes. At which point do you take the RTT measurement? Obviously, you also want to rapidly transition into normal mode the moment you detect any increase in RTT or the moment you see loss. Hopefully, if there's a mistake and a bunch of congestion is created by an assumption that it might be safe to be in go-fast mode, it will remain local and on cheap infrastructure and won't interfere too badly with other traffic. Maybe I'm a little too conservative, but 10ms seems pretty long to me. I can get well past the border and beyond Tele2's router in Malmö Sweden in less time than that, queues willing (which is thankfully fairly often). Fast hosts blasting traffic to there would be very painful. Sean. From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 07:39:46 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA22243 for ; Fri, 23 Oct 1998 07:39:45 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA09359; Fri, 23 Oct 1998 04:35:59 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id EAA86984 for tcp-impl-list; Fri, 23 Oct 1998 04:25:37 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id EAA43523 for ; Fri, 23 Oct 1998 04:25:34 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: from sean.ebone.net (sean.ebone.net [130.228.11.231]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA08827 for ; Fri, 23 Oct 1998 04:25:32 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: (from smd@localhost) by sean.ebone.net (8.8.8/8.8.5) id NAA24010; Fri, 23 Oct 1998 13:25:31 +0200 (CEST) Date: Fri, 23 Oct 1998 13:25:31 +0200 (CEST) From: Sean Doran Message-Id: <199810231125.NAA24010@sean.ebone.net> To: tcp-impl@cthulhu.engr.sgi.com, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Vernon Schryver wrote: | 10 milliseconds is about the right dividing line, since round trips | on reasonable LANs are less than 10 ms, and any long haul link with | an RTT of less than 10 is forced by the speed of light to be fast | and short enough to treat like a LAN. You have to explain this one to me. Bear in mind that some links are quiescent most of the time. Bear in mind also that mileage charges are meaningless when a border is being crossed. A circuit crossing the Canada/US border is going to be roughly 3x the cost of the same length national circuit on either side of the border. The factor of three rapidly becomes a factor of five to twenty in many other parts of the world. Treating short expensive links like a LAN is perhaps a bad idea in some cases. I wonder if heavily multiplexed but usually fairly quiet fast lines could lose badly is multiple senders suddenly tried to treat such a line as being "short and fat enough to treat like a LAN". A classical example might be a 45Mbps line connected on either end to a multiplexing router with a half dozen or so 10Mbps ethernet ports, where the hosts on the ethernets randomly do bulk transfers amongst themselves. Sean. From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 08:36:41 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA23089 for ; Fri, 23 Oct 1998 08:36:40 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA03175; Fri, 23 Oct 1998 05:31:57 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id FAA14570 for tcp-impl-list; Fri, 23 Oct 1998 05:25:34 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id FAA18205 for ; Fri, 23 Oct 1998 05:25:32 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: from sean.ebone.net (sean.ebone.net [130.228.11.231]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA09318 for ; Fri, 23 Oct 1998 05:25:30 -0700 (PDT) mail_from (smd@sean.ebone.net) Received: (from smd@localhost) by sean.ebone.net (8.8.8/8.8.5) id OAA24217; Fri, 23 Oct 1998 14:25:28 +0200 (CEST) Date: Fri, 23 Oct 1998 14:25:28 +0200 (CEST) From: Sean Doran Message-Id: <199810231225.OAA24217@sean.ebone.net> To: tcp-impl@cthulhu.engr.sgi.com, touch@ISI.EDU, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Joe Touch wrote: | RTT may be correlated (it is debatable how closely); hopcount is | much more meaningful. If you can get there in 0 hops, then there | is no router, and you shouldn't be doing these tricks. That would | require a traceroute-like test, out-of-band to the regular TCP | packets. This seems like a good approach, but traceroute-like tests may not be so simple -- consider the NAT case again: you send traffic to the "outside" address of the NAT itself, which may be hopcount=0, although the traffic passing through the NAT will be hopcount > 0. Sean. From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 09:00:34 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA23538 for ; Fri, 23 Oct 1998 09:00:34 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA01328; Fri, 23 Oct 1998 05:57:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id FAA21053 for tcp-impl-list; Fri, 23 Oct 1998 05:51:24 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id FAA74501 for ; Fri, 23 Oct 1998 05:51:21 -0700 (PDT) mail_from (andi@fred.muc.de) Received: from fred.muc.de (dialc179.ppp.lrz-muenchen.de [129.187.26.179]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id FAA02393 for ; Fri, 23 Oct 1998 05:50:36 -0700 (PDT) mail_from (andi@fred.muc.de) Received: (qmail 1594 invoked by uid 500); 23 Oct 1998 12:45:25 -0000 Message-ID: <19981023144525.A1588@kali.lrz-muenchen.de> Date: Fri, 23 Oct 1998 14:45:25 +0200 From: Andi Kleen To: Sean Doran , tcp-impl@cthulhu.engr.sgi.com, touch@ISI.EDU, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810231225.OAA24217@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <199810231225.OAA24217@sean.ebone.net>; from Sean Doran on Fri, Oct 23, 1998 at 02:25:28PM +0200 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk On Fri, Oct 23, 1998 at 02:25:28PM +0200, Sean Doran wrote: > Joe Touch wrote: > > | RTT may be correlated (it is debatable how closely); hopcount is > | much more meaningful. If you can get there in 0 hops, then there > | is no router, and you shouldn't be doing these tricks. That would > | require a traceroute-like test, out-of-band to the regular TCP > | packets. > > This seems like a good approach, but traceroute-like > tests may not be so simple -- consider the NAT case again: you > send traffic to the "outside" address of the NAT itself, which may > be hopcount=0, although the traffic passing through the NAT will > be hopcount > 0. Also it doesn't work for things like LANE over ATM or MPOA. -Andi From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 09:15:17 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA23778 for ; Fri, 23 Oct 1998 09:15:16 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAB06500; Fri, 23 Oct 1998 06:09:37 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA28704 for tcp-impl-list; Fri, 23 Oct 1998 06:02:25 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA57464 for ; Fri, 23 Oct 1998 06:02:23 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA00655 for ; Fri, 23 Oct 1998 06:02:23 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id GAA17556; Fri, 23 Oct 1998 06:02:06 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id GAA29331; Fri, 23 Oct 1998 06:02:05 -0700 (PDT) Date: Fri, 23 Oct 1998 06:02:05 -0700 (PDT) Message-Id: <199810231302.GAA29331@rum.isi.edu> To: smd@ebone.net, tcp-impl@cthulhu.engr.sgi.com, touch@ISI.EDU, vjs@calcite.rhyolite.com, ak@muc.de Subject: Re: 'Slow-Start Restart after Idle' draft X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From andi@fred.muc.de Fri Oct 23 05:50:50 1998 > Date: Fri, 23 Oct 1998 14:45:25 +0200 > From: Andi Kleen > Subject: Re: 'Slow-Start Restart after Idle' draft > > On Fri, Oct 23, 1998 at 02:25:28PM +0200, Sean Doran wrote: > > Joe Touch wrote: > > > > | RTT may be correlated (it is debatable how closely); hopcount is > > | much more meaningful. If you can get there in 0 hops, then there > > | is no router, and you shouldn't be doing these tricks. That would > > | require a traceroute-like test, out-of-band to the regular TCP > > | packets. > > > > This seems like a good approach, but traceroute-like > > tests may not be so simple -- consider the NAT case again: you > > send traffic to the "outside" address of the NAT itself, which may > > be hopcount=0, although the traffic passing through the NAT will > > be hopcount > 0. Agreed. > Also it doesn't work for things like LANE over ATM or MPOA. Here I'd argue it works just fine - if you want to make your ATM/MPOA look like a LAN, then it looks like a LAN, bursts and all. Rate limits at the ATM level would be required to avoid problems, however. Joe From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 10:38:14 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA25283 for ; Fri, 23 Oct 1998 10:38:13 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA03272; Fri, 23 Oct 1998 07:32:35 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA60243 for tcp-impl-list; Fri, 23 Oct 1998 07:26:11 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA05282 for ; Fri, 23 Oct 1998 07:26:09 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA00882 for ; Fri, 23 Oct 1998 07:26:00 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id IAA17032 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 08:25:59 -0600 (MDT) Date: Fri, 23 Oct 1998 08:25:59 -0600 (MDT) From: Vernon Schryver Message-Id: <199810231425.IAA17032@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Joe Touch > > You want to avoid slow-start and slow-restart and relax the 2:1 > > segment:ACK ratio exactly when the hosts are close to each other, > > which to say, when the RTT is small. > > RTT may be correlated (it is debatable how closely); hopcount is > much more meaningful. If you can get there in 0 hops, then there > is no router, and you shouldn't be doing these tricks. That would > require a traceroute-like test, out-of-band to the regular TCP > packets. I meant to point out in my first message Thursday that traceroute cannot detectect all of the forwarding boxes on which there is often congestion that needs slow start. Consider bridges. I disagree that hopcount is more meaningful than RTT. Whether there are 0 or 10 hops is not what determines whether slow start and ACK pacing are important, but whether there are hops where congestion should be avoided. For the bad hop count 0 case, consider a host that is able to run far faster than 100 Mbit/sec and that is taking 7000 HTTP hits/second, and also running a a few long term TCP connections to nearby systems, such as for syslog. Those local TCP links need slow start and the host needs RED or similar on its local interfaces because its interfaces are congested. I claim those cases get more accurate answers by looking at the RTT. > Closeness is not an issue - if I have a direct satellite > link, the RTT can be 500 ms but I still want to do the bursting, > since there is no router to overload. Don't satellite links almost always involve boxes doing forwarding (as well as FEC) and visible the count? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 10:48:44 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA25617 for ; Fri, 23 Oct 1998 10:48:42 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA07170; Fri, 23 Oct 1998 07:44:37 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA59494 for tcp-impl-list; Fri, 23 Oct 1998 07:38:40 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA59946 for ; Fri, 23 Oct 1998 07:38:39 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA03944 for ; Fri, 23 Oct 1998 07:38:38 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id IAA17059 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 08:38:37 -0600 (MDT) Date: Fri, 23 Oct 1998 08:38:37 -0600 (MDT) From: Vernon Schryver Message-Id: <199810231438.IAA17059@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Sean Doran > | A pair of hosts can tell only that they are on the same IP network by > | looking at prefixes, and cannot even get that right with some flavors of > | variable length subnet masking. > > Well, yes and no: ARP or ES-IS usually breaks when there > is a serious mask mismatch. Proxy-ARP is amazingly common--amazing considering what a kludge it is. > The bigger concern is LISes which are bridged. Yes, bridges are fatal for either hop-counting or netmask checks for turning on go-fast mode. > ... > Finally, as Vernon notes, even where a LAN really is a LAN and > retransmissions are cheap, it seems fair to wonder if it's smart > to dump traffic into them in an non-congestion-avoiding way for > the sake of performance. After all, the medium may be shared by > other users, and they may see a performance decrease as the result > of traffic being blasted into the LAN. Agreed. The Ethernet capture effect is a good (i.e. bad) case to consider. It need not involve two hosts, but a group of winners and another group of losers. > | There needs to be a test that detects a super fast, almost zero delay, > | practically zero loss link between a pair of hosts to turn off slow-start > | etc., but I think those examples show that network prefixesis not good > | enough. > > The only thing that seems to make sense would be recent observations > of performance between the two things that may be super-fast-losslessly- > connected to each other. Exactly! The average (not smoothed), the recent worst-case RTT, or the time required for the 3-way handshake are good indications of the common cases where you can use go-fast mode, with 10 ms being a reasonable cut-off. Note that a router or bridge hop or two likely to push the RTT or 3-way turn-around above 10 ms. Or maybe 3-5 ms. The RTT for small packets on a quiet 10 MHz Ethernet is less than 2 ms., but the maximum minimum RTT approaches 3 ms for full sized packets. 5 ms on FDDI tells you that you have 0 hops and the ring is not eggregiously saturated. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 11:36:31 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA27389 for ; Fri, 23 Oct 1998 11:36:30 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA01166; Fri, 23 Oct 1998 08:32:17 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA40420 for tcp-impl-list; Fri, 23 Oct 1998 08:28:39 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA30260 for ; Fri, 23 Oct 1998 08:28:38 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08160 for ; Fri, 23 Oct 1998 08:28:36 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id JAA17203 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 09:28:31 -0600 (MDT) Date: Fri, 23 Oct 1998 09:28:31 -0600 (MDT) From: Vernon Schryver Message-Id: <199810231528.JAA17203@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk (I appologize for sending 3 separate messages instead of checking everything in my mailbox before replying.) > From smd@sean.ebone.net Fri Oct 23 05:03:07 1998 > | Instead of matching network prefixes, why not look at the RTT? Regardless > ... > At which point do you take the RTT measurement? Why not during the 3-way handshake? Or during the previous connection, cached along with your path-MTU measurement? > Obviously, you also want to rapidly transition into normal mode > the moment you detect any increase in RTT or the moment you see loss. Agreed. I think it would go-fast mode would best leave slow-restart enabled at all times, and only turn off initial-slow-start and enable ACK compression (or disable ACK pacing). With the big windows you need to get reasonable throughput on a LAN, fast-retransmission is quite effective for the rare loss (due e.g. excessive Ethernet collisions) and mitigates the slow-dwon from slow-restart. > ... > Maybe I'm a little too conservative, but 10ms seems pretty long to me. > ... Ok, how about 5 ms? Or 10 ms divided by the half ratio of the local interface speed to 10 MHhz. E.g. 10 ms on a 10 MHz Ethernet, 2 ms on FDDI or 100 MHz Ethernet. weeell, that breaks on HIPPI, which definitely wants go-fast mode. ] From smd@sean.ebone.net Fri Oct 23 05:25:37 1998 ] ... ] | 10 milliseconds is about the right dividing line, since round trips ] | on reasonable LANs are less than 10 ms, and any long haul link with ] | an RTT of less than 10 is forced by the speed of light to be fast ] | and short enough to treat like a LAN. ] ] You have to explain this one to me. My calculator broke. 10 ms is ~2000 miles, not the 2-20 I was (not)thinking. On the other hand, each forwarding hop at bit rates of less than 45 Mbps tends to add 1 or more ms., and that tends to weed out the metro-sized fast WANs. The wire-occupancy of a 1500 byte packet at 10 MHz is 1.2 ms, , so 10 ms is not far from the watershed. ] Bear in mind that some links are quiescent most of the time. And that is fundamental to why go-fast mode is a good thing on LANs. Conversely, a saturate LAN has a larger RTT and probably wants slow-start. ] Bear in mind also that mileage charges are meaningless when ] a border is being crossed. A circuit crossing the Canada/US ] border is going to be roughly 3x the cost of the same length ] national circuit on either side of the border. The factor ] of three rapidly becomes a factor of five to twenty in many ] other parts of the world. What do monetary charges have to do with go-fast mode? ] Treating short expensive links like a LAN is perhaps a bad idea ] in some cases. I would have thought that short, expensive links are even more important candidates for go-fast mode, because their bits are more expensive. What matters is whether go-fast mode works better than the now standard way of pushing bits. ] in some cases. I wonder if heavily multiplexed but usually fairly ] quiet fast lines could lose badly is multiple senders suddenly tried ] to treat such a line as being "short and fat enough to treat like a LAN". ] ] A classical example might be a 45Mbps line connected on either end to a ] multiplexing router with a half dozen or so 10Mbps ethernet ports, ] where the hosts on the ethernets randomly do bulk transfers amongst ] themselves. It depends on the inter-Ethernet traffic. As long as there are not more than 4.5 inter-Ethernet bulk transfers happening, you want go-fast mode. In fact, even when the 45 Mbps interconnect is saturated, you want to turn off the 2:1 segment:ACK rule to reduce bad results of the Ethernet capture effect on the individual Ethernets. The Ethernet capture effect reduces TCP/IP/Ethernet throughput from the TCP speed of light of about 93% of the raw bit rate to about 68%. Lots of ACKs are a Very Bad Thing on Ethernets. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 12:55:58 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA00825 for ; Fri, 23 Oct 1998 12:55:57 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04033; Fri, 23 Oct 1998 09:52:03 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA04781 for tcp-impl-list; Fri, 23 Oct 1998 09:44:10 -0700 (PDT) mail_from (owner-tcp-impl@relay.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 JAA01832; Fri, 23 Oct 1998 09:44:08 -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 JAA05688; Fri, 23 Oct 1998 09:44:07 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810231644.JAA05688@bossette.engr.sgi.com> Subject: Re: 'Slow-Start Restart after Idle' draft To: vjs@calcite.rhyolite.com (Vernon Schryver) Date: Fri, 23 Oct 1998 09:44:07 -0700 (PDT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199810231425.IAA17032@calcite.rhyolite.com> from "Vernon Schryver" at Oct 23, 98 08:25:59 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@cthulhu.engr.sgi.com Precedence: bulk Vernon Schryver wrote: > > > From: Joe Touch > > > > You want to avoid slow-start and slow-restart and relax the 2:1 > > > segment:ACK ratio exactly when the hosts are close to each other, > > > which to say, when the RTT is small. > > > > RTT may be correlated (it is debatable how closely); hopcount is > > much more meaningful. If you can get there in 0 hops, then there > > is no router, and you shouldn't be doing these tricks. That would > > require a traceroute-like test, out-of-band to the regular TCP > > packets. > > I meant to point out in my first message Thursday that traceroute cannot > detectect all of the forwarding boxes on which there is often congestion > that needs slow start. Consider bridges. > > I disagree that hopcount is more meaningful than RTT. Whether there are > 0 or 10 hops is not what determines whether slow start and ACK pacing > are important, but whether there are hops where congestion should be avoided. > For the bad hop count 0 case, consider a host that is able to run far > faster than 100 Mbit/sec and that is taking 7000 HTTP hits/second, and > also running a a few long term TCP connections to nearby systems, such as > for syslog. Those local TCP links need slow start and the host needs RED > or similar on its local interfaces because its interfaces are congested. > > I claim those cases get more accurate answers by looking at the RTT. It seems both methods have their flaws; how about a routing table flag that allows go-fast-mode on a route-by-route basis. This could be both manually set/cleared and automatically set/cleared by some, as yet undefined, mechanism. This also avoids introducing cubersome hop-counting or RTT estimation mechanisms. You would have to be careful about setting go-fast-mode for the local net if you have proxy-ARP on that net, but you could still hack around that by setting up specific routes for the proxyarped hosts. It would be a bit messy, but that would serve you right ;-) -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 13:13:58 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA01392 for ; Fri, 23 Oct 1998 13:13:57 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA04968; Fri, 23 Oct 1998 10:08:59 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA16906 for tcp-impl-list; Fri, 23 Oct 1998 10:00:01 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA18320 for ; Fri, 23 Oct 1998 09:59:59 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA06166 for ; Fri, 23 Oct 1998 09:59:58 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id KAA17788 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 10:59:57 -0600 (MDT) Date: Fri, 23 Oct 1998 10:59:57 -0600 (MDT) From: Vernon Schryver Message-Id: <199810231659.KAA17788@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > ... > It seems both methods have their flaws; how about a routing table > flag that allows go-fast-mode on a route-by-route basis. This could > be both manually set/cleared and automatically set/cleared by some, as yet > undefined, mechanism. This also avoids introducing cubersome hop-counting > or RTT estimation mechanisms. > > You would have to be careful about setting go-fast-mode for the local > net if you have proxy-ARP on that net, but you could still hack around > that by setting up specific routes for the proxyarped hosts. It would > be a bit messy, but that would serve you right ;-) Set asside the question of how a router would compute the go-fast bit when advertising routes. On standards committee political grounds, there is absolutely no hope that any interior routing protocol would ever carry a go-fast bit. That implies such that a routing-table bit would be either only a local, purely manual configuration option, or it would a repository for a bit set by other means such as hop counting, RTT estimating, or netmask peeking. Thus, we're back where we started, having only chosen a place to put the information in some implementations. In other words, the "some, as yet undefined, mechanism" by which routing or anything else would figure out whether to go fast is the crux of the issue. Given that mechanism, where you cache its answer is an implementation detail. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 13:45:11 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA02423 for ; Fri, 23 Oct 1998 13:45:10 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA07193; Fri, 23 Oct 1998 10:40:18 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA28878 for tcp-impl-list; Fri, 23 Oct 1998 10:30:49 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA12609 for ; Fri, 23 Oct 1998 10:30:46 -0700 (PDT) mail_from (padmanab@mercenary.CS.Berkeley.EDU) Received: from mercenary.CS.Berkeley.EDU (mercenary.CS.Berkeley.EDU [128.32.33.58]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA03111 for ; Fri, 23 Oct 1998 10:30:45 -0700 (PDT) mail_from (padmanab@mercenary.CS.Berkeley.EDU) Received: from mercenary.CS.Berkeley.EDU (padmanab@localhost) by mercenary.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id KAA21313; Fri, 23 Oct 1998 10:30:41 -0700 (PDT) Message-Id: <199810231730.KAA21313@mercenary.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 X-Face: 8oz'i+bl`|5PbRnbf:lhb^%e[KkX6s2O+~WXUjjyZy3Ew*s3R1@]D {~a]r4V]),Mlwru>UYa+!f7aeLD3),v{_U3S*(e/Os}3N7*+U+#;5\W0!-U+zs&>c/Gb2FH/|KZ*Li eMcCH0X~${-18~JhYDf3Dc}H1,F From: Venkat Padmanabhan To: Vernon Schryver cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft In-reply-to: Your message of "Fri, 23 Oct 1998 08:25:59 MDT." <199810231425.IAA17032@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Oct 1998 10:30:41 -0700 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > From: Joe Touch > > > > You want to avoid slow-start and slow-restart and relax the 2:1 > > > segment:ACK ratio exactly when the hosts are close to each other, > > > which to say, when the RTT is small. > > > > RTT may be correlated (it is debatable how closely); hopcount is > > much more meaningful. If you can get there in 0 hops, then there > > is no router, and you shouldn't be doing these tricks. That would > > require a traceroute-like test, out-of-band to the regular TCP > > packets. > > I meant to point out in my first message Thursday that traceroute cannot > detectect all of the forwarding boxes on which there is often congestion > that needs slow start. Consider bridges. > > I disagree that hopcount is more meaningful than RTT. Whether there are > 0 or 10 hops is not what determines whether slow start and ACK pacing > are important, but whether there are hops where congestion should be avoided. > For the bad hop count 0 case, consider a host that is able to run far > faster than 100 Mbit/sec and that is taking 7000 HTTP hits/second, and > also running a a few long term TCP connections to nearby systems, such as > for syslog. Those local TCP links need slow start and the host needs RED > or similar on its local interfaces because its interfaces are congested. > > I claim those cases get more accurate answers by looking at the RTT. > > I disagree with your statement that it is irrelevant whether there are 0 hops or 10 hops. I agree with Joe Touch that having a 0-hop path (that should actually be "1-hop", but oh well...) is significant. I believe slow start should be skipped *only if* there is a 0-hop path between source and destination. Such a path is fundamentally different from all other paths in the following sense: if the MAC protocol grants the source host access to the channel, then the source "owns" the channel for a certain length of time. During this period, the source can be sure that the entire bandwidth of the channel is exclusively available to it, so there is no reason to probe for bandwidth a la slow-start. The situation is entirely different when a connection traverses more than one link (i.e., 1-hop or greater, according to the terminology for this discussion thread) no matter what the RTT is. Of course, 0-hop doesn't necessarily mean that it is okay to skip slow-start (i.e., we can't make an *if and only if* assertion). A slow receiver could get overwhelmed by a fast sender and drop packets. This is not fundametally different from congestion at an intermediate router in the multi-hop case. Therefore, there is a need for a per-host flag to indicate whether or not it is okay to skip slow-start (as Sam Manthorpe suggests). Of course, how these flags would be set is an open issue. -Venkat From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 13:54:50 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA02630 for ; Fri, 23 Oct 1998 13:54:49 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA05156; Fri, 23 Oct 1998 10:49:06 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA27890 for tcp-impl-list; Fri, 23 Oct 1998 10:40:22 -0700 (PDT) mail_from (owner-tcp-impl@relay.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 KAA96450; Fri, 23 Oct 1998 10:40:20 -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 KAA05941; Fri, 23 Oct 1998 10:40:20 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810231740.KAA05941@bossette.engr.sgi.com> Subject: Re: 'Slow-Start Restart after Idle' draft To: vjs@calcite.rhyolite.com (Vernon Schryver) Date: Fri, 23 Oct 1998 10:40:20 -0700 (PDT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199810231659.KAA17788@calcite.rhyolite.com> from "Vernon Schryver" at Oct 23, 98 10:59:57 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@cthulhu.engr.sgi.com Precedence: bulk Vernon Schryver wrote: > > > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > > > ... > > It seems both methods have their flaws; how about a routing table > > flag that allows go-fast-mode on a route-by-route basis. This could > > be both manually set/cleared and automatically set/cleared by some, as yet > > undefined, mechanism. This also avoids introducing cubersome hop-counting > > or RTT estimation mechanisms. > > > > You would have to be careful about setting go-fast-mode for the local > > net if you have proxy-ARP on that net, but you could still hack around > > that by setting up specific routes for the proxyarped hosts. It would > > be a bit messy, but that would serve you right ;-) > > Set asside the question of how a router would compute the go-fast bit when > advertising routes. > > [...] > > On standards committee political grounds, there is absolutely no hope that > any interior routing protocol would ever carry a go-fast bit. That implies I can't immediately see any reason why you would even want to communicate this information in a routing protocol, but I haven't thought about it in any depth yet. > In other words, the "some, as yet undefined, mechanism" by which routing > or anything else would figure out whether to go fast is the crux of the > issue. Given that mechanism, where you cache its answer is an > implementation detail. I wasn't suggesting this is an alternative to an RTT based, or hop-count based or whatever-based mechanism, rather as a supplement to one of these. The way I interpreted the ongoing discussion is to find _automatic_ mechanisms that would become part of a TCP implementation to determining whether to `go fast' or not. The routing table flag suggestion enables you to manually configure go-fast mode and thus takes care of all these `special' cases (proxy-ARP, LANE, bridges) that have been cited as examples of why automated-scheme-x will not work. It would be an implementational choice of whether you employ some automated scheme of setting this bit, based on hop counts, RTT or whatever... -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 14:25:54 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA03193 for ; Fri, 23 Oct 1998 14:25:53 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA00473; Fri, 23 Oct 1998 11:22:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA43364 for tcp-impl-list; Fri, 23 Oct 1998 11:12:21 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA50494 for ; Fri, 23 Oct 1998 11:12:19 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07279 for ; Fri, 23 Oct 1998 11:12:17 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id MAA18027 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 12:12:16 -0600 (MDT) Date: Fri, 23 Oct 1998 12:12:16 -0600 (MDT) From: Vernon Schryver Message-Id: <199810231812.MAA18027@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Venkat Padmanabhan > ... > I disagree with your statement that it is irrelevant whether there are > 0 hops or 10 hops. I agree with Joe Touch that having a 0-hop path (that should > actually be "1-hop", but oh well...) is significant. I believe slow > start should be skipped *only if* there is a 0-hop path between source and > destination. Such a path is fundamentally different from all other paths > in the following sense: if the MAC protocol grants the source host access > to the channel, then the source "owns" the channel for a certain length > of time. During this period, the source can be sure that the entire > bandwidth of the channel is exclusively available to it, so there is > no reason to probe for bandwidth a la slow-start. That model of how a LAN works sounds nice and fits the textbooks, but it is neither entirely accurate nor relevant. To see its accuracy, consider CSMA/CD during the first slot-time. It would be relevant just in case such ownership affected how TCP works. The reason for a go-fast mode has nothing to do with property ownership, but purely with whether TCP/IP runs faster. (For TCP, "speed" covers "reliability".) > The situation is entirely different when a connection traverses more than > one link (i.e., 1-hop or greater, according to the terminology for this > discussion thread) no matter what the RTT is. Everything is different from everything else, but the only differences that matter are those that matter. The difference that matters here is that paths (not merely LANs) without significant congestion from other hosts or potential congestion at bottlenecks do not benefit and are harmed by slow-start, slow-restart, and the 2:1 ACK:segment ratio. That fact is the only justification for a fast mode. That harm has nothing to do with whether the link is 0/1 or 100 hops long, although it is far less likely with more hops. That characterization, "without significant congestion or bottlenecks," is independent of whether some MAC protocol has granted some ownership, even where that notion makes sense. Note that: - congestion that ought to be managed with slow-start can happen on the sending side of a host-LAN-host link when the sending host is much faster than the LAN, and the host-LAN interface is one of those bottlenecks. For a fun, try a bunch of simultaneous ttcp or netperf sessions on a fast host using 100BASE-T or FDDI, 60 KByte default TCP windows, and less than 1 MByte of output buffering in the driver. For that matter, try it with one ttcp session using a MByte TCP window but less than 1 MB drive buffering. - a path without congestion or bottlenecks but that has errors is also harmed by slow-(re)start. If you know that there is no other traffic and no bottlenecks, then you do NOT want to shrink the transmit window when you detect loss, because you know the loss had nothing to do with congestion. - router and bridges (and therefore hops) tend to go together with connecting slower and faster links in a path, and so with bottlenecks that need slow-start. So hops, if they were detectable, would be a reasonable go-fast mode switch. But hops) are not detectable (briges, except by looking at the RTT and then only much of the time. - what I'm saying now is slightly contrary to my claim this morning about satellite links. A link with 500 ms RTT, that is carrying only one TCP/IP connection, and where all of the links in the path have the same bit rate does not want slow-(re)start or any other congestion avoidance mechanism, because there is no congestion to avoid (expcept perhaps at the sending host). However, a satellite link or any path with an RTT larger than about 10 ms is likely to involve multiple segments including at least one where the bit rate is far slower than the bit rate at the sending host, and so a bottleneck that wants slow-start. > Of course, 0-hop doesn't necessarily mean that it is > okay to skip slow-start (i.e., we can't make an *if and only if* assertion). > A slow receiver could get overwhelmed by a fast sender and drop packets. > This is not fundametally different from congestion at an intermediate > router in the multi-hop case. A slow receiver is less likely to produce a fast RTT, and in any case, had better not be dropping any TCP/IP packets. That's what the TCP window is all about. However, there is the sending-host case. > Therefore, there is a need for a per-host flag to indicate whether > or not it is okay to skip slow-start (as Sam Manthorpe suggests). > Of course, how these flags would be set is an open issue. A per-host, purely manual, violate-the-standard-and-go-fast flag is always possible, but is also outside the scope of of a standard. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:10:43 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03876 for ; Fri, 23 Oct 1998 15:10:42 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09905; Fri, 23 Oct 1998 11:34:16 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA58648 for tcp-impl-list; Fri, 23 Oct 1998 11:25:24 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA58633 for ; Fri, 23 Oct 1998 11:25:22 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA01130 for ; Fri, 23 Oct 1998 11:25:07 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id LAA11529; Fri, 23 Oct 1998 11:25:04 -0700 (PDT) Message-Id: <199810231825.LAA11529@daffy.ee.lbl.gov> To: Vernon Schryver Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft In-reply-to: Your message of Fri, 23 Oct 1998 09:28:31 PDT. Date: Fri, 23 Oct 1998 11:25:04 PDT From: Vern Paxson Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Lots of ACKs are a Very Bad Thing on Ethernets. Please back this up with further analysis. I've put a tcpdump trace in ftp://ftp.ee.lbl.gov/.vp-100mbps.trace This is an rcp along a 100 Mbps fast Ether link, with sufficiently large windows to fill it. The receiver for the most part acks every-second, sometimes acking every third, and there's a periodic glitch in which it generates stretch acks (doesn't affect the throughput). Once the connection reaches steady-state, it sustains upwards of 11 MB/s. Vern From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:12:44 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03920 for ; Fri, 23 Oct 1998 15:12:43 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA02315; Fri, 23 Oct 1998 12:07:13 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA71022 for tcp-impl-list; Fri, 23 Oct 1998 11:59:03 -0700 (PDT) mail_from (owner-tcp-impl@relay.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 LAA64841; Fri, 23 Oct 1998 11:59:01 -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 LAA06319; Fri, 23 Oct 1998 11:59:00 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810231859.LAA06319@bossette.engr.sgi.com> Subject: Re: 'Slow-Start Restart after Idle' draft To: vjs@calcite.rhyolite.com (Vernon Schryver) Date: Fri, 23 Oct 1998 11:59:00 -0700 (PDT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199810231826.MAA18096@calcite.rhyolite.com> from "Vernon Schryver" at Oct 23, 98 12:26:34 pm 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@cthulhu.engr.sgi.com Precedence: bulk Vernon Schryver wrote: > > > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > > > ... > > I can't immediately see any reason why you would even want to communicate > > this information in a routing protocol, but I haven't thought about it > > in any depth yet. > > If it is not sent in routing packets, why should the go-fast-to-this-host > bit be in the routing table? I agree that's a nice place to put it, but > it is not the only place. The situation is very much like path MTU > discovery. Many people put the discovered MTU in the routing table, but > that is not the only choice, as shown by some code on bonnie.engr.sgi.com. > > > > > In other words, the "some, as yet undefined, mechanism" by which routing > > > or anything else would figure out whether to go fast is the crux of the > > > issue. Given that mechanism, where you cache its answer is an > > > implementation detail. > > > > I wasn't suggesting this is an alternative to an RTT based, or hop-count > > based or whatever-based mechanism, rather as a supplement to one of these. > > > > The way I interpreted the ongoing discussion is to find _automatic_ > > mechanisms that would become part of a TCP implementation to determining > > whether to `go fast' or not. The routing table flag suggestion enables > > you to manually configure go-fast mode and thus takes care of all > > these `special' cases (proxy-ARP, LANE, bridges) that have been cited > > as examples of why automated-scheme-x will not work. > > How does putting the per-host go-fast bit in the routing table entry > for that host (presumably along with other things such as the manual MSS) > help the proxy-ARP case? As far as the host that would have the bit in > its routing table is concerned (assuming a merged ARP-IP routing table), > all peers look the same regardless of whether proxy-ARP is involved. > > Manual go-fast bits are not practical. Proofs by example of that claim > are the manual MSS mechanism used among SGI and Cray boxes, and the > popularity of the automated path MTU discovery mechanism. > > Are you suggesting that if the MAC source address in an ARP entry does not > match the contents of the ARP packet (after allowing for bit-order > nonsense on FDDI), that the go-fast bit would be automatically turned off? > And on by default otherwise? > > > It would be an implementational choice of whether you employ some automated > > scheme of setting this bit, based on hop counts, RTT or whatever... > > I am still confused. Are you saying more than that the 4.4BSD-Lite style > routing table is a nicer place for a per-host go-fast bit than, for > example, an independent kernel data structure? Note that many systems > do not have the 4.4BSD-Lite style routing table. I'm thinking in terms of user-interface. My point was simply that since there seem to be a multitude of scenarios where the simple go-fast-detection schemes discussed would fail, it would be desirable for a sysadmin to be able to override any automatic decision on a net-by-net or host-by-host basis. It also provides the possibility to enable/disable GFM (go fast mode) in the complete absence of any automated mechanism. So my argument is really orthogonal to the discussion on a nice scheme for detecting when one should use go-fast mode. Yes, my thinking is definitely BSD biased; how alien OSes would chose to implement such a scheme would be for them to decide. (the word alien is in no way meant to be derogatory, I am myself currently a legal alien). -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:12:46 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03931 for ; Fri, 23 Oct 1998 15:12:45 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04941; Fri, 23 Oct 1998 12:07:13 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA36540 for tcp-impl-list; Fri, 23 Oct 1998 12:03:12 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA73873 for ; Fri, 23 Oct 1998 12:03:09 -0700 (PDT) mail_from (padmanab@mercenary.CS.Berkeley.EDU) Received: from mercenary.CS.Berkeley.EDU (mercenary.CS.Berkeley.EDU [128.32.33.58]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04562 for ; Fri, 23 Oct 1998 12:03:08 -0700 (PDT) mail_from (padmanab@mercenary.CS.Berkeley.EDU) Received: from mercenary.CS.Berkeley.EDU (padmanab@localhost) by mercenary.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id MAA21984; Fri, 23 Oct 1998 12:03:04 -0700 (PDT) Message-Id: <199810231903.MAA21984@mercenary.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 X-Face: 8oz'i+bl`|5PbRnbf:lhb^%e[KkX6s2O+~WXUjjyZy3Ew*s3R1@]D {~a]r4V]),Mlwru>UYa+!f7aeLD3),v{_U3S*(e/Os}3N7*+U+#;5\W0!-U+zs&>c/Gb2FH/|KZ*Li eMcCH0X~${-18~JhYDf3Dc}H1,F From: Venkat Padmanabhan To: Vernon Schryver cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft In-reply-to: Your message of "Fri, 23 Oct 1998 12:12:16 MDT." <199810231812.MAA18027@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Oct 1998 12:03:04 -0700 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > From: Venkat Padmanabhan > > > ... > > I disagree with your statement that it is irrelevant whether there are > > 0 hops or 10 hops. I agree with Joe Touch that having a 0-hop path (that sh ould > > actually be "1-hop", but oh well...) is significant. I believe slow > > start should be skipped *only if* there is a 0-hop path between source and > > destination. Such a path is fundamentally different from all other paths > > in the following sense: if the MAC protocol grants the source host access > > to the channel, then the source "owns" the channel for a certain length > > of time. During this period, the source can be sure that the entire > > bandwidth of the channel is exclusively available to it, so there is > > no reason to probe for bandwidth a la slow-start. > > That model of how a LAN works sounds nice and fits the textbooks, but it > is neither entirely accurate nor relevant. To see its accuracy, consider > CSMA/CD during the first slot-time. It would be relevant just in case > such ownership affected how TCP works. The reason for a go-fast mode has > nothing to do with property ownership, but purely with whether TCP/IP runs > faster. (For TCP, "speed" covers "reliability".) > I guess I am entirely missing what you are saying here... What I am saying is that in the 0-hop case, the regulation would be done by the MAC. TCP needn't. TCP would still have a flow-control window, though, but that's a function of the socket buffer size set by applications, and hence orthogonal. > > The situation is entirely different when a connection traverses more than > > one link (i.e., 1-hop or greater, according to the terminology for this > > discussion thread) no matter what the RTT is. > > Everything is different from everything else, but the only differences > that matter are those that matter. The difference that matters here is > that paths (not merely LANs) without significant congestion from other > hosts or potential congestion at bottlenecks do not benefit and are harmed > by slow-start, slow-restart, and the 2:1 ACK:segment ratio. That fact is > the only justification for a fast mode. That harm has nothing to do with > whether the link is 0/1 or 100 hops long, although it is far less likely > with more hops. That characterization, "without significant congestion > or bottlenecks," is independent of whether some MAC protocol has granted > some ownership, even where that notion makes sense. > I can't contest the validity of the tautologies in the first sentence ;-) I was saying that there is *fundamental* difference between 0-hop and n-hop where n > 0. It is dangerous to assume that a path is lightly loaded. Since the path is presumably shared by many hosts and no one host has a complete picture of the load imposed by other hosts, what is lightly loaded at one instant could be heavily loaded at another (for instance, due to "flash crowds"). In other words, it is difficult (in fact, fundametally flawed) to characterize a path as being "without significant congestion or bottlenecks" given the shared nature of the network. However, in the 0-hop case, the MAC protocol gives a host exclusive access to the channel for a certain length of time. There is no competition above the MAC layer, except between multiple connections on a host. Of course, there is competition at the MAC layer and we would want it to be resolved fairly, etc., but that is an orthogonal issue. As a performance optimization one certainly might want to take advantage of times when a multi-hop network is in fact lightly loaded. But I believe such aggressive use of the network must happen only in conjunction with mechanisms that avoid/alleviate disaster when the "lightly loaded" assumption is incorrect. One possible mechanism is priority dropping which I discuss in the "TCP fast start" chapter of my thesis: http://www.cs.berkeley.edu/~padmanab/phd-thesis.html > Note that: > - congestion that ought to be managed with slow-start can happen > on the sending side of a host-LAN-host link when the sending host > is much faster than the LAN, and the host-LAN interface is one of > those bottlenecks. For a fun, try a bunch of simultaneous ttcp or > netperf sessions on a fast host using 100BASE-T or FDDI, 60 KByte > default TCP windows, and less than 1 MByte of output buffering in > the driver. For that matter, try it with one ttcp session using > a MByte TCP window but less than 1 MB drive buffering. Sure, it can happen at the sender. I've seen it several times on a WaveLAN network. It can happen at the receiver, too. > A per-host, purely manual, violate-the-standard-and-go-fast flag is always > possible, but is also outside the scope of of a standard. A per-host flag need not be set manually. A host can learn from past experience and set it automatically. -Venkat From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:17:57 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA04024 for ; Fri, 23 Oct 1998 15:17:56 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03612; Fri, 23 Oct 1998 11:34:16 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA48929 for tcp-impl-list; Fri, 23 Oct 1998 11:26:40 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA77328 for ; Fri, 23 Oct 1998 11:26:38 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA08351 for ; Fri, 23 Oct 1998 11:26:35 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id MAA18096 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 12:26:34 -0600 (MDT) Date: Fri, 23 Oct 1998 12:26:34 -0600 (MDT) From: Vernon Schryver Message-Id: <199810231826.MAA18096@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > ... > I can't immediately see any reason why you would even want to communicate > this information in a routing protocol, but I haven't thought about it > in any depth yet. If it is not sent in routing packets, why should the go-fast-to-this-host bit be in the routing table? I agree that's a nice place to put it, but it is not the only place. The situation is very much like path MTU discovery. Many people put the discovered MTU in the routing table, but that is not the only choice, as shown by some code on bonnie.engr.sgi.com. > > In other words, the "some, as yet undefined, mechanism" by which routing > > or anything else would figure out whether to go fast is the crux of the > > issue. Given that mechanism, where you cache its answer is an > > implementation detail. > > I wasn't suggesting this is an alternative to an RTT based, or hop-count > based or whatever-based mechanism, rather as a supplement to one of these. > > The way I interpreted the ongoing discussion is to find _automatic_ > mechanisms that would become part of a TCP implementation to determining > whether to `go fast' or not. The routing table flag suggestion enables > you to manually configure go-fast mode and thus takes care of all > these `special' cases (proxy-ARP, LANE, bridges) that have been cited > as examples of why automated-scheme-x will not work. How does putting the per-host go-fast bit in the routing table entry for that host (presumably along with other things such as the manual MSS) help the proxy-ARP case? As far as the host that would have the bit in its routing table is concerned (assuming a merged ARP-IP routing table), all peers look the same regardless of whether proxy-ARP is involved. Manual go-fast bits are not practical. Proofs by example of that claim are the manual MSS mechanism used among SGI and Cray boxes, and the popularity of the automated path MTU discovery mechanism. Are you suggesting that if the MAC source address in an ARP entry does not match the contents of the ARP packet (after allowing for bit-order nonsense on FDDI), that the go-fast bit would be automatically turned off? And on by default otherwise? > It would be an implementational choice of whether you employ some automated > scheme of setting this bit, based on hop counts, RTT or whatever... I am still confused. Are you saying more than that the 4.4BSD-Lite style routing table is a nicer place for a per-host go-fast bit than, for example, an independent kernel data structure? Note that many systems do not have the 4.4BSD-Lite style routing table. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:19:17 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA04048 for ; Fri, 23 Oct 1998 15:19:16 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02248; Fri, 23 Oct 1998 11:54:55 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA42925 for tcp-impl-list; Fri, 23 Oct 1998 11:46:24 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA64578 for ; Fri, 23 Oct 1998 11:46:17 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07347 for ; Fri, 23 Oct 1998 11:46:16 -0700 (PDT) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA1378 for ; Fri, 23 Oct 1998 11:46:13 -0700 Message-ID: <3630CECE.A365D800@ehsco.com> Date: Fri, 23 Oct 1998 11:45:34 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810231825.LAA11529@daffy.ee.lbl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > Lots of ACKs are a Very Bad Thing on Ethernets. > > Please back this up with further analysis. There's lots of variables that affect the Badness of Frequent ACKs on Ethernets. Half-duplex or full. Shared or switched. Network load. But generally speaking, the more frames used for ACKs, the less frames can be used for data. If you've got plenty of slots, there's no difference. If you're tight on slots, there's lots of difference. Lots of nodes sending lots of ACKs will definitely cut your data delivery rate. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:19:19 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA04058 for ; Fri, 23 Oct 1998 15:19:18 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02863; Fri, 23 Oct 1998 11:54:54 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA68242 for tcp-impl-list; Fri, 23 Oct 1998 11:48:23 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA13380 for ; Fri, 23 Oct 1998 11:48:20 -0700 (PDT) mail_from (raj@cup.hp.com) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA00379 for ; Fri, 23 Oct 1998 11:48:20 -0700 (PDT) mail_from (raj@cup.hp.com) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.13.104.252]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id OAA13283 for ; Fri, 23 Oct 1998 14:48:11 -0400 (EDT) Received: from cup.hp.com (raj@loiter [15.13.104.252]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id LAA26331 for ; Fri, 23 Oct 1998 11:48:17 -0700 (PDT) Message-ID: <3630CF71.E8A61097@cup.hp.com> Date: Fri, 23 Oct 1998 11:48:17 -0700 From: Rick Jones Organization: HP 9000 Network Performance X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810231825.LAA11529@daffy.ee.lbl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > Lots of ACKs are a Very Bad Thing on Ethernets. > > Please back this up with further analysis. I've put a tcpdump trace in Well, these days, the cycle processing of an ACK is little different from the cycle processing of a data packet. Systems now have copy-avoidance mechanisms, and interface cards with checksum offload (CKO) functionality. This makes most if not all of the CPU costs for say a web server per-packet costs. Reducing the number of packets (eg ACKs) then increases the capacity of the server. An arbitrary reduction in ACKs is probably not a good idea. However, a receiver which is able to figure-out when things are not flowing smoothly and so ACKs with apropriate frequency at apropriate times would probably not be such a bad thing. A fixed choice of an ACK for every two MSS segments is merely a very simple, straightforward, and "cheap" heuristic to arrive at an ACK rate apropriate for the traffic conditions. I would certainly like implementations to be free to use other equally robust mechanisms which might happen to be cheaper in the free and clear case (such as LANs or unloaded links). So, if future RFC's can state requirements of behaviour without forcing a given ACK policy that might be best. 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@cthulhu.engr.sgi.com Fri Oct 23 15:19:20 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA04067 for ; Fri, 23 Oct 1998 15:19:19 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09419; Fri, 23 Oct 1998 11:54:54 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA64478 for tcp-impl-list; Fri, 23 Oct 1998 11:45:47 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA69365 for ; Fri, 23 Oct 1998 11:45:44 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA05223 for ; Fri, 23 Oct 1998 11:45:40 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id MAA18174 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 12:45:39 -0600 (MDT) Date: Fri, 23 Oct 1998 12:45:39 -0600 (MDT) From: Vernon Schryver Message-Id: <199810231845.MAA18174@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Vern Paxson > > > Lots of ACKs are a Very Bad Thing on Ethernets. > > Please back this up with further analysis. I've put a tcpdump trace in > > ftp://ftp.ee.lbl.gov/.vp-100mbps.trace > > This is an rcp along a 100 Mbps fast Ether link, with sufficiently large > windows to fill it. The receiver for the most part acks every-second, > sometimes acking every third, and there's a periodic glitch in which it > generates stretch acks (doesn't affect the throughput). Once the connection > reaches steady-state, it sustains upwards of 11 MB/s. I cannot find a file there. However, I bet that at least one of the following is true, any one of which is sufficent to sidestep the problem: - you used a TCP window size of less than 16 K - you used half-duplex MAC chips with BLAM (except that I didn't think any were commercially available) - you used full-duplex EThernet, which is not really Ethernet since it has nothing more to do with CSMA/CD than 100VG-AnyLAN, 802.5, HIPP, ATM, FC, or FDDI. - you used half-duplex MAC chips that violate 802.3 as the old AMD 7990 LANCE did, by being "polite" and not transmitting immediately after deferring. If you use a TCP window of >= 32K, 802.3 compliant MAC chips with BEG instead of BLAM, and fast hosts, you'll get about 8 MByte/sec instead of 11 MByte/sec. The problem is that if both systems are transmitting about the same number of packets, and they are using 802.3 compliant MACs with BEB and not BLAM, then one of them will capture the Ethernet, and the other will binary-exponential-backoff into the weeds and even suffer excessive collision errors. What usually happens is that the TCP sender blasts a full window, starves for ACKs because the TCP receiver has BEB'ed into waiting for 512 slot times, and goes to sleep. Eventually the TCP receiver wakes up, sends one of its queued ACK's, and everything starts rolling again, for a while. If you use a small TCP window, the hiccups still exist, but they are much smaller. If the TCP sender does capture the wire with an 8K window, it runs out of transmit window before the TCP receiver has backed off to death, and so the TCP receiver is able to get its ACK through without having the wire being idle for most of 1024 slot times. If you abuse the 4.3BSD-Reno TCP code to not send as many ACKs, the problem goes away, at least for TCP windows of 61,440. I say this based on years of glaring at a <> of traces, as well as having personally abused 4.3BSD-Reno. I could also tell you about custom silicon in MAC chips intended by design to violate IEEE 802.3 to deal with this problem, but it's supposed to be secret. There is also Mart Molle's extensive writings on the issue. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:34:11 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA04451 for ; Fri, 23 Oct 1998 15:34:10 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07070; Fri, 23 Oct 1998 12:29:55 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA54914 for tcp-impl-list; Fri, 23 Oct 1998 12:24:46 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA88324 for ; Fri, 23 Oct 1998 12:24:44 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA06140 for ; Fri, 23 Oct 1998 12:24:43 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id MAA11832; Fri, 23 Oct 1998 12:24:43 -0700 (PDT) Message-Id: <199810231924.MAA11832@daffy.ee.lbl.gov> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft In-reply-to: Your message of Fri, 23 Oct 1998 12:45:39 PDT. Date: Fri, 23 Oct 1998 12:24:42 PDT From: Vern Paxson Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Vernon Schryver > > > ftp://ftp.ee.lbl.gov/.vp-100mbps.trace > ... > I cannot find a file there. Some browsers don't like hidden files - if so, ordinary FTP ought to fetch it. > However, I bet that at least one of the following is true, any one of > which is sufficent to sidestep the problem: > - you used a TCP window size of less than 16 K Receiver offered 17K, sender had about 16K in flight. > - you used half-duplex MAC chips with BLAM (except that I didn't > think any were commercially available) I don't know, but we're running stock hardware. > - you used full-duplex EThernet, which is not really Ethernet since No, we have that on one of our machines, but not this one. > - you used half-duplex MAC chips that violate 802.3 as the old AMD 7990 > LANCE did, by being "polite" and not transmitting immediately after > deferring. I don't know - it's fairly new hardware, though. > The problem is that if both systems are transmitting about the same > number of packets, and they are using 802.3 compliant MACs with BEB and > not BLAM, then one of them will capture the Ethernet, and the other will > binary-exponential-backoff into the weeds and even suffer excessive > collision errors. It would appear that acking frequently could actually help with this. The window moves in small increments, so there are lulls in the sender's transmission, during which more acks can be sent. It seems that infrequent acking could rather aggravate the capture effect: it leads to large bursts of back-to-back data packets, so a lot more opportunity for the receiver's collision timer to back off into the weeds. I'd be interested in understanding what's missing from this analysis. Vern From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 15:54:27 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA04805 for ; Fri, 23 Oct 1998 15:54:26 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08258; Fri, 23 Oct 1998 12:49:46 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA79437 for tcp-impl-list; Fri, 23 Oct 1998 12:46:53 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA94683 for ; Fri, 23 Oct 1998 12:46:50 -0700 (PDT) mail_from (sob@newdev.harvard.edu) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAB05420 for ; Fri, 23 Oct 1998 12:46:48 -0700 (PDT) mail_from (sob@newdev.harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.8.8/8.8.5) id PAA17986; Fri, 23 Oct 1998 15:46:40 -0400 (EDT) Date: Fri, 23 Oct 1998 15:46:40 -0400 (EDT) From: Scott Bradner Message-Id: <199810231946.PAA17986@newdev.harvard.edu> To: tcp-impl@cthulhu.engr.sgi.com, vern@ee.lbl.gov Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > - you used half-duplex MAC chips with BLAM (except that I didn't > think any were commercially available) I had not heard that such chips were in products - has BLAM even been endorsed by IEEE? Scott From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 16:34:54 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA05673 for ; Fri, 23 Oct 1998 16:34:53 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08639; Fri, 23 Oct 1998 13:24:34 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA04877 for tcp-impl-list; Fri, 23 Oct 1998 13:21:01 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA05312 for ; Fri, 23 Oct 1998 13:20:59 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06202 for ; Fri, 23 Oct 1998 13:20:57 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id OAA18403 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 14:20:57 -0600 (MDT) Date: Fri, 23 Oct 1998 14:20:57 -0600 (MDT) From: Vernon Schryver Message-Id: <199810232020.OAA18403@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Venkat Padmanabhan > ... > I guess I am entirely missing what you are saying here... My point is that classic, Van Jacobson TCP congestion avoidance and control should be applied only where it does more good than harm. > What I am saying is that in the 0-hop case, the regulation would be > done by the MAC. TCP needn't. TCP would still have a flow-control > window, though, but that's a function of the socket buffer size set > by applications, and hence orthogonal. That is false in both directions. First is the case where there is a bottleneck within a host between it and its LAN that benefits from slow-start etc. Second is the case of today's typical bridged network. If you insist on slow-start whenever there is a forwarder in the path, then you insist on slow-start practically everywhere. Host-to-host MAC-layer flow-control has been almost universally destroyed by so called "smart hubs" and "switches." > ... > I was saying that there is *fundamental* difference between 0-hop and > n-hop where n > 0. It is dangerous to assume that a path is lightly > loaded. Since the path is presumably shared by many hosts and no one > host has a complete picture of the load imposed by other hosts, what > is lightly loaded at one instant could be heavily loaded at another > (for instance, due to "flash crowds"). Those words apply equally to a WAN as to a LAN. "Flash crowds" happen on LANs, although they are vastly less frequent than the "switch" salescritters and trade-rag consultants would like suckers to believe. > In other words, it is difficult > (in fact, fundametally flawed) to characterize a path as being > "without significant congestion or bottlenecks" given the shared > nature of the network. When a path is not "without significant congestion or bottlenecks", then it obvious is not, and when it is, it is. How in the world can it be "fundamentally flawed" to charactize a path as it is? Do you mean that the characterization can change? If so, that problem applies even more to single-hop LANs than to WANs. The instant a bulk transfer starts, with or without go-fast mode, a single hop LAN is no longer "without significant congestion or bottlenecks" to other traffic. > However, in the 0-hop case, the MAC protocol > gives a host exclusive access to the channel for a certain length of > time. There is no competition above the MAC layer, except between > multiple connections on a host. Of course, there is competition > at the MAC layer and we would want it to be resolved fairly, etc., > but that is an orthogonal issue. Those words do not apply to no LAN that I can think of. They obviously do not apply to any LAN that involves a shared medium. "Flash crowds" on on LANs are familiar to anyone who has looked at an Ethernet or token ring, not mention implemented applications that did things like update files on many systems at the stroke of 8 a.m. Access to the Ethernet carrier or the 802.5 or FDDI token is just as vulnerable to contention as access to a leased line or the buffer in a router talking to a leased line. Even LANs that are based enirely on non-blocking switches, such as ATM and HIPPI do not fit your model, because of congestion in the host interfces. How do you resolve congestion at the MAC layer without slowing something down? If the MAC layer simply slows down but your TCP code keeps pumping, what must happen? Hint: my point about what happens with `ttcp -b 1048576 -l 1048576` between a pair of hosts was not theoretical. Or consider NFSv3/TCP/IP; it does not take many NFS connections with the default 32K block size of NFSv3 to overwhelm the buffering in most drivers. > As a performance optimization one certainly might want to take advantage > of times when a multi-hop network is in fact lightly loaded. But I believe such > aggressive use of the network must happen only in conjunction with > mechanisms that avoid/alleviate disaster when the "lightly loaded" > assumption is incorrect. One possible mechanism is priority dropping > which I discuss in the "TCP fast start" chapter of my thesis: > http://www.cs.berkeley.edu/~padmanab/phd-thesis.html Anything involving "dropping" seems irrelevant to the issue at hand. I favor turning on go-fast mode only when it appears from recent RTT measurements that it is reasonable, and giving up on lossy networks by limiting go-fast mode to only turning off slow-start and ACK pacing and retaining slow-restart. Turning off slow-start but keeping slow-restart (which I take to mean standard congestion avoiding TCP/IP but with an initial full-sized transmit window) has the nice property of responding appropriately if a "flash crowd" appears. It has the bad property of making flash crowds worse, and so should not be used unless there is evidence things are not bad. The only way I see to get that evidence is by looking at the recent RTT. > ... > > A per-host, purely manual, violate-the-standard-and-go-fast flag is always > > possible, but is also outside the scope of of a standard. > > A per-host flag need not be set manually. A host can learn from past > experience and set it automatically. Exactly how the host learns and so automatically sets the per-host flag is the whole point! The etiology of 0- vs. multi-hop networks might be interesting, but the issue is how to set that per-host flag automatically! So far, netmasks, hop counting, and RTT's have been suggested. Do you have another way? - netmasks do not work because proxy-ARP, bridges, and VLSM would cause false positives with dire consequences on literally millions of networks (PPP stubbs connected to home computeres). - hop counting is simply impossible. How does TCP discover how many hops are in the path? Does it delay sending the SYN-ACK until it probes with `traceroute`? How does that detect bridges? How can you detect >1 hop paths except with the RTT? - RTT's (e.g. from a previous connection or measured during the 3-way handshake) are imperfect, possibly producing false positives on, e.g. OC-12 metro links, or on bursty LANs. Still, what alternative is there? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 17:14:22 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06461 for ; Fri, 23 Oct 1998 17:14:21 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA07880; Fri, 23 Oct 1998 14:02:20 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA26547 for tcp-impl-list; Fri, 23 Oct 1998 13:56:31 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA17486 for ; Fri, 23 Oct 1998 13:56:29 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06221 for ; Fri, 23 Oct 1998 13:56:27 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id OAA18533 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 14:56:16 -0600 (MDT) Date: Fri, 23 Oct 1998 14:56:16 -0600 (MDT) From: Vernon Schryver Message-Id: <199810232056.OAA18533@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Vern Paxson > ... > > > ftp://ftp.ee.lbl.gov/.vp-100mbps.trace > > ... > > I cannot find a file there. > > Some browsers don't like hidden files - if so, ordinary FTP ought to > fetch it. Netscape delivered garbage, so I tried `ls` via FTP, which denied the file existed. Having more than once received large (many MByte) traces by email, I was a little shy about fetching it blindly. I just now did anyway, and found it was < 200KBytes, but it's some kind of binary. I guess I could try `tcpdump -r`...yes, I see that produces things. But you answer the point > ... > > - you used a TCP window size of less than 16 K > > Receiver offered 17K, sender had about 16K in flight. That's close enough to reduce the problem to tolerable levels. You might also have BLAM in one of the MAC chips. Now that I think back, I think I heard rumors one of the 100 MHz chips has BLAM. > ... > > The problem is that if both systems are transmitting about the same > > number of packets, and they are using 802.3 compliant MACs with BEB and > > not BLAM, then one of them will capture the Ethernet, and the other will > > binary-exponential-backoff into the weeds and even suffer excessive > > collision errors. > > It would appear that acking frequently could actually help with this. The > window moves in small increments, so there are lulls in the sender's > transmission, during which more acks can be sent. It seems that infrequent > acking could rather aggravate the capture effect: it leads to large bursts of > back-to-back data packets, so a lot more opportunity for the receiver's > collision timer to back off into the weeds. I'd be interested in > understanding what's missing from this analysis. In summary, back-to-back packets are not the problem. The problem is the collison between to long trains of packets. If the TCP receiver is not sending ACKs frequently, then it is less likely to collide with the TCP sender, and so it's less likely to back-off into the weeds. If the TCP receiver responds to the second TCP segment with an ACK (and is fast), it is certain to collide with the third segment. If it is unlucky and loses the first 2 or 3 collisions while trying to send that first ACK, it will probably back-off into the weeds (backoff counter=10) or wait until the TCP sender stops sending, whichever comes first. TCP sender will continue sending and occassionally colliding, as the receiver's timer occassionally and less and less frequently expires, until it runs out of window. With your TCP window of ~17K, the TCP sender will never send more than ~11 packets before starving for an ACK. That means the receiver will never suffer more than 8, and at 100 MHz if it is not super fast, probably not more than 5 or 6 consecutive collisions on any ACK, so its back-off counter will be only 5, so it will wait only about 16 slot times, which is less than a packet-time. Note that the probability of the TCP receiver losing the wire is less than 87% on each ACK. More than 87% of the time, it will win the first collision or one of the early subsequent collisions. (Specifically, on each packet, it will not be locked out with probability .5+.25+.125+...) Now consider a TCP window of 60*1024. That's a collision a train of 40 packets with a train of 20 ACKs under normal rules. Either the TCP sender or the TCP receiver is likely to capture the wire, and the other is like to have a back-off counter equal to 10, and so wait up to 1024 slot times or the equivalent of 65KBytes of data after the other has stopped sending. Worse, there's a good chance that the loser will suffer 16 collisions and drop a packet, and if the loser is the TCP sender, that really hurts. Now consider reducing the ACK ratio by always delaying ACKs, and not just after partial segments. If the TCP receiver does send its first ACK for the arriving train of segments until 10 or 15 segments have arrived, it is less likely to be locked off the wire by its own back-off counter. Or if its train of ACKs is only 5 intead of 20, it is not nearly as certain to have one of those ACKs get unlucky and run up its back-off counter. Note that the point Rick Jones made is also valid, but less dramatic than the 30% throughput loss due to the Ethernet Capture Effect. Host performance is a generally function of packet counts, so more packets always costs speed, even if they cost no bandwidth, as with full-duplex media. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 17:15:14 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA06490 for ; Fri, 23 Oct 1998 17:15:13 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05075; Fri, 23 Oct 1998 14:04:54 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA26929 for tcp-impl-list; Fri, 23 Oct 1998 14:02:55 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA10127 for ; Fri, 23 Oct 1998 14:02:53 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA04596 for ; Fri, 23 Oct 1998 14:02:50 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id PAA18571 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 15:02:47 -0600 (MDT) Date: Fri, 23 Oct 1998 15:02:47 -0600 (MDT) From: Vernon Schryver Message-Id: <199810232102.PAA18571@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Scott Bradner > > - you used half-duplex MAC chips with BLAM (except that I didn't > > think any were commercially available) > > I had not heard that such chips were in products - has BLAM even been > endorsed by IEEE? What does "endorsed by the IEEE" mean? The last I heard from Mart Molle was quite a while ago and that 802.3v (u? x? whatever) was chugging along, but that the 10 MHz chip vendors were not happy with the prospect of either fixing their ancient designs or shipping slower chips. Never mind that the really ancient AMD LANCE beats them all, except when you turn on their various really nasty (e.g. linear backoff) work-arounds or in a case or two, their emulation of the LANCE bug. On reflection, I think I was told at my former job that one of the 100 MHz MACs in one or another of the products would eventually have BLAM. However, don't take that as gospel, since I was never directly involved, never even saw a 100 MHz or GHz chip spec, and besides, it might be a secret. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 18:12:31 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07334 for ; Fri, 23 Oct 1998 18:12:29 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA00432; Fri, 23 Oct 1998 15:03:20 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA41726 for tcp-impl-list; Fri, 23 Oct 1998 14:58:48 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA58476 for ; Fri, 23 Oct 1998 14:58:46 -0700 (PDT) mail_from (padmanab@mercenary.CS.Berkeley.EDU) Received: from mercenary.CS.Berkeley.EDU (mercenary.CS.Berkeley.EDU [128.32.33.58]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05777 for ; Fri, 23 Oct 1998 14:58:44 -0700 (PDT) mail_from (padmanab@mercenary.CS.Berkeley.EDU) Received: from mercenary.CS.Berkeley.EDU (padmanab@localhost) by mercenary.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id OAA22811; Fri, 23 Oct 1998 14:58:32 -0700 (PDT) Message-Id: <199810232158.OAA22811@mercenary.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 X-Face: 8oz'i+bl`|5PbRnbf:lhb^%e[KkX6s2O+~WXUjjyZy3Ew*s3R1@]D {~a]r4V]),Mlwru>UYa+!f7aeLD3),v{_U3S*(e/Os}3N7*+U+#;5\W0!-U+zs&>c/Gb2FH/|KZ*Li eMcCH0X~${-18~JhYDf3Dc}H1,F From: Venkat Padmanabhan To: Vernon Schryver cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft In-reply-to: Your message of "Fri, 23 Oct 1998 14:20:57 MDT." <199810232020.OAA18403@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Oct 1998 14:58:32 -0700 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > > What I am saying is that in the 0-hop case, the regulation would be > > done by the MAC. TCP needn't. TCP would still have a flow-control > > window, though, but that's a function of the socket buffer size set > > by applications, and hence orthogonal. > > That is false in both directions. First is the case where there is a > bottleneck within a host between it and its LAN that benefits from > slow-start etc. Second is the case of today's typical bridged network. > If you insist on slow-start whenever there is a forwarder in the path, > then you insist on slow-start practically everywhere. Host-to-host > MAC-layer flow-control has been almost universally destroyed by so called > "smart hubs" and "switches." Regarding your first point, you are basically saying that congestion is can happen at the sender (a point you made in your previous email and I agreed with in my previous one). But the problem is a local one that is easy to resolve, and in fact there is a reasonable fix in the BSD stack. If the interface queue fills up, TCP's call to ip_output() returns an error code and the sender slows down ("quench") instantaneously. When there are multiple connections originating from a host, they should coordinate their actions so that if one of them experiences a "buffer full" condition, the others should learn from it. (In my thesis, I worked on doing this in certain special cases.) Experiencing a "buffer full" condition on your local stack is much easier to deal with than having your packets lost elsewhere in the network. For one thing, there is no uncertainty about whether the buffer is in fact full (and hence dropping packets) or whether there is only a temporary RTT spike (i.e., large delay but no drops). Regarding your second point, yes, if there is a forwarder in the path so that the sender does not have know the load on a LAN segment on the other side of a bridge than itself, then it should do slow start. > > > > ... > > I was saying that there is *fundamental* difference between 0-hop and > > n-hop where n > 0. It is dangerous to assume that a path is lightly > > loaded. Since the path is presumably shared by many hosts and no one > > host has a complete picture of the load imposed by other hosts, what > > is lightly loaded at one instant could be heavily loaded at another > > (for instance, due to "flash crowds"). > > Those words apply equally to a WAN as to a LAN. "Flash crowds" happen > on LANs, although they are vastly less frequent than the "switch" > salescritters and trade-rag consultants would like suckers to believe. > You are absolutely right. But the difference I was pointing out was not that flash crowds happen in one but not in the other. It was that in the 0-hop case, the MAC guarantees the sender access to the wire from itself to the receiver. No such guarantees are made for an n-hop path. Of course, as we have agreed, there can still be a problem due to slowness of the receiver or sender. That is why in my first email, I said that a 0-hop path was an *only if* requirement but not an *if and only if* one. > > In other words, it is difficult > > (in fact, fundametally flawed) to characterize a path as being > > "without significant congestion or bottlenecks" given the shared > > nature of the network. > > When a path is not "without significant congestion or bottlenecks", then > it obvious is not, and when it is, it is. How in the world can it be > "fundamentally flawed" to charactize a path as it is? Do you mean that > the characterization can change? If so, that problem applies even more > to single-hop LANs than to WANs. The instant a bulk transfer starts, with > or without go-fast mode, a single hop LAN is no longer "without significant > congestion or bottlenecks" to other traffic. > Yes, I mean it can change, and quite unpredicatably in the worst case. In the LAN case, as I have explained, the sender knows through *local* information that the LAN has a high load, so can slow down its sending rate without aggravating the congestion in the LAN. > > > However, in the 0-hop case, the MAC protocol > > gives a host exclusive access to the channel for a certain length of > > time. There is no competition above the MAC layer, except between > > multiple connections on a host. Of course, there is competition > > at the MAC layer and we would want it to be resolved fairly, etc., > > but that is an orthogonal issue. > > Those words do not apply to no LAN that I can think of. They obviously > do not apply to any LAN that involves a shared medium. "Flash crowds" on > on LANs are familiar to anyone who has looked at an Ethernet or token > ring, not mention implemented applications that did things like update > files on many systems at the stroke of 8 a.m. Access to the Ethernet > carrier or the 802.5 or FDDI token is just as vulnerable to contention as > access to a leased line or the buffer in a router talking to a leased > line. Even LANs that are based enirely on non-blocking switches, such as > ATM and HIPPI do not fit your model, because of congestion in the host > interfces. Perhaps you misunderstood what I meant by a "certain length of time". I was referring to the time granularity of MAC allocations, not minutes or hours. An example may clarify the issue. Suppose that host A has a single TCP connection to host B, and both A and B are on the same LAN segment. Assuming that the end hosts are not bottlenecks and that TCP flow control does not kick in, A should be sending to B as fast as its MAC is able to grab the channel. Of course, at times such as "the stroke of 8 a.m.", A's MAC will not be able to grab the channel very much because many others will also be trying to grab the channel, so ... . > > How do you resolve congestion at the MAC layer without slowing something > down? If the MAC layer simply slows down but your TCP code keeps pumping, > what must happen? Hint: my point about what happens with > `ttcp -b 1048576 -l 1048576` between a pair of hosts was not theoretical. > Or consider NFSv3/TCP/IP; it does not take many NFS connections with the > default 32K block size of NFSv3 to overwhelm the buffering in most drivers. > My original characterization of TCP and the MAC as being orthogonal was incorrect. As I have mentioned above, BSD TCP has a "quench" mechanism that allows TCP to slow down instantly when its local interface queue is full (for instance, because the MAC is not able to grab the channel very much). I hope you will agree that dealing with such local congestion is a whole lot easier than the general problem of dealing with congestion "somewhere" in the network. I think it makes little sense to use a general probing algorithm such as slow start is the only capacity that you are trying "match" is that of your local link/buffer. > > > As a performance optimization one certainly might want to take advantage > > of times when a multi-hop network is in fact lightly loaded. But I believe such > > aggressive use of the network must happen only in conjunction with > > mechanisms that avoid/alleviate disaster when the "lightly loaded" > > assumption is incorrect. One possible mechanism is priority dropping > > which I discuss in the "TCP fast start" chapter of my thesis: > > http://www.cs.berkeley.edu/~padmanab/phd-thesis.html > > Anything involving "dropping" seems irrelevant to the issue at hand. > That's a strong statement! I thought we were discussing congestion avoidance and control, and given that, I don't see how we can ignore the possibility of packets getting dropped (however undesirable that may be). I'll try to explain how I use priority dropping in my answer to your next question. > > ... > > > A per-host, purely manual, violate-the-standard-and-go-fast flag is alway s > > > possible, but is also outside the scope of of a standard. > > > > A per-host flag need not be set manually. A host can learn from past > > experience and set it automatically. > > Exactly how the host learns and so automatically sets the per-host flag > is the whole point! The etiology of 0- vs. multi-hop networks might be > interesting, but the issue is how to set that per-host flag automatically! > > So far, netmasks, hop counting, and RTT's have been suggested. Do > you have another way? > The operative part of what I said was "learn from past experience". Here's the outline of a simple scheme. It makes no assumptions about hop counts, netmasks, etc. 1. If doing a transfer to another host for the first time in x minutes (x TBD), do slow start. 2. If you've done a transfer in the past x minutes, start with window size equal to where you left off the last time. Use timer to smooth out bursts. Mark all packets, except for the first one, as "low priority". In the best case, all the packets will go through fine and you will experience the benefit of fast start. In a worse case (such as the networking having become much more congested since the last time you used it), priority dropping with shield (to an extent) other traffic from the ill-effects of your aggressiveness. In my work, I also developed some special loss detection/recovery algorithms for use during the fast start phase. If your are interested, you should look at my thesis. -Venkat From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 18:52:55 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07855 for ; Fri, 23 Oct 1998 18:52:53 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA03841; Fri, 23 Oct 1998 15:40:49 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA39714 for tcp-impl-list; Fri, 23 Oct 1998 15:37:24 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA73835 for ; Fri, 23 Oct 1998 15:37:21 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA08158 for ; Fri, 23 Oct 1998 15:37:17 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id QAA18911 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 23 Oct 1998 16:37:14 -0600 (MDT) Date: Fri, 23 Oct 1998 16:37:14 -0600 (MDT) From: Vernon Schryver Message-Id: <199810232237.QAA18911@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Venkat Padmanabhan > ... > Regarding your second point, yes, if there is a forwarder in the > path so that the sender does not have know the load on a LAN > segment on the other side of a bridge than itself, then it should > do slow start. Given the near universal installation of bridges, aren't you saying that by your reconning, no go-fast switch is possible? Recall, for example, that every 100/10BASE-T hub is necessarily a bridge. > ... > Of course, as we have agreed, there can still be a problem due to > slowness of the receiver or sender. That is why in my first email, > I said that a 0-hop path was an *only if* requirement but not an > *if and only if* one. We disagree. You keep saying that a 0-hop path is almost sacred but others are vulgar and cannot use a go-fast mode. Consider a private, three-segment campus or metro network where the local links are 10 MHz Ethernet and the long-haul segment is as fast as necessary to guarantee no slow down, say FDDI or T3. Such things do exist in real life for economically sound reasons. (Many Silicon Valley outfits lease dark fiber under public streets to connect their buildings). Please say why that case is more likely to experience flash crowds than the 128.32.33.00/24 near your desk, and also say how it would be easier for mercenary.CS.Berkeley.EDU to detect such problems. (I'm guessing that there is a "smart hub" or "bridge" on the 128.32.33.00/24 Ethernet, given the many well known and presumably sometimes busy hosts on it.) My guess is that the only way congestion can be detected in either network is by TCP timeouts or duplicate ACKs, and that congestion is far more likely on your local Ethernet then on my not so hypothetical network. > ... > Yes, I mean it can change, and quite unpredicatably in the worst case. > In the LAN case, as I have explained, the sender knows through *local* > information that the LAN has a high load, so can slow down its > sending rate without aggravating the congestion in the LAN. Please say how a sender on a LAN can tell that its local LAN has suddenly gone bad, given the installed base of millions of bridges that we all know will never look at any new bits in proposed revisions of TCP headers. There is no hope among those of us who've experienced previous generations of bridges that they'll even honor old bits they're required by standards and common sense (e.g. FDDI-Ethernet and IP DF). Also as I keep saying, the "switch" sales critters have entirely broken MAC-layer flow control. They actually use that fact as one of their selling points, and their suckers--oops actually think it is a good thing. > ... > > Anything involving "dropping" seems irrelevant to the issue at hand. > > > That's a strong statement! I thought we were discussing congestion > avoidance and control, and given that, I don't see how we can ignore > the possibility of packets getting dropped (however undesirable that > may be). We are not discussing new ideas ofr congestion avoidance or management. We are talking about a sneaky-smart switch in hosts that turns off the standards-required ACK pacing and/or slow-(re)start. Yes, packets can be dropped, but the idea of the go-fast switch is ONLY for cases where packet losses are low or at least not due to congestion, and only when congestion is being managed with slow-(re)start, with the need of slow-(re)start for well smoothed RTT's with requirement from that for the 2:1 ACK:segment ratio. > ... > The operative part of what I said was "learn from past experience". > Here's the outline of a simple scheme. It makes no assumptions > about hop counts, netmasks, etc. > > 1. If doing a transfer to another host for the first time in x minutes > (x TBD), do slow start. > > 2. If you've done a transfer in the past x minutes, start with window size > equal to where you left off the last time. Use timer to smooth out bursts. > Mark all packets, except for the first one, as "low priority". In the best > case, all the packets will go through fine and you will experience the > benefit of fast start. In a worse case (such as the networking having become > much more congested since the last time you used it), priority dropping > with shield (to an extent) other traffic from the ill-effects of your > aggressiveness. > ... In which bit of the current TCP or IPv4 headers is your low priority mark? Given a free hand, a lot of things other than Van Jacobson's old but extremely cool old kludge of watching for packet loss and guessing about congestion could be tried. ECN is an obvious and currently popular idea, after years of quiet. However, that's all entirely irrelevant to this discussion and possibly to this mailing list. (Recall it's title is something about TCP implementation). We are not talking about TCPng, but how to mitigate the new, stronger language about ACK pacing and slow-(re)start. Again, given things that the host that needs to set its own go-fast switch for traffic to a specified other host, what do you suggest we do? If you have a real alternative to looking at the RTT or the netmask, please describe it. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Oct 23 20:39:59 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA08977 for ; Fri, 23 Oct 1998 20:39:58 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA05138; Fri, 23 Oct 1998 17:34:58 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA23380 for tcp-impl-list; Fri, 23 Oct 1998 17:28:57 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA05362 for ; Fri, 23 Oct 1998 17:28:49 -0700 (PDT) mail_from (sob@newdev.harvard.edu) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA01336 for ; Fri, 23 Oct 1998 17:28:48 -0700 (PDT) mail_from (sob@newdev.harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.8.8/8.8.5) id UAA18625; Fri, 23 Oct 1998 20:28:39 -0400 (EDT) Date: Fri, 23 Oct 1998 20:28:39 -0400 (EDT) From: Scott Bradner Message-Id: <199810240028.UAA18625@newdev.harvard.edu> To: tcp-impl@cthulhu.engr.sgi.com, vjs@calcite.rhyolite.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > What does "endorsed by the IEEE" mean? passed as a standard Scott From owner-tcp-impl@cthulhu.engr.sgi.com Sun Oct 25 23:46:10 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA14575 for ; Sun, 25 Oct 1998 23:46:05 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA07343; Sun, 25 Oct 1998 20:42:21 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA61550 for tcp-impl-list; Sun, 25 Oct 1998 20:34:45 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA33518 for ; Sun, 25 Oct 1998 20:34:44 -0800 (PST) mail_from (mridley@autobahn.org) Received: from bmw.autobahn.org (bmw.autobahn.org [206.79.223.28]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA05699 for ; Sun, 25 Oct 1998 20:34:43 -0800 (PST) mail_from (mridley@autobahn.org) Received: from willow (mridley@ip-209-133-105-61.dialup.autobahn.org [209.133.105.61]) by bmw.autobahn.org (8.8.7/8.8.7) with ESMTP id UAA22914; Sun, 25 Oct 1998 20:34:39 -0800 Received: (from mridley@localhost) by willow (8.6.12/8.6.9) id UAA12972; Sun, 25 Oct 1998 20:35:53 -0800 Message-ID: <19981025203553.A12952@autobahn.org> Date: Sun, 25 Oct 1998 20:35:53 -0800 From: Michael Ridley To: Vernon Schryver Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft References: <199810232020.OAA18403@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810232020.OAA18403@calcite.rhyolite.com>; from Vernon Schryver on Fri, Oct 23, 1998 at 02:20:57PM -0600 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk On Fri, Oct 23, 1998 at 02:20:57PM -0600, Vernon Schryver wrote: > > - RTT's (e.g. from a previous connection or measured during the > 3-way handshake) are imperfect, possibly producing false positives > on, e.g. OC-12 metro links, or on bursty LANs. Still, what > alternative is there? > Vernon Schryver vjs@rhyolite.com I think I must be missing something here, but why do we care if it's an OC-12 link, for instance? Is that a false positive? The goal here is to bypass slow start when appropriate and send the full advertised window so as to maximize use of non-congested links, correct? Assuming that I haven't gotten really confused in all of this, then I would think you'd want to send the max window on the OC-12 if it's RTT was low (often a faster link even than your LAN on both ends). By stating it's a false positive, you make me think that you'd want slow start in such a case- why? Sorry about the late reply on this... -- Michael Ridley mridley@computer.org From owner-tcp-impl@cthulhu.engr.sgi.com Mon Oct 26 10:16:01 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20592 for ; Mon, 26 Oct 1998 10:15:34 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA00669; Mon, 26 Oct 1998 07:10:17 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA82544 for tcp-impl-list; Mon, 26 Oct 1998 07:01:48 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA87703 for ; Mon, 26 Oct 1998 07:01:46 -0800 (PST) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA00555 for ; Mon, 26 Oct 1998 07:01:45 -0800 (PST) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id IAA16354 for tcp-impl@cthulhu.engr.sgi.com env-from ; Mon, 26 Oct 1998 08:01:42 -0700 (MST) Date: Mon, 26 Oct 1998 08:01:42 -0700 (MST) From: Vernon Schryver Message-Id: <199810261501.IAA16354@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: 'Slow-Start Restart after Idle' draft Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Michael Ridley > > - RTT's (e.g. from a previous connection or measured during the > > 3-way handshake) are imperfect, possibly producing false positives > > on, e.g. OC-12 metro links, or on bursty LANs. Still, what > > alternative is there? > I think I must be missing something here, but why do we care if it's > an OC-12 link, for instance? Is that a false positive? The goal > here is to bypass slow start when appropriate and send the full > advertised window so as to maximize use of non-congested links, correct? > Assuming that I haven't gotten really confused in all of this, then > I would think you'd want to send the max window on the OC-12 if it's RTT > was low (often a faster link even than your LAN on both ends). > > By stating it's a false positive, you make me think that you'd want slow > start in such a case- why? Yes, I phrased things badly there. My general claim is that it does not matter whether there is one hop or many, or whether some of the hops are longer or shorter. All that matters is that you want a go-fast mode that violates some of the proposed, even stronger language enforcing the TCP congestion control and avoidance mechanisms when there are sufficiently few, opportunites for congestion at the current instant. It would be nice if there the go-fast mode and how and when it is invoked were documented, for all of the standard reasons standards exist. I was trying to concede in those words that a fairly short, fast, but somewhat congested link can appear to have a very small RTT, when the RTT is measured with a single pair of packets, such as during the 3-way handshake. The point of a go-fast mode is the extreme case of what started the discussions in this mailing list (I think it was here) weeks or months ago about increasing the initial window for HTTP. If you have a semi-private 1 Gbit/sec link connecting hosts using 500KByte windows and 1432 byte MSS to move blocks of data, you really do not want to wait for 175 ACKs before you are using the full window. You use such large windows because your bandwidth*delay product is that large or larger, and you are going at speeds where much of the delay comes from inside your hosts. For example, if your operating system wakes up your application to dump to a screen buffer 10 or 20 ms, you want enough data on hand to make it worth while. Or consider moving files; most UNIX file systems do not deliver or sink GBytes/sec, but some do, and there soon will be more. Given today's cheap Gbit Ethernet and $2000 PC's with 100's of MByte of RAM, such scenarios are no longer found only among people with $30M CPU's, or at least with $B atomic particle detectors. Competative pressures will at least entice implementors to discard slow-start in such situations. If they are not conservative in how they turn off slow-start, their code will also turn it off in the classic cases where it is needed. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Mon Oct 26 13:17:37 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26070 for ; Mon, 26 Oct 1998 13:17:36 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA05564; Mon, 26 Oct 1998 10:13:06 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA38743 for tcp-impl-list; Mon, 26 Oct 1998 10:07:48 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA55355 for ; Mon, 26 Oct 1998 10:07:46 -0800 (PST) mail_from (luigi@labinfo.iet.unipi.it) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id KAA06080 for ; Mon, 26 Oct 1998 10:07:41 -0800 (PST) mail_from (luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA02603; Mon, 26 Oct 1998 17:03:11 +0100 From: Luigi Rizzo Message-Id: <199810261603.RAA02603@labinfo.iet.unipi.it> Subject: tcp initial window and rate pacing... To: tcp-impl@cthulhu.engr.sgi.com Date: Mon, 26 Oct 1998 17:03:10 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Hi, (not sure if this is more for tcpimpl or end2end...) I have read the recent RFCs (2414,2415,2416) about increasing the initial window to 4K or so -- all is fine, the situation is not too different from a regular TCP after one round, etc. But has anyone considered, in addition to larger windows, also pacing the generation of the initial burst of packets at a relatively low rate so that one can an even slightly larger initial window yet avoiding overflows at the network edges (e.g. dialup users) ? The implementation seems trivial (i did it with some 20 lines of code driven by fasttimo() ) and being able to use slightly larger windows makes the connection less prone to ack starvation. Lacking information the initial rate can be set to a conservative value so that one can reuse the fasttimo code, or one can use cached values from previous connections same as it is done with the initial RTT and RTTVAR comments ? cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-tcp-impl@cthulhu.engr.sgi.com Mon Oct 26 14:44:55 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA27763 for ; Mon, 26 Oct 1998 14:44:50 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA06435; Mon, 26 Oct 1998 11:39:09 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA12530 for tcp-impl-list; Mon, 26 Oct 1998 11:31:56 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA03484 for ; Mon, 26 Oct 1998 11:31:54 -0800 (PST) mail_from (aron@cs.rice.edu) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02569 for ; Mon, 26 Oct 1998 11:31:53 -0800 (PST) mail_from (aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA08370; Mon, 26 Oct 1998 13:31:48 -0600 (CST) From: Mohit Aron Message-Id: <199810261931.NAA08370@cs.rice.edu> Subject: Re: tcp initial window and rate pacing... To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 26 Oct 1998 13:31:47 -0600 (CST) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199810261603.RAA02603@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 26, 98 05:03:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > But has anyone considered, in addition to larger windows, also > pacing the generation of the initial burst of packets at a relatively > low rate so that one can an even slightly larger initial window > yet avoiding overflows at the network edges (e.g. dialup users) ? > I've done some work on this. Please take a look at: http://www.cs.rice.edu/~aron/papers/rice-TR98-318.ps - Mohit From owner-tcp-impl@cthulhu.engr.sgi.com Mon Oct 26 16:03:43 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29287 for ; Mon, 26 Oct 1998 16:03:42 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04342; Mon, 26 Oct 1998 12:58:15 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA49207 for tcp-impl-list; Mon, 26 Oct 1998 12:54:00 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA51758 for ; Mon, 26 Oct 1998 12:53:55 -0800 (PST) mail_from (touch@ISI.EDU) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09551 for ; Mon, 26 Oct 1998 12:53:53 -0800 (PST) mail_from (touch@ISI.EDU) Received: from isi.edu (boreas.isi.edu [128.9.160.161]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id MAA27248; Mon, 26 Oct 1998 12:53:38 -0800 (PST) Message-ID: <3634E0D4.D9F1D92D@isi.edu> Date: Mon, 26 Oct 1998 12:51:33 -0800 From: Joe Touch Organization: USC/ISI X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Mohit Aron CC: Luigi Rizzo , tcp-impl@cthulhu.engr.sgi.com Subject: Re: tcp initial window and rate pacing... References: <199810261931.NAA08370@cs.rice.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Mohit Aron wrote: > > > > But has anyone considered, in addition to larger windows, also > > pacing the generation of the initial burst of packets at a relatively > > low rate so that one can an even slightly larger initial window > > yet avoiding overflows at the network edges (e.g. dialup users) ? > > > > I've done some work on this. Please take a look at: > http://www.cs.rice.edu/~aron/papers/rice-TR98-318.ps John Heidemann here at USC/ISI has done some work on rate-pacing.I have done some work (RFC2140) on TCP control block sharing, which would allow rate values to be shared over multiple connections to the same place. There can, of course, be default initial values, as there are for the window size. Papers are available at: http://www.isi.edu/lsam/ Joe From owner-tcp-impl@cthulhu.engr.sgi.com Mon Oct 26 19:18:16 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01235 for ; Mon, 26 Oct 1998 19:18:15 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA05571; Mon, 26 Oct 1998 16:12:20 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA57066 for tcp-impl-list; Mon, 26 Oct 1998 16:08:16 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA65225 for ; Mon, 26 Oct 1998 16:08:14 -0800 (PST) mail_from (craig@aland.bbn.com) Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA01422 for ; Mon, 26 Oct 1998 16:08:10 -0800 (PST) mail_from (craig@aland.bbn.com) Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id QAA20546; Mon, 26 Oct 1998 16:07:33 -0800 (PST) Message-Id: <199810270007.QAA20546@aland.bbn.com> To: Luigi Rizzo cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: tcp initial window and rate pacing... In-reply-to: Your message of "Mon, 26 Oct 1998 17:03:10 +0100." <199810261603.RAA02603@labinfo.iet.unipi.it> Date: Mon, 26 Oct 1998 16:07:33 -0800 From: Craig Partridge Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Yes -- we're looking at various pacing schemes and their effects under contract to NASA. So far it looks promising but one never knows until one is done. Thanks! Craig In message <199810261603.RAA02603@labinfo.iet.unipi.it>, Luigi Rizzo writes: >Hi, > >(not sure if this is more for tcpimpl or end2end...) > >I have read the recent RFCs (2414,2415,2416) about increasing the >initial window to 4K or so -- all is fine, the situation is not too >different from a regular TCP after one round, etc. > >But has anyone considered, in addition to larger windows, also >pacing the generation of the initial burst of packets at a relatively >low rate so that one can an even slightly larger initial window >yet avoiding overflows at the network edges (e.g. dialup users) ? > >The implementation seems trivial (i did it with some 20 lines of code >driven by fasttimo() ) and being able to use slightly larger windows >makes the connection less prone to ack starvation. >Lacking information the initial rate can be set to a conservative >value so that one can reuse the fasttimo code, or one can use cached >values from previous connections same as it is done with the initial >RTT and RTTVAR > >comments ? > > cheers > luigi >-----------------------------+-------------------------------------- >Luigi Rizzo | Dip. di Ingegneria dell'Informazione >email: luigi@iet.unipi.it | Universita' di Pisa >tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) >fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ >_____________________________|______________________________________ From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 09:40:31 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA14899 for ; Tue, 27 Oct 1998 09:40:30 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA07862; Tue, 27 Oct 1998 06:36:17 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA91565 for tcp-impl-list; Tue, 27 Oct 1998 06:29:10 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA54062; Tue, 27 Oct 1998 06:28:52 -0800 (PST) mail_from (hire@hiredhits.com) Received: from hiredhits.com (chi-qbu-nvb-vty10.as.wcom.net [209.154.105.10]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id GAA02851; Tue, 27 Oct 1998 06:28:22 -0800 (PST) mail_from (hire@hiredhits.com) DATE: Tue, 27 Oct 1998 08:41:08 -0600 Message-ID: Subject: FREE DEMO of Software That Puts You On OVER 1000 Search Engines! From: hire@hiredhits.com To: $user@cthulhu.engr.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Greetings! I thought I would take some time today to let you know about a wonderful new software package that will dramatically increase your web site's visibility. It's called The Spider, and I have been using it for several months and enjoyed a tremendous increase in my website's traffic. This software has impressed me so much that I decided to buy the reseller rights to it. And now, we are offering it on a FREE DEMO basis. Before I let you in on our secret download location, let me tell you a bit more about it. 1) 1000 + Supported Search Engines (Pro), 450 for standard edition 2) Batch Processing - allows you to take control of your website promotions - for all of your pages and sites. With a built in on-board database and batch processing, you can accurately register as many sites or pages as you like, all at once. 3) Categorized submissions - accuracy is critical when placing your site; our program recognizes and properly places you in all of our supported search engines. Don't be fooled by the competition - the shotgun approach does not work! 4) True CGI based registration - while other programs simply email your site information to search engine webmasters in the vain hope they will manually enter your information, The Search Engine Spider interacts with the server directly, custom formatting your site information for each and every supported engine. 5) Small Size, Fast Execution : The Spider is written entirely in the C programming language, and takes advantage of the true 32 bit multithreaded programming environment provided therein. It's fast: in our internal testing, the new program will perform 450 individual registrations in just under 18 minutes. Testing was done on a 28.8 dialup line. 6) Automatic Update Feature: No more weekly and monthly downloads! In an effort to keep up to date with search engine changes and updates, we have now incorporated a feature that will automate this task. Here's how it works: a.. Each time the program is loaded, it will automatically connect to our server and verify that the current search engine database is loaded on your user's machine. If it is not, it will automatically initiate a download. b. Once the download is complete (typically 20-30 seconds on a 28.8K connection), normal program operation will resume with the new database. 7) Improved Error Checking: anytime an error is generated during submission, by any user anywhere, the program updates our server with the search engine name, time and date of the error, and the nature of the error. Our resource manager for this project checks his log daily and investigates each and every error and has the ability to dynamically and instantly update the master database with the corrections. Once the correction is made, the Automatic Update Feature kicks in, distributing the updated registration database to every user worldwide the next time they use the program. To get your FREE DEMO of this amazing software, please visit: http://www.hiredhits.com/ If you would prefer us to send you a CD with The Spider, along with free demos of over 10 of our other web promotion software packages, please visit: http://www.hiredhits.com/order/process_cd.htm If you are having problems connecting to the above links, please give us a call at 773-271-8484 and we will arrange another way for you to get your FREE DEMO. Thanks again for your time and please let me know if you have any questions. Best Regards, Amy Horowitz MasterPromote, Inc. 120 Broadview Village Square Suite 315 Broadview, IL 60153 773-271-8484 ********* To remove yourself from this mailing list, please visit http://www.hiredhits.com and type your name in the "Remove Me!" box. We will promptly remove your name from future mailings. Sorry for any inconveince we may have caused From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 13:57:51 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA23001 for ; Tue, 27 Oct 1998 13:57:50 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA07116; Tue, 27 Oct 1998 10:50:00 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA83600 for tcp-impl-list; Tue, 27 Oct 1998 10:43:47 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA32335 for ; Tue, 27 Oct 1998 10:43:44 -0800 (PST) mail_from (alan@lxorguk.ukuu.org.uk) Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06385 for ; Tue, 27 Oct 1998 10:43:42 -0800 (PST) mail_from (alan@lxorguk.ukuu.org.uk) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id SAA15912; Tue, 27 Oct 1998 18:43:28 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zYExp-0007UkC; Tue, 27 Oct 98 19:39 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: tcp initial window and rate pacing... To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 27 Oct 1998 19:39:31 +0000 (GMT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199810261603.RAA02603@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 26, 98 05:03:10 pm Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Lacking information the initial rate can be set to a conservative > value so that one can reuse the fasttimo code, or one can use cached > values from previous connections same as it is done with the initial > RTT and RTTVAR I played a little with pacing output frames. The overhead on fast links when trying to do the timer stuff is nasty, on low speed ok. I had horrible problems with half duplex media though. On AX.25 and irda throughput dropped in both cases. Alan From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 14:41:48 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23625 for ; Tue, 27 Oct 1998 14:41:46 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA09218; Tue, 27 Oct 1998 11:36:29 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA34074 for tcp-impl-list; Tue, 27 Oct 1998 11:32:32 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA74219 for ; Tue, 27 Oct 1998 11:32:31 -0800 (PST) mail_from (padmanab@microsoft.com) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03791 for ; Tue, 27 Oct 1998 11:32:30 -0800 (PST) mail_from (padmanab@microsoft.com) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 27 Oct 1998 11:32:29 -0800 Message-ID: <2FEED299C092D1118B3100805F6F41BD09BC5ED7@RED-MSG-09> From: Venkat Padmanabhan To: "'luigi@labinfo.iet.unipi.it'" Cc: "'tcp-impl@cthulhu.engr.sgi.com'" Subject: Re: tcp initial window and rate pacing... Date: Tue, 27 Oct 1998 11:32:20 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > But has anyone considered, in addition to larger windows, also > pacing the generation of the initial burst of packets at a relatively > low rate so that one can an even slightly larger initial window > yet avoiding overflows at the network edges (e.g. dialup users) ? I considered this in TCP fast start, which I developed as part of my thesis (http://www.cs.berkeley.edu/~padmanab/phd-thesis.html). This also appears in the 1998 Global Internet Conference (http://www.cs.berkeley.edu/~padmanab/papers/gi98.ps). I made no assumptions about how often information from the past would be valid. Therefore, I had two goals: 1. To reduce latency by reusing window information when such information is valid. 2. To avoid performance degradation when the information is stale. I used priority dropping to shield other traffic in case the cached window is stale (and too large), and some special techniques to quickly detect and abort a failed fast start attempt. My experimental results showed that not doing so could cause much worse performance than with standard slow start in certain situations, clearly an undesirable outcome. -Venkat From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 16:13:52 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24684 for ; Tue, 27 Oct 1998 16:13:51 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01873; Tue, 27 Oct 1998 13:04:19 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA75040 for tcp-impl-list; Tue, 27 Oct 1998 12:59:06 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA33396 for ; Tue, 27 Oct 1998 12:59:05 -0800 (PST) mail_from (vern@daffy.ee.lbl.gov) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08517 for ; Tue, 27 Oct 1998 12:58:52 -0800 (PST) mail_from (vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id MAA29263; Tue, 27 Oct 1998 12:58:46 -0800 (PST) Message-Id: <199810272058.MAA29263@daffy.ee.lbl.gov> To: Venkat Padmanabhan Cc: "'luigi@labinfo.iet.unipi.it'" , "'tcp-impl@cthulhu.engr.sgi.com'" Subject: Re: tcp initial window and rate pacing... In-reply-to: Your message of Tue, 27 Oct 1998 11:32:20 PST. Date: Tue, 27 Oct 1998 12:58:46 PST From: Vern Paxson Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Let's please migrate this thread to end2end-interest - thanks. Vern From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 19:49:14 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26376 for ; Tue, 27 Oct 1998 19:49:12 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA05743; Tue, 27 Oct 1998 16:43:18 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA76287 for tcp-impl-list; Tue, 27 Oct 1998 16:38:25 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA80712 for ; Tue, 27 Oct 1998 16:38:17 -0800 (PST) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06596 for ; Tue, 27 Oct 1998 16:38:16 -0800 (PST) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA17F7 for ; Tue, 27 Oct 1998 16:38:14 -0800 Message-ID: <36366756.8A3D499B@ehsco.com> Date: Tue, 27 Oct 1998 16:37:42 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementations Subject: shipping implementations w/ advanced options Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Apart from Microsoft, is anybody shipping a TCP stack that incorporates any of the advanced options? In particular, am looking for products that use the Window Scale, Timestamp and Selective Acknowledgment options. Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 19:56:28 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26410 for ; Tue, 27 Oct 1998 19:56:28 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA09922; Tue, 27 Oct 1998 16:49:42 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA77104 for tcp-impl-list; Tue, 27 Oct 1998 16:47:49 -0800 (PST) mail_from (owner-tcp-impl@relay.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 QAA76331; Tue, 27 Oct 1998 16:47:47 -0800 (PST) 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 QAA35912; Tue, 27 Oct 1998 16:47:47 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199810280047.QAA35912@bossette.engr.sgi.com> Subject: Re: shipping implementations w/ advanced options To: ehall@ehsco.com (Eric A. Hall) Date: Tue, 27 Oct 1998 16:47:47 -0800 (PST) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <36366756.8A3D499B@ehsco.com> from "Eric A. Hall" at Oct 27, 98 04:37:42 pm 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@cthulhu.engr.sgi.com Precedence: bulk Eric A. Hall wrote: > Apart from Microsoft, is anybody shipping a TCP stack that incorporates > any of the advanced options? In particular, am looking for products that > use the Window Scale, Timestamp and Selective Acknowledgment options. IRIX supports window scale and timestamps (as I think most people do these days) and will soon support SACK. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 20:00:26 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA26446 for ; Tue, 27 Oct 1998 20:00:25 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06164; Tue, 27 Oct 1998 16:55:01 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA72678 for tcp-impl-list; Tue, 27 Oct 1998 16:51:17 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA84483 for ; Tue, 27 Oct 1998 16:51:16 -0800 (PST) mail_from (alan@lxorguk.ukuu.org.uk) Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA00152 for ; Tue, 27 Oct 1998 16:51:14 -0800 (PST) mail_from (alan@lxorguk.ukuu.org.uk) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id AAA21876; Wed, 28 Oct 1998 00:50:56 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zYKhS-0007UkC; Wed, 28 Oct 98 01:47 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: shipping implementations w/ advanced options To: ehall@ehsco.com (Eric A. Hall) Date: Wed, 28 Oct 1998 01:47:02 +0000 (GMT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <36366756.8A3D499B@ehsco.com> from "Eric A. Hall" at Oct 27, 98 04:37:42 pm Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Apart from Microsoft, is anybody shipping a TCP stack that incorporates > any of the advanced options? In particular, am looking for products that > use the Window Scale, Timestamp and Selective Acknowledgment options. Linux 2.1.x has window scaling, timestamp, and selective ack for both IPv4 and IPv6. The BSD's have been shipping window scaling for a very long time. Alan From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 20:03:21 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA26533 for ; Tue, 27 Oct 1998 20:03:20 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06667; Tue, 27 Oct 1998 16:58:16 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA06669 for tcp-impl-list; Tue, 27 Oct 1998 16:57:18 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA95852 for ; Tue, 27 Oct 1998 16:57:17 -0800 (PST) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06622 for ; Tue, 27 Oct 1998 16:57:16 -0800 (PST) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA181D for ; Tue, 27 Oct 1998 16:57:13 -0800 Message-ID: <36366BC9.78D993D2@ehsco.com> Date: Tue, 27 Oct 1998 16:56:42 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@cthulhu.engr.sgi.com Subject: Re: shipping implementations w/ advanced options References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Linux 2.1.x has window scaling, timestamp, and selective ack for both > IPv4 and IPv6. I must have old kernels. Neither RH 5.2 nor COL 1.3 do anything other than MSS. Thanks. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Tue Oct 27 20:03:39 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA26546 for ; Tue, 27 Oct 1998 20:03:38 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA00097; Tue, 27 Oct 1998 16:58:12 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA80107 for tcp-impl-list; Tue, 27 Oct 1998 16:56:45 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA90384 for ; Tue, 27 Oct 1998 16:56:43 -0800 (PST) mail_from (raj@cup.hp.com) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA09789 for ; Tue, 27 Oct 1998 16:56:43 -0800 (PST) mail_from (raj@cup.hp.com) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.13.104.252]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id TAA10318 for ; Tue, 27 Oct 1998 19:56:33 -0500 (EST) Received: from cup.hp.com (raj@loiter [15.13.104.252]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id QAA03865 for ; Tue, 27 Oct 1998 16:56:40 -0800 (PST) Message-ID: <36366BC8.8205404E@cup.hp.com> Date: Tue, 27 Oct 1998 16:56:40 -0800 From: Rick Jones Organization: HP 9000 Network Performance X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: TCP Implementations Subject: Re: shipping implementations w/ advanced options References: <36366756.8A3D499B@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Apart from Microsoft, is anybody shipping a TCP stack that incorporates > any of the advanced options? In particular, am looking for products that > use the Window Scale, Timestamp and Selective Acknowledgment options. Window Scale and Timestamp functionality have been shipping for HP-UX since patches for HP-UX 9.05. That goes back several years. 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@cthulhu.engr.sgi.com Tue Oct 27 20:22:44 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA26688 for ; Tue, 27 Oct 1998 20:22:31 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA06201; Tue, 27 Oct 1998 17:10:54 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA92771 for tcp-impl-list; Tue, 27 Oct 1998 17:07:34 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA84279 for ; Tue, 27 Oct 1998 17:07:32 -0800 (PST) mail_from (alan@lxorguk.ukuu.org.uk) Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA07092 for ; Tue, 27 Oct 1998 17:07:31 -0800 (PST) mail_from (alan@lxorguk.ukuu.org.uk) Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id BAA22196; Wed, 28 Oct 1998 01:07:25 GMT Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zYKxQ-0007UkC; Wed, 28 Oct 98 02:03 GMT Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: shipping implementations w/ advanced options To: ehall@ehsco.com (Eric A. Hall) Date: Wed, 28 Oct 1998 02:03:32 +0000 (GMT) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <36366BC9.78D993D2@ehsco.com> from "Eric A. Hall" at Oct 27, 98 04:56:42 pm Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > Linux 2.1.x has window scaling, timestamp, and selective ack for both > > IPv4 and IPv6. > > I must have old kernels. Neither RH 5.2 nor COL 1.3 do anything other > than MSS. Thanks. 2.1.x does the lot, 2.0.x doesnt do anything funky. 2.0.x is the stable tree until about December so vendors ship 2.0 (sensibly) Alan From owner-tcp-impl@cthulhu.engr.sgi.com Wed Oct 28 06:06:57 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA07653 for ; Wed, 28 Oct 1998 06:06:56 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA06459; Wed, 28 Oct 1998 03:02:22 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id CAA93935 for tcp-impl-list; Wed, 28 Oct 1998 02:57:48 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id CAA24868 for ; Wed, 28 Oct 1998 02:57:46 -0800 (PST) mail_from (mjo@dojo.mi.org) Received: from mail.msen.com (conch.msen.com [148.59.19.5]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id CAA03897 for ; Wed, 28 Oct 1998 02:57:45 -0800 (PST) mail_from (mjo@dojo.mi.org) Received: (from mjo@localhost) by mail.msen.com (8.8.8/8.8.5) id FAA11465 for tcp-impl@engr.sgi.com; Wed, 28 Oct 1998 05:57:45 -0500 (EST) X-Authentication-Warning: conch.msen.com: mjo set sender to mjo@dojo.mi.org using -f Subject: Re: shipping implementations w/ advanced options To: tcp-impl@cthulhu.engr.sgi.com Date: Wed, 28 Oct 1998 05:57:44 -0500 (EST) From: "Mike O'Connor" Reply-To: "Mike O'Connor" Message-Id: <981028055744.mjo@dojo.mi.org> X-Organization: :noitazinagrO-X Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk :Apart from Microsoft, is anybody shipping a TCP stack that incorporates :any of the advanced options? In particular, am looking for products that :use the Window Scale, Timestamp and Selective Acknowledgment options. There's a good summary of the information you're looking for at: http://www.psc.edu/networking/perf_tune.html -- Michael J. O'Connor | WWW: http://dojo.mi.org/~mjo/ | Email: mjo@dojo.mi.org InterNIC WHOIS: MJO | (has my PGP & Geek Code info) | Phone: +1 248-848-4481 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "You have to use imaginary numbers, like eleventeen..." -Calvin From owner-tcp-impl@cthulhu.engr.sgi.com Wed Oct 28 06:28:20 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA07693 for ; Wed, 28 Oct 1998 06:28:19 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA07746; Wed, 28 Oct 1998 03:23:31 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id DAA85130 for tcp-impl-list; Wed, 28 Oct 1998 03:20:07 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id DAA18008 for ; Wed, 28 Oct 1998 03:20:05 -0800 (PST) mail_from (jonwe@sco.COM) Received: from sco.COM (scol.london.sco.COM [150.126.1.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id DAA04467 for ; Wed, 28 Oct 1998 03:19:59 -0800 (PST) mail_from (jonwe@sco.COM) Received: from tyne.london.sco.COM(150.126.1.103), claiming to be "tyne.sco.com" via SMTP by scol.london.sco.COM, id smtpdAAAa006SY; Wed Oct 28 11:18:40 1998 Received: from dhcp3-23.pd.london.sco.com by tyne.sco.com id aa18325; 28 Oct 98 11:18 GMT Message-ID: <011401be0264$cfe30760$17037e96@barbarella.pd.london.sco.com> From: Jonathan Webb To: "Eric A. Hall" , TCP Implementations Subject: Re: shipping implementations w/ advanced options Date: Wed, 28 Oct 1998 11:15:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk The next release of SCO UnixWare7 will include windows scale and timestamp. - Jonathan ________________________________________________ Jonathan Webb Architect, Internet Engineering Group jonwe@sco.com The Santa Cruz Operation Limited Tel: +44 1923 813658 Croxley Business Park, Fax: +44 1923 813804 Hatters Lane, http://www.sco.com Watford. WD1 8YN, UK Registered in England No 2063779 ________________________________________________ -----Original Message----- From: Eric A. Hall To: TCP Implementations Date: 28 October 1998 00:44 Subject: shipping implementations w/ advanced options > >Apart from Microsoft, is anybody shipping a TCP stack that incorporates >any of the advanced options? In particular, am looking for products that >use the Window Scale, Timestamp and Selective Acknowledgment options. > >Thanks > >-- >Eric A. Hall ehall@ehsco.com >+1-650-685-0557 http://www.ehsco.com > From owner-tcp-impl@cthulhu.engr.sgi.com Wed Oct 28 10:48:55 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA10613 for ; Wed, 28 Oct 1998 10:48:54 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA09956; Wed, 28 Oct 1998 07:42:39 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA15343 for tcp-impl-list; Wed, 28 Oct 1998 07:34:29 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA12323 for ; Wed, 28 Oct 1998 07:34:26 -0800 (PST) mail_from (craigb@ftp.com) Received: from wd40.ftp.com (ftp.com [128.127.2.123]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA00782 for ; Wed, 28 Oct 1998 07:34:25 -0800 (PST) mail_from (craigb@ftp.com) Received: from MAILSERV-2HIGH.FTP.COM (ms1.ftp.com [128.127.2.93]) by wd40.ftp.com (8.8.8/8.8.8) with SMTP id KAA04961; Wed, 28 Oct 1998 10:34:24 -0500 (EST) Received: from clyde.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id KAA00708; Wed, 28 Oct 1998 10:34:23 -0500 Message-Id: <199810281534.KAA00708@MAILSERV-2HIGH.FTP.COM> X-MAPI-MessageClass: IPM To: ehall@ehsco.com, tcp-impl@cthulhu.engr.sgi.com X-Mailer: FTP Software Internet Mail 2.0 MIME-Version: 1.0 From: Craig Buffinton Subject: RE: shipping implementations w/ advanced options Date: Wed, 28 Oct 1998 10:33:58 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10613 >>Reply to your message of 10/27/98 7:43 PM > >Apart from Microsoft, is anybody shipping a TCP stack that incorporates >any of the advanced options? In particular, am looking for products that >use the Window Scale, Timestamp and Selective Acknowledgment options. > The OnNet Kernel 4.0 from FTP Software, a subsidiary of NetManage incorporates Window Scale, Timestamp and Selective Acknowledgment (RFCs 1323, 2018, 2001). It installs on Win 95/98. Other features: Winsock 2, IPv6, Mobile IP, graphic display of TCP/UDP traffic. BTW: http://www.psc.edu/networking/perf_tune.html is atleast a couple years out of date regarding our products. If you have any problems / comments please let me know. Craig Buffinton Principal Engineer FTP Software, a subsidiary of NetManage 978-946-5142 From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 07:13:56 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA00882 for ; Thu, 29 Oct 1998 07:13:55 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA06548; Thu, 29 Oct 1998 04:09:26 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id EAA07256 for tcp-impl-list; Thu, 29 Oct 1998 04:04:51 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id EAA03775; Thu, 29 Oct 1998 04:04:33 -0800 (PST) mail_from (hire@hiredhits.com) Received: from hiredhits.com (chi-qbu-nvb-vty12.as.wcom.net [209.154.105.12]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id EAB03695; Thu, 29 Oct 1998 04:03:58 -0800 (PST) mail_from (hire@hiredhits.com) DATE: Thu, 29 Oct 1998 06:16:51 -0600 Message-ID: Subject: FREE DEMO of Web Promotion Software that Puts You On Top of 1,000+ Search Engines! From: hire@hiredhits.com To: $user@cthulhu.engr.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Greetings! I thought I would take some time today to let you know about a wonderful new software package that will dramatically increase your web site's visibility. It's called The Spider, and I have been using it for several months and enjoyed a tremendous increase in my website's traffic. This software has impressed me so much that I decided to buy the reseller rights to it. And now, we are offering it on a FREE DEMO basis. Before I let you in on our secret download location, let me tell you a bit more about it. 1) 1000 + Supported Search Engines (Pro), 450 for standard edition 2) Batch Processing - allows you to take control of your website promotions - for all of your pages and sites. With a built in on-board database and batch processing, you can accurately register as many sites or pages as you like, all at once. 3) Categorized submissions - accuracy is critical when placing your site; our program recognizes and properly places you in all of our supported search engines. Don't be fooled by the competition - the shotgun approach does not work! 4) True CGI based registration - while other programs simply email your site information to search engine webmasters in the vain hope they will manually enter your information, The Search Engine Spider interacts with the server directly, custom formatting your site information for each and every supported engine. 5) Small Size, Fast Execution : The Spider is written entirely in the C programming language, and takes advantage of the true 32 bit multithreaded programming environment provided therein. It's fast: in our internal testing, the new program will perform 450 individual registrations in just under 18 minutes. Testing was done on a 28.8 dialup line. 6) Automatic Update Feature: No more weekly and monthly downloads! In an effort to keep up to date with search engine changes and updates, we have now incorporated a feature that will automate this task. Here's how it works: a.. Each time the program is loaded, it will automatically connect to our server and verify that the current search engine database is loaded on your user's machine. If it is not, it will automatically initiate a download. b. Once the download is complete (typically 20-30 seconds on a 28.8K connection), normal program operation will resume with the new database. 7) Improved Error Checking: anytime an error is generated during submission, by any user anywhere, the program updates our server with the search engine name, time and date of the error, and the nature of the error. Our resource manager for this project checks his log daily and investigates each and every error and has the ability to dynamically and instantly update the master database with the corrections. Once the correction is made, the Automatic Update Feature kicks in, distributing the updated registration database to every user worldwide the next time they use the program. To get your FREE DEMO of this amazing software, please visit: http://www.hiredhits.com/ If you would prefer us to send you a CD with The Spider, along with free demos of over 10 of our other web promotion software packages, please visit: http://www.hiredhits.com/order/process_cd.htm If you are having problems connecting to the above links, please give us a call at 773-271-8484 and we will arrange another way for you to get your FREE DEMO. Thanks again for your time and please let me know if you have any questions. Best Regards, Amy Horowitz MasterPromote, Inc. 120 Broadview Village Square Suite 315 Broadview, IL 60153 773-271-8484 hire@hiredhits.com ********* To remove yourself from this mailing list, please visit http://www.hiredhits.com and we will promptly remove your name from future mailings. Sorry for any inconvenience we may have caused From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 08:00:48 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA01090 for ; Thu, 29 Oct 1998 08:00:47 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA06302; Thu, 29 Oct 1998 04:54:01 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id EAA33446 for tcp-impl-list; Thu, 29 Oct 1998 04:49:41 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id EAA35418 for ; Thu, 29 Oct 1998 04:49:36 -0800 (PST) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: from zygorthian-space-raiders.mit.edu (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA02495 for ; Thu, 29 Oct 1998 04:49:35 -0800 (PST) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: (from mycroft@localhost) by zygorthian-space-raiders.mit.edu (8.8.8/8.8.8) id HAA10897; Thu, 29 Oct 1998 07:49:34 -0500 (EST) Date: Thu, 29 Oct 1998 07:49:34 -0500 (EST) Message-Id: <199810291249.HAA10897@zygorthian-space-raiders.mit.edu> From: "Charles M. Hannum" To: tcp-impl@cthulhu.engr.sgi.com Cc: explorer@flame.org, paul@vix.com Subject: Re: Problem with RFC 1323 and HP-UX Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk A user sent me the following tcpdump output, regarding a problem where a connection between a machine running HP-UX (hp.rc.vix.com) and NetBSD (xenon.rc.vix.com) would `freeze.' It appears that the HP box is resetting its time stamp. (Note that the time stamp on the 00:19:25.226717 packet is `less than' the time stamp on the 00:18:05.615634 packet.) This causes the PAWS check to fail on all future packets, and they are therefore dropped by the NetBSD box after sending an ACK. This would seem to be a bug in the HP-UX implementation of RFC 1323. It looks to me like HP-UX is using a 16-bit counter and updating it every .01s, whereas NetBSD is using a 32-bit counter and updating it every .5s. The granularity isn't really an issue, but it seems to me that rolling over at 16 bits is clearly wrong. For reference, the version of HP-UX in question is: HP-UX hpd280 B.11.00 A 9000/820 2006777451 two-user license Could someone verify that I'm not on drugs here? 00:18:05.445911 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: P 124148:124240(92) ack 1668 win 32768 [tos 0x10] 00:18:05.445998 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124240 win 17428 [tos 0x10] 00:18:05.589140 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: P 124240:124284(44) ack 1668 win 32768 [tos 0x10] 00:18:05.615634 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: P 124284:124328(44) ack 1668 win 32768 [tos 0x10] 00:18:05.615717 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124328 win 17476 [tos 0x10] 00:19:25.179785 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: P 1668:1688(20) ack 124328 win 17520 [tos 0x10] 00:19:25.226717 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: P 124328:124364(36) ack 1688 win 32768 [tos 0x10] 00:19:25.226806 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124328 win 17520 [tos 0x10] 00:19:25.736480 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: P 124328:124364(36) ack 1688 win 32768 [tos 0x10] 00:19:25.736560 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124328 win 17520 [tos 0x10] 00:19:26.163664 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: P 1668:1688(20) ack 124328 win 17520 [tos 0x10] 00:19:26.164082 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: . ack 1688 win 32768 [tos 0x10] 00:19:26.164148 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124328 win 17520 [tos 0x10] 00:19:26.164600 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: P 124328:124364(36) ack 1688 win 32768 [tos 0x10] 00:19:26.164662 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124328 win 17520 [tos 0x10] 00:19:26.686484 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: P 124328:124364(36) ack 1688 win 32768 [tos 0x10] 00:19:26.686556 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124328 win 17520 [tos 0x10] 00:19:28.163663 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: P 1668:1688(20) ack 124328 win 17520 [tos 0x10] 00:19:28.164080 hp.rc.vix.com.ssh > xenon.rc.vix.com.65534: . ack 1688 win 32768 [tos 0x10] 00:19:28.164145 xenon.rc.vix.com.65534 > hp.rc.vix.com.ssh: . ack 124328 win 17520 [tos 0x10] From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 11:23:44 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA05607 for ; Thu, 29 Oct 1998 11:23:43 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA08136; Thu, 29 Oct 1998 08:17:43 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA94009 for tcp-impl-list; Thu, 29 Oct 1998 08:11:29 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA17034 for ; Thu, 29 Oct 1998 08:11:27 -0800 (PST) mail_from (marquard@austin.ibm.com) Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06643 for ; Thu, 29 Oct 1998 08:11:27 -0800 (PST) mail_from (marquard@austin.ibm.com) Received: from netmail3.austin.ibm.com (netmail3.austin.ibm.com [9.53.250.99]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id KAA122146; Thu, 29 Oct 1998 10:11:23 -0600 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [9.53.150.76]) by netmail3.austin.ibm.com (8.8.5/8.8.5) with ESMTP id KAA76728; Thu, 29 Oct 1998 10:11:22 -0600 Received: (from marquard@localhost) by mojave.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) id KAA04138; Thu, 29 Oct 1998 10:11:21 -0600 To: "Eric A. Hall" Cc: TCP Implementations Subject: Re: shipping implementations w/ advanced options References: <36366756.8A3D499B@ehsco.com> From: Dave Marquardt Date: 29 Oct 1998 10:11:21 -0600 In-Reply-To: "Eric A. Hall"'s message of "Tue, 27 Oct 1998 16:37:42 -0800" Message-ID: Lines: 8 X-Mailer: Gnus v5.6.2/Emacs 19.34 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk "Eric A. Hall" writes: > Apart from Microsoft, is anybody shipping a TCP stack that incorporates > any of the advanced options? In particular, am looking for products that > use the Window Scale, Timestamp and Selective Acknowledgment options. AIX has had the window scale and timestamp options for several years. -Dave From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 12:21:22 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA07011 for ; Thu, 29 Oct 1998 12:21:21 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08730; Thu, 29 Oct 1998 09:16:28 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA50119 for tcp-impl-list; Thu, 29 Oct 1998 09:11:09 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA82470 for ; Thu, 29 Oct 1998 09:11:03 -0800 (PST) mail_from (wag@cup.hp.com) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA03906 for ; Thu, 29 Oct 1998 09:11:02 -0800 (PST) mail_from (wag@cup.hp.com) Received: from hpinwag.cup.hp.com (wag@hpinwag.cup.hp.com [15.13.108.71]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id JAA04817; Thu, 29 Oct 1998 09:11:11 -0800 (PST) Received: (from wag@localhost) by hpinwag.cup.hp.com (8.7.5/8.7.3 TIS Messaging 5.0) id JAA09958; Thu, 29 Oct 1998 09:13:46 -0800 (PST) From: William Gilliam Message-Id: <199810291713.JAA09958@hpinwag.cup.hp.com> Subject: Re: Problem with RFC 1323 and HP-UX To: root@ihack.net (Charles M. Hannum) Date: Thu, 29 Oct 1998 09:13:46 -0800 (PST) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199810291249.HAA10897@zygorthian-space-raiders.mit.edu> from "Charles M. Hannum" at Oct 29, 98 07:49:34 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Charles M. Hannum said: > A user sent me the following tcpdump output, regarding a problem where > a connection between a machine running HP-UX (hp.rc.vix.com) and > NetBSD (xenon.rc.vix.com) would `freeze.' > > It appears that the HP box is resetting its time stamp. (Note that > the time stamp on the 00:19:25.226717 packet is `less than' the time > stamp on the 00:18:05.615634 packet.) This causes the PAWS check to > fail on all future packets, and they are therefore dropped by the > NetBSD box after sending an ACK. Yes, your user has hit an old bug that was fixed quite a while ago. > This would seem to be a bug in the HP-UX implementation of RFC 1323. > It looks to me like HP-UX is using a 16-bit counter and updating it > every .01s, whereas NetBSD is using a 32-bit counter and updating it > every .5s. The granularity isn't really an issue, but it seems to me > that rolling over at 16 bits is clearly wrong. > > For reference, the version of HP-UX in question is: > > HP-UX hpd280 B.11.00 A 9000/820 2006777451 two-user license > > Could someone verify that I'm not on drugs here? I'll just say that your interpretation of the tcpdump output is correct. I'll also say that this problem was fixed shortly after HP-UX 11.0 was released, so your customer should probably grab and install the appropriate patch (the latest cumulative patch is PHNE_16645). WG From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 14:55:07 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09037 for ; Thu, 29 Oct 1998 14:55:06 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA08620; Thu, 29 Oct 1998 11:49:25 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA37250 for tcp-impl-list; Thu, 29 Oct 1998 11:42:05 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA25621 for ; Thu, 29 Oct 1998 11:42:03 -0800 (PST) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA06562 for ; Thu, 29 Oct 1998 11:41:59 -0800 (PST) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA1C12 for ; Thu, 29 Oct 1998 11:41:57 -0800 Message-ID: <3638C4FA.ED8F11EC@ehsco.com> Date: Thu, 29 Oct 1998 11:41:46 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementations Subject: MTU greater than rcv.wnd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Scenario: two PCs with 8k windows on a Token Ring network with 16k frames. What happens? Send a single 8k segment and then wait for ACK? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 15:12:10 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09208 for ; Thu, 29 Oct 1998 15:12:09 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA09360; Thu, 29 Oct 1998 12:06:33 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA13179 for tcp-impl-list; Thu, 29 Oct 1998 11:59:24 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from wli.engr.sgi.com (wli.engr.sgi.com [150.166.61.134]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA92482 for ; Thu, 29 Oct 1998 11:59:23 -0800 (PST) mail_from (wli@wli.engr.sgi.com) Received: by wli.engr.sgi.com (980205.SGI.8.8.8/940406.SGI.AUTO) id LAA07752; Thu, 29 Oct 1998 11:59:22 -0800 (PST) From: "William Li" Message-Id: <9810291159.ZM7756@wli.engr.sgi.com> Date: Thu, 29 Oct 1998 11:59:20 -0800 In-Reply-To: "Eric A. Hall" "MTU greater than rcv.wnd" (Oct 29, 11:41am) References: <3638C4FA.ED8F11EC@ehsco.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: "Eric A. Hall" , TCP Implementations Subject: Re: MTU greater than rcv.wnd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk On Oct 29, 11:41am, Eric A. Hall wrote: > Subject: MTU greater than rcv.wnd > > Scenario: two PCs with 8k windows on a Token Ring network with 16k > frames. What happens? Send a single 8k segment and then wait for ACK? if slow_start applies. It sends first MTU, and will get an ACK with updated rcv.wnd, if the rcv.wnd is 0, the persist timer kick in. -- William Li wli@sgi.com/650-933-3751 From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 15:24:48 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09320 for ; Thu, 29 Oct 1998 15:24:47 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08084; Thu, 29 Oct 1998 12:11:30 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA79331 for tcp-impl-list; Thu, 29 Oct 1998 12:07:59 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA05169 for ; Thu, 29 Oct 1998 12:07:58 -0800 (PST) mail_from (ehall@ehsco.com) Received: from Krill.EHSco.com (Krill.EHSco.com [209.31.7.48]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA00175 for ; Thu, 29 Oct 1998 12:07:09 -0800 (PST) mail_from (ehall@ehsco.com) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA1BE6 for ; Thu, 29 Oct 1998 12:07:00 -0800 Message-ID: <3638CAD9.3FB639EB@ehsco.com> Date: Thu, 29 Oct 1998 12:06:49 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: TCP Implementations Subject: Re: MTU greater than rcv.wnd References: <3638C4FA.ED8F11EC@ehsco.com> <9810291159.ZM7756@wli.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > > Scenario: two PCs with 8k windows on a Token Ring network with 16k > > frames. What happens? Send a single 8k segment and then wait for > > ACK? > > if slow_start applies. I mean beyond slow-start, not that there's any difference in this model. It seems that if the rcv.wnd is constantly smaller than the MTU, then the sender will never send more than one segment without having to stop and wait for an ACK, slow-start or not. Confirming a suspicion, Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Thu Oct 29 15:34:04 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09471 for ; Thu, 29 Oct 1998 15:34:03 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA22758; Thu, 29 Oct 1998 13:33:57 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by assateague.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA22754; Thu, 29 Oct 1998 13:33:55 -0500 (EST) Received: from guns.lerc.nasa.gov by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA08910; Thu, 29 Oct 1998 13:33:55 -0500 (EST) Message-Id: <199810291833.NAA08910@guns.lerc.nasa.gov> To: tcp-impl@lerc.nasa.gov Cc: "Vern Paxson" From: Mark Allman Reply-To: mallman@lerc.nasa.gov Subject: new mailing list location Organization: Late Night Hackers, NASA Lewis, Cleveland, Ohio Song-of-the-Day: Lodi Date: Thu, 29 Oct 1998 13:33:54 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk TCP-impl Folks: The tcp-impl mailing list is moving to NASA LeRC as of right now. As of several minutes ago, the list of people on the mailing list was identical at LeRC and SGI. So, please use "tcp-impl@lerc.nasa.gov" from now on. The list archive is available both as a flat file and a hypermail web index from the following URL: http://tcp-impl.lerc.nasa.gov/tcp-impl I'd like to thank SGI for hosting the mailing list and archive at their site for a long time. We very much appreciate their efforts! The move is simply an attempt to make things a little easier for Vern and I to manage. allman --- http://gigahertz.lerc.nasa.gov/~mallman/ From owner-tcp-impl@cthulhu.engr.sgi.com Thu Oct 29 15:36:21 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA09504 for ; Thu, 29 Oct 1998 15:36:18 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07829; Thu, 29 Oct 1998 12:30:24 -0800 (PST) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA35542 for tcp-impl-list; Thu, 29 Oct 1998 12:26:38 -0800 (PST) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA91860 for ; Thu, 29 Oct 1998 12:26:37 -0800 (PST) mail_from (artshel@microsoft.com) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA00857 for ; Thu, 29 Oct 1998 12:26:36 -0800 (PST) mail_from (artshel@microsoft.com) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Thu, 29 Oct 1998 12:26:35 -0800 Message-ID: <3FF8121C9B6DD111812100805F31FC0D048CCE39@RED-MSG-59> From: Art Shelest To: "'Eric A. Hall'" Cc: TCP Implementations Subject: RE: MTU greater than rcv.wnd Date: Thu, 29 Oct 1998 12:26:31 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Will adjusting MSS or MTU down improve the performance? With any size MSS, you still can only send up to rwin bytes before stopping and waiting for an ACK. After slow-start, you have: Large MTU: send 8KB in one chunk, then wait for an ACK. Small MTU: send 8KB in small pieces, then wait for an ACK. Small MTU will reduce performance somewhat because of overhead. _Art. -----Original Message----- From: Eric A. Hall [mailto:ehall@ehsco.com] Sent: Thursday, October 29, 1998 12:07 PM Cc: TCP Implementations Subject: Re: MTU greater than rcv.wnd > > Scenario: two PCs with 8k windows on a Token Ring network with 16k > > frames. What happens? Send a single 8k segment and then wait for > > ACK? > > if slow_start applies. I mean beyond slow-start, not that there's any difference in this model. It seems that if the rcv.wnd is constantly smaller than the MTU, then the sender will never send more than one segment without having to stop and wait for an ACK, slow-start or not. Confirming a suspicion, Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Thu Oct 29 16:25:06 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09935 for ; Thu, 29 Oct 1998 16:25:06 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id OAA02640; Thu, 29 Oct 1998 14:58:23 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from atlrel2.hp.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id OAA02632; Thu, 29 Oct 1998 14:58:20 -0500 (EST) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.13.104.252]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id OAA10240 for ; Thu, 29 Oct 1998 14:58:10 -0500 (EST) Received: from cup.hp.com (raj@loiter [15.13.104.252]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id LAA07980 for ; Thu, 29 Oct 1998 11:58:17 -0800 (PST) Message-ID: <3638C8D9.CC2DA322@cup.hp.com> Date: Thu, 29 Oct 1998 11:58:17 -0800 From: Rick Jones Organization: SNSL X-Mailer: Mozilla 4.5 [en] (X11; U; HP-UX B.10.20 9000/735) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementations Subject: Re: MTU greater than rcv.wnd References: <3638C4FA.ED8F11EC@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Scenario: two PCs with 8k windows on a Token Ring network with 16k > frames. What happens? Send a single 8k segment and then wait for ACK? That would be my guess as to one correct behaviour. HP-UX is supposed to be coded such that for an 8K window a 4K MSS will be negotiated. In general, HP-UX will negotiate an MSS that is no more than 1/2 the receive window at time of establishment. 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 Oct 29 17:23:18 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA10242 for ; Thu, 29 Oct 1998 17:23:18 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA10734; Thu, 29 Oct 1998 15:53:46 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA10730; Thu, 29 Oct 1998 15:53:44 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA1C6F for ; Thu, 29 Oct 1998 12:53:41 -0800 Message-ID: <3638D5CA.F99E1844@ehsco.com> Date: Thu, 29 Oct 1998 12:53:30 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: TCP Implementations Subject: Re: MTU greater than rcv.wnd References: <3FF8121C9B6DD111812100805F31FC0D048CCE39@RED-MSG-59> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Small MTU will reduce performance somewhat because of overhead. Right. Obviously the performance solution to this problem is to increase thw window size on the client. > With any size MSS, you still can only send up to rwin bytes > before stopping and waiting for an ACK. There are other elements here besides performance. In particular, I can imagine a situation where SWS avoidance causes problems if the rcv.win and MTU are dramatically different. It would be possible to code yourself into a corner, although I doubt anybody's made this mistake. Also, as pointed out from a Sun person, Solaris (as a recipient) will scale the rcv.wnd size so that it's substantially larger than the MTU, keeping this from ever happening in the first place. Neat solution. Just an interesting scenario. Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Thu Oct 29 17:34:25 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA10320 for ; Thu, 29 Oct 1998 17:34:25 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA11908; Thu, 29 Oct 1998 16:01:51 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from mercury.Sun.COM (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA11895; Thu, 29 Oct 1998 16:01:48 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA09152 for ; Thu, 29 Oct 1998 13:01:46 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id NAA24027 for ; Thu, 29 Oct 1998 13:01:43 -0800 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id NAA13483 for ; Thu, 29 Oct 1998 13:01:44 -0800 (PST) Date: Thu, 29 Oct 1998 13:01:43 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: RE: MTU greater than rcv.wnd To: tcp-impl@lerc.nasa.gov In-Reply-To: "Your message with ID" <3FF8121C9B6DD111812100805F31FC0D048CCE39@RED-MSG-59> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Small MTU will reduce performance somewhat because of overhead. In this particular case, receive window is less than 1*MTU, smaller negotiated MSS may actually help. With big MSS, if a segment is lost, the only way to recover that is a timeout. But if MSS is smaller, multiple segments can be sent. This means that fast retransmit can happen. Since RTO is usually bigger than RTT (in BSD's case, it can be much bigger), this definitely helps in recovery. But the MSS has to be small enough to allow at least 4 segments to be sent in a window. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@lerc.nasa.gov Thu Oct 29 18:19:39 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA10511 for ; Thu, 29 Oct 1998 18:19:39 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA17341; Thu, 29 Oct 1998 16:44:57 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from sgi.sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA17336; Thu, 29 Oct 1998 16:44:54 -0500 (EST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA07574 for <@sgi.engr.sgi.com:tcp-impl@lerc.nasa.gov>; Thu, 29 Oct 1998 13:44:53 -0800 (PST) mail_from (rags@bapuji.engr.sgi.com) Received: from bapuji.engr.sgi.com (bapuji.engr.sgi.com [150.166.61.13]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA85564 for <@cthulhu.engr.sgi.com:tcp-impl@lerc.nasa.gov>; Thu, 29 Oct 1998 13:44:52 -0800 (PST) mail_from (rags@bapuji.engr.sgi.com) Received: (from rags@localhost) by bapuji.engr.sgi.com (980327.SGI.8.8.8/970903.SGI.AUTOCF) id NAA04291; Thu, 29 Oct 1998 13:44:26 -0800 (PST) From: rags@bapuji.engr.sgi.com (Raghu Mallena) Message-Id: <199810292144.NAA04291@bapuji.engr.sgi.com> Subject: Is it really exponential? To: tcp-impl@lerc.nasa.gov Date: Thu, 29 Oct 1998 13:44:26 -0800 (PST) Cc: rags@bapuji.engr.sgi.com (Raghu Mallena) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I was looking at some traces and noticed that the Slow Start algorithm opens the window size by *one* segment size everytime an ACK is received. This is how it was described in Van Jacobson's "Congestion Avoidance and Control" SIGCOM'98 paper. Is there any reason why it is designed this way as opposed to opening the window by the amount of data that got acked? With Delayed Ack in effect, the one-segment growth scheme would increase the window in roughly 2^(x/2) way as opposed to a true 2^x growth. Basically, RTT*logW (where W is window size in segments) being the time to reach steady state as computed in VJ's paper will not be true for Delayed Ack. And this will be even worse for the stacks that are lazy about sending Acks i.e send one Ack for more than 2 packets (please... i dont mean to re-start last weeks discussion on this subject) However, a simple one-line fix to open the window by the amount of data acked (ack - snd_una) should work well always. The window would still open exponentially and the time to reach full window size would still be in the order of RTT*logW, approximately. Any reason why it shouldnt be done this way? - raghu --- Raghu Mallena Silicon Graphics From owner-tcp-impl@lerc.nasa.gov Thu Oct 29 18:20:13 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA10526 for ; Thu, 29 Oct 1998 18:20:13 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id QAA18826; Thu, 29 Oct 1998 16:59:41 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by assateague.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id QAA18815; Thu, 29 Oct 1998 16:59:39 -0500 (EST) Received: from guns.lerc.nasa.gov by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id QAA11149; Thu, 29 Oct 1998 16:59:38 -0500 (EST) Message-Id: <199810292159.QAA11149@guns.lerc.nasa.gov> To: rags@bapuji.engr.sgi.com (Raghu Mallena) From: Mark Allman Reply-To: mallman@lerc.nasa.gov cc: tcp-impl@lerc.nasa.gov Subject: Re: Is it really exponential? Organization: Late Night Hackers, NASA LeRC, Cleveland, Ohio Song-of-the-Day: Lodi Date: Thu, 29 Oct 1998 16:59:38 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > However, a simple one-line fix to open the window by the amount of > data acked (ack - snd_una) should work well always. The window > would still open exponentially and the time to reach full window > size would still be in the order of RTT*logW, approximately. > > Any reason why it shouldnt be done this way? I think except for the "work well always" part you are right. I think generally the fix you suggest works well. It lowers the transfer time (of short connections especially). The size of the burst of segments in response to an ACK is incraesed a little and therefore, there can be a slight increase in loss. The real problem comes into play in reno-style recovery, where ACKs for large numbers of un-ACKed data can come in during a slow start after an RTO timeout. In this case, you very much *do not* want to generate a burst that is basically twice what we generate now. So, a reasonable approach (I think!) is to use a ``limited byte counting''. Basically, you should increase the window by the number of bytes ACKed, up to some limit like 2 segments. So, when responding to a correctly behaving delayed ACK receiver you are getting better growth. But, you are limiting the size of the burst that any ACK can generate to one more segment than is currently allowed in the case of receiving stretch ACK (because of a buggy delayed ACK implementation or ACK loss). That seems to be a good way to do things to me. For more information, please see my paper on this topic... Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998. http://gigahertz.lerc.nasa.gov/~mallman/papers/acks.ps allman From owner-tcp-impl@lerc.nasa.gov Thu Oct 29 18:23:32 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA10538 for ; Thu, 29 Oct 1998 18:23:31 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id RAA19660; Thu, 29 Oct 1998 17:03:41 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by assateague.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA19648; Thu, 29 Oct 1998 17:03:39 -0500 (EST) Received: from guns.lerc.nasa.gov by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id RAA11210; Thu, 29 Oct 1998 17:03:38 -0500 (EST) Message-Id: <199810292203.RAA11210@guns.lerc.nasa.gov> To: rags@bapuji.engr.sgi.com (Raghu Mallena) From: Mark Allman Reply-To: mallman@lerc.nasa.gov cc: tcp-impl@lerc.nasa.gov Subject: Re: Is it really exponential? Organization: Late Night Hackers, NASA LeRC, Cleveland, Ohio Song-of-the-Day: Lodi Date: Thu, 29 Oct 1998 17:03:38 -0500 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Any reason why it shouldnt be done this way? Oh, so the last message was with my research hat on... I should also use my IETF hat and point out that byte counting should not be used during slow start because the spec (2001, 2001.bis) intentionally does not allow it. The feeling is that this change makes TCP more aggressive and we need to study and understand this change before we unleash it on the network. allman From owner-tcp-impl@lerc.nasa.gov Sat Oct 31 15:34:06 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA12721 for ; Sat, 31 Oct 1998 15:34:06 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id NAA04980; Sat, 31 Oct 1998 13:38:23 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from Krill.EHSco.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id NAA04976; Sat, 31 Oct 1998 13:38:20 -0500 (EST) Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45]) by Krill.EHSco.com (Netscape Messaging Server 3.5) with ESMTP id AAA1F46 for ; Sat, 31 Oct 1998 10:38:18 -0800 Message-ID: <363B5918.433881BA@ehsco.com> Date: Sat, 31 Oct 1998 10:38:16 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementations Subject: old TCP options Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Did anybody ever make use of any of the expiremental or legacy TCP options, such as NAK, Echo and Alternative Checksums? Are these options seen much today, still? Thanks -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Sat Oct 31 16:49:09 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13274 for ; Sat, 31 Oct 1998 16:49:08 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA10870; Sat, 31 Oct 1998 15:10:04 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from aland.bbn.com (fw01.lerc.nasa.gov [139.88.145.14]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA10866; Sat, 31 Oct 1998 15:10:02 -0500 (EST) Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id MAA03323; Sat, 31 Oct 1998 12:09:59 -0800 (PST) Message-Id: <199810312009.MAA03323@aland.bbn.com> To: "Eric A. Hall" cc: TCP Implementations Subject: Re: old TCP options In-reply-to: Your message of "Sat, 31 Oct 1998 10:38:16 PST." <363B5918.433881BA@ehsco.com> Date: Sat, 31 Oct 1998 12:09:59 -0800 From: Craig Partridge Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Alternative Checksum was, I believe, never used or even implemented. It was devised as an example during a discussion about whether one could use a different checksum. Craig In message <363B5918.433881BA@ehsco.com>, "Eric A. Hall" writes: > >Did anybody ever make use of any of the expiremental or legacy TCP >options, such as NAK, Echo and Alternative Checksums? Are these options >seen much today, still? > >Thanks > >-- >Eric A. Hall ehall@ehsco.com >+1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Sat Oct 31 16:58:53 1998 Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13339 for ; Sat, 31 Oct 1998 16:58:52 -0500 (EST) Received: (listserv@localhost) by assateague.lerc.nasa.gov (NASA LeRC 8.7.4.1/2.01-main) id PAA13487; Sat, 31 Oct 1998 15:49:39 -0500 (EST) X-Authentication-Warning: assateague.lerc.nasa.gov: listserv set sender to owner-tcp-impl@lerc.nasa.gov using -f Received: from revnet4.revnet.com (fw04.lerc.nasa.gov [139.88.145.19]) by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA13476; Sat, 31 Oct 1998 15:49:35 -0500 (EST) From: scj2@gs4.revnet.com Received: from gs4.revnet.com (gs4.revnet.com [198.51.35.84]) by revnet4.revnet.com (8.8.7/8.8.7) with SMTP id OAA31179; Sat, 31 Oct 1998 14:42:43 -0600 Message-Id: <199810312042.OAA31179@revnet4.revnet.com> To: scj2@gs4.revnet.com Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent Date: Sat, 31 Oct 1998 14:47:10 -0600 Originator: scj2@gs4.revnet.com X-Mailer: GroupMaster X-Mailer-Version: 1.5 X-GroupMasterUser: Revnet Express Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Please open the following message in your web browser http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML ____________________________________________________________ International Shoe Manufacturing Corp Update: International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage financing to begin full-scale production at its plants in India. The $4.75 million is being used to purchase the final equipment needed to begin production at the company’s existing plant in India. With equipment in place, the company projects net profits of over $25 million a year within two years. The company stated that the financing will be followed up by a $9 million dollar IPO in India, anticipated for March 1999. The IPO will be handled by underwriters in India, and will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the IPO will pay off the $4.75 million dollar financing. The balance will be used for the acquisition of additional shoe manufacturing. ISHO is in the business of manufacturing athletic footwear for the world’s leading shoe companies. It owns a 23,000-square-foot plant located in the protected “free trade zone” in Noida, just outside of New Delhi, India, where skilled labor is plentiful and very inexpensive. The Indian government recently developed new economic policy to attract foreign investment that is export-oriented, and could employ large numbers of people. ISM is the only athletic shoe manufacturer in India directed toward the international market. It currently has contracts with Adidas and The Pentland Group. These two companies have agreed to purchase all the shoes ISM can manufacture. The athletic shoe industry is estimated at $14.25 billion a year. The world’s leading shoe companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design and marketing organizations that spend hundreds of millions of dollars a year getting their products sold. They then rely on others to manufacture to their specifications. Almost, if not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of millions of dollars spent on advertising by the name-brand companies. The result is an open purchase order where such manufacturers literally can sell every pair of shoes they can produce. A business like this lends itself to being privately held due to the large cash flow allowing for internal financing. International Shoe Manufacturing Corp. is the only company known to exist that offers a public investor the opportunity to own a share of this highly lucrative business in a pure investment play. For inquiries please contact the office of the director of investor relations toll free at: 877-ISM-CORP (877-476-2677) or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately. Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752 Please visit ISM’s web site at www.ismcorp.net Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of 1995. Forward-looking statements involve known and unknown risks and uncertainties which may cause the company’s actual results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things, product price volatility, product demand, market competition, risk inherent in the company’s domestic and international operations, imprecision in estimating product reserves and the company’s ability to replace and expand its holdings. ____________________________________________________________ Unsubscribe or access your membership settings at: http://gs4.revnet.com/GMG/ctrlpanel/0/79