From owner-tcp-impl@lerc.nasa.gov Mon Jun 7 19:09:19 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02619 for ; Mon, 7 Jun 1999 19:09:19 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA04905 for tcp-impl-outgoing; Mon, 7 Jun 1999 15:53:46 -0400 (EDT) Received: from mailhost.iprg.nokia.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA04885 for ; Mon, 7 Jun 1999 15:53:43 -0400 (EDT) Received: from vienna.iprg.nokia.com (vienna.iprg.nokia.com [205.226.11.35]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id MAA25241 for ; Mon, 7 Jun 1999 12:53:39 -0700 (PDT) From: Fred Bauer Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id MAA13252 for tcp-impl@lerc.nasa.gov; Mon, 7 Jun 1999 12:53:36 -0700 (PDT) Date: Mon, 7 Jun 1999 12:53:36 -0700 (PDT) Message-Id: <199906071953.MAA13252@vienna.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000 Call For Papers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk INFOCOM 2000 CALL FOR PAPERS IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom (general) http://www.comsoc.org/confs/infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies ******************************************* * * * PAPER SUBMISSION ENDS ON JULY 1, 1999 * * * * Submission deadlines are strict! * * * * To avoid last minute problems, * * authors are encouraged to submit * * their papers well in advance of the * * deadline. * * * ******************************************* SCOPE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. The conference is sponsored by the technical committees on computer communications of the IEEE Communications and Computers Societies. The Infocom 2000 organizing committee is soliciting original papers describing state-of-the-art research and development in all areas of computer networking and data communications. Topics of interest include, but are not limited to, the following: Active Networks Network Management and Control BISDN and ATM Network Reliability Billing and Pricing Network Restoration Congestion and Admission Control Network Signaling Distributed Network Algorithms Network Standards High-Speed Network Protocols Network and Protocol Performance Integrated Control of Networks Optical Networks Intelligent Networks Personal Communications Systems Internet Photonic Switching Internetworking Protocol Design and Analysis Lightwave Networks Quality of Service Mobility Routing and Routing Protocols Multicast/Broadcast Algorithms Security and Privacy Multimedia Protocols Switch Architectures Multimedia Terminals and Systems Testbeds and Measurements Multiple Access Traffic Management and Control Network Architectures Video Networking Network Design and Planning Wireless Networks and Protocols PAPER SUBMISSION ================ Papers must be submitted electronically in the manner and format detailed below. Authors for whom this presents a severe problem should contact one of the technical program committee co-chairs to discuss alternatives. Papers must be formatted according to the IEEE standard format except for the font size, which must be 11pt. To make it easy to adhere to the formatting standard we offer templates and samples for LaTex, MSWord, and FrameMaker (consult at the web pages referenced on top of this message). Submission must be in PDF. However, the committee will also accept Postscript from Latex, FrameMaker, or MSWord source file. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. (Postscript output from MSWord typically does not work on non-Microsoft platforms. The use of the Apple LaserWriter II printer driver is strongly recommended). The above formatted papers can be submitted in a compressed form (gzip, zip, compress). Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, ----------------------------------------------------- |papers with more than 11 pages will not be reviewed| ----------------------------------------------------- (this is roughly equivalent to 20 double-spaced pages). Papers must be submitted electronically using the Web site at . This web page contains exact and detailed instructions. The submission process includes providing detailed contact information. To save space authors can omit this information from the paper itself. Authors will receive an immediate notification of the successful receipt of the file containing their paper. Subsequently, a formal notification will be sent after verifying that the paper can be printed successfully. --------------------------------------------------------- |Submissions will only be accepted until July 1st, 1999.| --------------------------------------------------------- Submission deadlines are strict! Papers that have been improperly submitted or improperly formatted by the submission date will not be considered. To avoid last minute problems, authors are encouraged to submit their papers well in advance of the deadline. THE REVIEW PROCESS ================== Each paper will typically be reviewed by three independent reviewers, whose reviews will be relayed to the corresponding author. To facilitate the review process authors will be asked to classify the paper according to a list of categories so that the most appropriate reviewers handle the paper. This year a new step will be introduced into the process whereby authors will have a chance to provide a limited rebuttal on the reviews before the program committee makes its final decision. TRAVEL GRANTS ============= Limited travel assistance to students, post-docs and junior faculty for defraying some of the costs of presenting a paper in the conference will be available. Please refer to the conference web sites for further details later this year. IMPORTANT DATES =============== Complete paper due April 1 - July 1, 1999 Notification of acceptance October 31, 1999 Final version due December 3, 1999 PROGRAM COMMITTEE CO-CHAIRS [infocom@comnet9.technion.ac.il] =========================== Raphael Rom, Technion, Israel Henning Schulzrinne, Columbia University, USA From owner-tcp-impl@lerc.nasa.gov Wed Jun 9 04:52:16 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22092 for ; Wed, 9 Jun 1999 04:52:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA02703 for tcp-impl-outgoing; Wed, 9 Jun 1999 01:44:31 -0400 (EDT) Received: from mailcarrier.snv1.gctr.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA02697 for ; Wed, 9 Jun 1999 01:44:30 -0400 (EDT) Received: from pobox.snv1.gctr.net (pobox.snv1.gctr.net [204.71.194.242]) by mailcarrier.snv1.gctr.net (8.9.3/8.9.0) with ESMTP id FAA27779; Wed, 9 Jun 1999 05:44:28 GMT Received: from vauxhall.isi.net (vauxhall.isi.net [204.71.194.131]) by pobox.snv1.gctr.net (8.9.1/8.9.1) with ESMTP id FAA11831; Wed, 9 Jun 1999 05:44:28 GMT Received: (from alan@localhost) by vauxhall.isi.net (8.8.8/8.8.8) id WAA03692; Tue, 8 Jun 1999 22:45:11 -0700 (PDT) Date: Tue, 8 Jun 1999 22:45:11 -0700 From: Alan Hannan To: nanog@merit.edu, tcp-impl@lerc.nasa.gov Subject: TOS issues with non RFC compliant TCP stacks Message-ID: <19990608224510.B3451@globalcenter.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Howdy. We have learned of a problem with non RFC compliant users of the Internet. We believe this problem will be of interest to NANOG and tcp-impl WG participants. We would like to involve a larger body so that: - more people are aware of this issue - ISPs can more quickly handle potential problems when they arise - we can learn about additional IP stacks that have this problem - alternate opinions can be presented that may argue this behaviour is appropriate, and RFC compliant It has come to our attention that a notable fraction of the internet client community uses a TCP stack which is not RFC compliant, as far as we can determine. Certain versions of MacTCP send a RST when they receive SYN ACK packets of TOS!=0. I assume there are other TCP implementations which also have this behaviour. This concerns us, as we would like to see IP transport utilize TOS markings for the growth of the Internet. In discussions with several vendors, colleagues, and review of RFCs, the following phrase seems most applicable, from Postel in RFC 793: ------------------------ = ------------------------ 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. ------------------------ = ------------------------ Open Transport (an alternate, Apple supported stack) follows this principle and works well. Additionally, a patch is available on the net for MacTCP (see below). So, the empirical part: We implemented TOS bit-setting for the purpose of tracking traffic flows and traffic levels. For an entirely arbitrary reason, we chose TOS=5 for the default of traffic. We found that MacTCP ceased functioning. The MacTCP stack would initiate an RST when receiving SYN ACK packets with a TOS=5, as the SYN packets had a TOS=0. Therefore, all TCP sessions would fail. We can quite simply work around our customer's problem by setting TOS=0 on all traffic to/from the customer interface. However, any traffic towards nonFGC customer's [ie, from our interconnection partners] will not be modified. Therefore, they are also vulnerable to this problem. Because of a hardware implementation limitation on most of routers, INbound TOS setting is efficient, while OUTbound TOS setting is inefficient. So it is difficult for us to modify the TOS settings leaving our network. It would be moderately trivial for most interconnection partners to modify the TOS settings on input. This is a path we plan to pursue. As it turns out, this is an archaically (sp) known problem, with a pre-existing patch. Information about this patch for MacTCP exists at: http://www.mactcp.org.nz/mactcp.html At this time we do not modify TCP TOS bits. Once we have more information we intend to move forward with the TOS modifications, after notifying our InterConnection partners and customers of potential impact. Thank you for your consideration. -alan From owner-tcp-impl@lerc.nasa.gov Wed Jun 9 07:19:23 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23096 for ; Wed, 9 Jun 1999 07:19:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA06031 for tcp-impl-outgoing; Wed, 9 Jun 1999 03:57:57 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA06027 for ; Wed, 9 Jun 1999 03:57:55 -0400 (EDT) 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 AAA13675; Wed, 9 Jun 1999 00:57:53 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id AAA01888; Wed, 9 Jun 1999 00:57:53 -0700 (PDT) Date: Wed, 9 Jun 1999 00:57:53 -0700 (PDT) Message-Id: <199906090757.AAA01888@rum.isi.edu> To: alan@globalcenter.net, nanog@merit.edu, tcp-impl@lerc.nasa.gov Subject: Re: TOS issues with non RFC compliant TCP stacks Cc: touch@ISI.EDU Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From owner-tcp-impl@lerc.nasa.gov Tue Jun 8 23:27:07 1999 > Date: Tue, 8 Jun 1999 22:45:11 -0700 > From: Alan Hannan > To: nanog@merit.edu, tcp-impl@lerc.nasa.gov > Subject: TOS issues with non RFC compliant TCP stacks ... > It has come to our attention that a notable fraction of the > internet client community uses a TCP stack which is not RFC > compliant, as far as we can determine. > > Certain versions of MacTCP send a RST when they receive SYN ACK > packets of TOS!=0. Far as I have found, the spec (STD7) says that TOS is a TCP per-connection property (page 12). On page 36 it appears to clearly state that (case 2): terminated then). If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent. > So, the empirical part: We implemented TOS bit-setting for the > purpose of tracking traffic flows and traffic levels. For an > entirely arbitrary reason, we chose TOS=5 for the default of > traffic. We found that MacTCP ceased functioning. The MacTCP > stack would initiate an RST when receiving SYN ACK packets with > a TOS=5, as the SYN packets had a TOS=0. Therefore, all TCP > sessions would fail. Granted, this is a first cut read, but wouldn't this appear to indicate that NOT sending the RST is the violation of the spec? Can you clarify? Joe From owner-tcp-impl@lerc.nasa.gov Wed Jun 9 13:58:17 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00009 for ; Wed, 9 Jun 1999 13:58:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA03158 for tcp-impl-outgoing; Wed, 9 Jun 1999 10:49:01 -0400 (EDT) Received: from mail.pudikgraphics.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA03150 for ; Wed, 9 Jun 1999 10:48:59 -0400 (EDT) Received: from pudikgraphics.com ([206.151.190.196]) by mail.pudikgraphics.com (Netscape Messaging Server 3.5) with ESMTP id 462 for ; Wed, 9 Jun 1999 09:48:52 -0500 Message-ID: <375E7D27.17A4D109@pudikgraphics.com> Date: Wed, 09 Jun 1999 09:41:43 -0500 From: "Paul Simon" Organization: Pudik Graphics, Inc. X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en-US MIME-Version: 1.0 To: tcp-impl@lerc.nasa.gov Subject: SUBNETS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Can any one explain the /subnet and number of IP's in each subnet block? -- Thanks, Paul T. Simon Pudik Graphics, Inc. www.pudikgraphics.com From owner-tcp-impl@lerc.nasa.gov Wed Jun 9 17:14:20 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03648 for ; Wed, 9 Jun 1999 17:14:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA29114 for tcp-impl-outgoing; Wed, 9 Jun 1999 14:34:08 -0400 (EDT) Received: from hotmail.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA27186 for ; Wed, 9 Jun 1999 14:17:54 -0400 (EDT) Received: (qmail 20115 invoked by uid 0); 9 Jun 1999 18:09:47 -0000 Message-ID: <19990609180947.20114.qmail@hotmail.com> Received: from 192.31.7.244 by wy1lg.hotmail.com with HTTP; Wed, 09 Jun 1999 11:09:46 PDT X-Originating-IP: [192.31.7.244] From: Sunil Kumar To: psimon@pudikgraphics.com, tcp-impl@lerc.nasa.gov Subject: Re: SUBNETS Date: Wed, 09 Jun 1999 18:09:46 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello Simon IP address consists of 4 octets ranging from 0.0.0.0 to 255.255.255.255 This range is further divided into different classes to make certain things easier Class A: First octet can be between 0 to 126 (2 power 24 - 2 IP add) Class B: First octet can be between 128 to 191(2 power 16 - 2 IP add) Class C: First octet can be between 192 to 223(2 power 8 -2 IP add) Class D: First octet can be between 224 to 239 (multicast) Class E: remaining address However defining IP addresses in this way restricts the allocation of IP address in terms of numbers of IP addresses needed. Like if you need 10000 IP addresses for ur organization, you have to take Class B address, since class C address can only have 254 addresses . But while taking Class B address, you are wasting 55000 IP addresses as Class B can have near to 65000 IP addresses. Here comes the term of subnets. We divide each class based networks into different subnets so that do use maximum IP addresses. Like if you need 1000 IP address. A class B network can be subneted into 64 subnetworks by using 6 bit subnet mask each having 1024 IP address. Note u can only subnet on power of 2. One of the 1024 subnetwork is allocated to you and remaining can be used by other organizations. Maximum ip address for a particular subnetwork is maximum possible addresses -2. Since u cant use ALL one's and ALL zeros. So in this case u can use 1022 IP addresses. Hope it clear a bit Regards Sunil Kumar >From: "Paul Simon" >To: tcp-impl@lerc.nasa.gov >Subject: SUBNETS >Date: Wed, 09 Jun 1999 09:41:43 -0500 >MIME-Version: 1.0 >From owner-tcp-impl@lerc.nasa.gov Wed Jun 09 10:54:23 1999 >Received: from [139.88.112.33] by hotmail.com (1.5) with SMTP id >MHotMailB927F53E013FD10170768B587021CCEE0; Wed Jun 09 10:54:23 1999 >Received: (from listserv@localhost)by lombok-fi.lerc.nasa.gov (NASA LeRC >8.9.1.1/8.9.1) id KAA03158for tcp-impl-outgoing; Wed, 9 Jun 1999 10:49:01 >-0400 (EDT) >Received: from mail.pudikgraphics.com (fw01.lerc.nasa.gov >[139.88.145.14])by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with >ESMTP id KAA03150for ; Wed, 9 Jun 1999 10:48:59 >-0400 (EDT) >Received: from pudikgraphics.com ([206.151.190.196]) by >mail.pudikgraphics.com (Netscape Messaging Server 3.5) with ESMTP >id 462 for ; Wed, 9 Jun 1999 09:48:52 >-0500 >Message-ID: <375E7D27.17A4D109@pudikgraphics.com> >Organization: Pudik Graphics, Inc. >X-Mailer: Mozilla 4.6 [en] (Win95; I) >X-Accept-Language: en-US >Sender: owner-tcp-impl@lerc.nasa.gov >Precedence: bulk > >Can any one explain the /subnet and number of IP's in each subnet block? > >-- > Thanks, > Paul T. Simon > Pudik Graphics, Inc. > www.pudikgraphics.com > > _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-tcp-impl@lerc.nasa.gov Thu Jun 10 01:24:22 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13987 for ; Thu, 10 Jun 1999 01:24:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA28151 for tcp-impl-outgoing; Wed, 9 Jun 1999 22:13:08 -0400 (EDT) Received: from mail.ocs.com.au (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA28145 for ; Wed, 9 Jun 1999 22:13:03 -0400 (EDT) Received: (qmail 27961 invoked by uid 502); 10 Jun 1999 02:12:58 -0000 Message-ID: <19990610021258.27960.qmail@mail.ocs.com.au> Received: (qmail 27949 invoked from network); 10 Jun 1999 02:12:57 -0000 Received: from ocs4.ocs-net (192.168.255.4) by mail.ocs.com.au with SMTP; 10 Jun 1999 02:12:57 -0000 X-Mailer: exmh version 2.0.2 From: Keith Owens To: "Paul Simon" cc: tcp-impl@lerc.nasa.gov Subject: Re: SUBNETS In-reply-to: Your message of "Wed, 09 Jun 1999 09:41:43 EST." <375E7D27.17A4D109@pudikgraphics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Jun 1999 12:12:56 +1000 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Wed, 09 Jun 1999 09:41:43 -0500, "Paul Simon" wrote: >Can any one explain the /subnet and number of IP's in each subnet block? ftp://ftp.ocs.com.au/pub/ipcalc.pl.gz automates this for you. # ipcalc.pl 192.168.255.17/30 IP address 192 . 168 . 255 . 17 / 30 192.168.255.17/30 Netmask bits 11111111 11111111 11111111 11111100 Netmask bytes 255 . 255 . 255 . 252 255.255.255.252 Address bits 11000000 10101000 11111111 00010001 Network 192 . 168 . 255 . 16 192.168.255.16 Broadcast 192 . 168 . 255 . 19 192.168.255.19 First Host 192 . 168 . 255 . 17 192.168.255.17 Last Host 192 . 168 . 255 . 18 192.168.255.18 Total Hosts 2 PTR 17.255.168.192.in-addr.arpa IP Address (hex) C0A8FF11 From owner-tcp-impl@lerc.nasa.gov Fri Jun 18 01:52:47 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13577 for ; Fri, 18 Jun 1999 01:52:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA28852 for tcp-impl-outgoing; Thu, 17 Jun 1999 22:26:58 -0400 (EDT) Received: from ns1.siara.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA28848 for ; Thu, 17 Jun 1999 22:26:56 -0400 (EDT) Received: from siara-serv1. by ns1.siara.com via smtpd (for fw01.lerc.nasa.gov [139.88.145.14]) with SMTP; 18 Jun 1999 02:56:47 UT Received: from red.mtv.siara.com by siara.com with smtp id m10uoMM-001FIEC; Thu, 17 Jun 1999 19:26:26 -0700 (PDT) Received: from red.mtv.siara.com by red.mtv.siara.com (8.8.7) id TAA01525; Thu, 17 Jun 1999 19:27:13 -0700 (PDT) Message-Id: <199906180227.TAA01525@red.mtv.siara.com> X-Mailer: exmh version 2.0.2 2/24/98 To: tcp-impl@grc.nasa.gov Subject: Nagle -- again Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jun 1999 19:27:13 -0700 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk All and sundry, We last talked about this in March. The I-D i had submitted last fall has either expired or is about to expire. So... My plan is to submit the updated version of my I-D (that i sent to this list a long time ago -- Fri, 26 Feb 1999) to the Internet Drafts directory (soon, given that the cut-off for the Oslo IETF is coming up, and i don't want it to be "out of print" that long). There was, at the end of our previous discussions, still some amount of controversy. I guess that will flare up again, and we will talk about it. After that, my hope is to submit the I-D as an experimental RFC (but, we will see!). By the way, since our discussions in March, i (and some others) have published a short paper on one of the scenarios that made me feel like a modified Nagle would be a "good thing". A postscript version of that paper is online at http://www.cc.gatech.edu/fac/Ellen.Zegura/wisp99/papers/minshall.ps (it was presented at the "workshop on internet server performance" at the beginning of May). Note that the "implementation of a modified version of Nagle" reported in the paper -- which didn't give all that great results -- was *NOT* an implementation of the modified version of Nagle as suggested in the I-D. However, the paper gives both a good explanation of how application developers may not be doing the right buffering, and thus see many more "Nagle+delayed ACK" delays than they need have seen, as well as of how, even with "perfect buffering", applications may have the trailing packet of some responses delayed; the first motivates us to educate application developers, the second motivates us (me, at least) to modify Nagle slightly to remove this class of delay. Cheers, Greg From owner-tcp-impl@lerc.nasa.gov Fri Jun 18 16:11:04 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29792 for ; Fri, 18 Jun 1999 16:11:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21143 for tcp-impl-outgoing; Fri, 18 Jun 1999 13:08:56 -0400 (EDT) Received: from luna.packeteer.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA21135 for ; Fri, 18 Jun 1999 13:08:54 -0400 (EDT) Received: from bob ([10.10.1.48]) by luna.packeteer.com (8.9.0/8.9.0) with SMTP id KAA04506 for ; Fri, 18 Jun 1999 10:08:52 -0700 (PDT) Message-Id: <199906181708.KAA04506@luna.packeteer.com> X-Sender: bob@pop.packeteer.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 18 Jun 1999 10:10:28 -0700 To: tcp-impl@grc.nasa.gov From: bob packer Subject: tcp mss question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Hello, A connection is made with receiver R who has sent a value of large_mss for its syn option and a sender S who has sent small_mss. In the ensuing transfer, R sends time driven acks rather than acking consecutive small_mss sized segments (given a window < 2*large_mss). Clearly wrong per TCP-Illustrated but I don't find clarity in the RFCs. 1122 states that implementations should ack consecutive full sized segments and elsewhere describes full sized segments as the min of the received mss option and the local mtu - something not visible to the remote endpoint. Maybe I am missing something here ? Anyone know of an authoratative reference on this point ? Thanks, bp From owner-tcp-impl@lerc.nasa.gov Fri Jun 18 19:44:00 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02470 for ; Fri, 18 Jun 1999 19:43:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA15044 for tcp-impl-outgoing; Fri, 18 Jun 1999 17:02:03 -0400 (EDT) Received: from caliper.sjf.novell.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAB15040 for ; Fri, 18 Jun 1999 17:02:01 -0400 (EDT) Received: (from kml@localhost) by caliper.sjf.novell.com (8.8.8/8.8.8) id OAA00983; Fri, 18 Jun 1999 14:01:22 -0700 (PDT) Message-Id: <199906182101.OAA00983@caliper.sjf.novell.com> To: bob packer cc: tcp-impl@grc.nasa.gov Subject: Re: tcp mss question In-reply-to: Your message of "Fri, 18 Jun 1999 10:10:28 PDT." <199906181708.KAA04506@luna.packeteer.com> From: "Kevin Lahey" Date: Fri, 18 Jun 1999 14:01:22 -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In message <199906181708.KAA04506@luna.packeteer.com>bob packer writes > > A connection is made with receiver R who has sent a value > of large_mss for its syn option and a sender S who has sent > small_mss. > > In the ensuing transfer, R sends time driven acks rather than > acking consecutive small_mss sized segments (given a window > < 2*large_mss). > > Clearly wrong per TCP-Illustrated but I don't find clarity in the > RFCs. 1122 states that implementations should ack consecutive > full sized segments and elsewhere describes full sized segments > as the min of the received mss option and the local mtu - something > not visible to the remote endpoint. Maybe I am missing something > here ? With Path MTU Discovery, this can get tricky. See RFC 2581. Some implementations (NetBSD) have started to ACK every second packet, regardless of size; others (Linux) actually watch the size of the incoming packets to attempt to determine the appropriate "full size" for generating ACKs. Enjoy, Kevin Lahey kml@novell.com From owner-tcp-impl@lerc.nasa.gov Sun Jun 20 01:27:40 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00820 for ; Sun, 20 Jun 1999 01:27:39 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA09663 for tcp-impl-outgoing; Sat, 19 Jun 1999 20:51:45 -0400 (EDT) Received: from pisces.tcg.sgi.net (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA09659 for ; Sat, 19 Jun 1999 20:51:43 -0400 (EDT) Received: from hal (dap-209-166-146-74.pm3-1.smds.untn.pa.stargate.net [209.166.146.74]) by pisces.tcg.sgi.net (StarGate/4.0.24) with SMTP id LAA09458 for ; Sat, 19 Jun 1999 11:49:53 -0400 (EDT) Message-Id: <199906191549.LAA09458@pisces.tcg.sgi.net> X-Sender: halg@sgi.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Demo Date: Sat, 19 Jun 1999 11:50:51 -0400 To: tcp-impl@grc.nasa.gov From: Hal Subject: Bit Swiping Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_9027179==_.ALT" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --=====================_9027179==_.ALT Content-Type: text/plain; charset="us-ascii" What would be a good way to explain bit swiping to my TCP/IP MCSE Class ? Hal F. Gottfried MCSE+I,CNE,A+ Computer - Tech of Pittsburgh, Pa Instructor The Gottfrieds 406 Market St Apt 1 Brownsville, Pa 15417 --=====================_9027179==_.ALT Content-Type: text/html; charset="us-ascii"
What would be a good way to explain bit swiping to my TCP/IP MCSE Class ?

Hal F. Gottfried MCSE+I,CNE,A+
Computer - Tech of Pittsburgh, Pa
Instructor

The Gottfrieds
406 Market St Apt 1
Brownsville, Pa 15417 --=====================_9027179==_.ALT-- From owner-tcp-impl@lerc.nasa.gov Wed Jun 23 14:42:58 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09138 for ; Wed, 23 Jun 1999 14:42:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA02129 for tcp-impl-outgoing; Wed, 23 Jun 1999 11:30:47 -0400 (EDT) Received: from mailhost.iprg.nokia.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA02125 for ; Wed, 23 Jun 1999 11:30:45 -0400 (EDT) Received: from vienna.iprg.nokia.com (vienna.iprg.nokia.com [205.226.11.35]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA20387 for ; Wed, 23 Jun 1999 08:30:44 -0700 (PDT) From: Fred Bauer Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id IAA03888 for tcp-impl@lerc.nasa.gov; Wed, 23 Jun 1999 08:30:43 -0700 (PDT) Date: Wed, 23 Jun 1999 08:30:43 -0700 (PDT) Message-Id: <199906231530.IAA03888@vienna.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000 Call For Papers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>>> <<<< >>>>LAST CALL LAST CALL LAST CALL LAST CALL<<<< >>>> <<<< >>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<< INFOCOM 2000 LAST CALL FOR PAPERS IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom (general) http://www.comsoc.org/confs/infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies ******************************************* * * * PAPER SUBMISSION ENDS ON JULY 1, 1999 * * * * Submission deadlines are strict! * * * * To avoid last minute problems, * * authors are encouraged to submit * * their papers well in advance of the * * deadline. * * * ******************************************* SCOPE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. The conference is sponsored by the technical committees on computer communications of the IEEE Communications and Computers Societies. The Infocom 2000 organizing committee is soliciting original papers describing state-of-the-art research and development in all areas of computer networking and data communications. Topics of interest include, but are not limited to, the following: Active Networks Network Management and Control BISDN and ATM Network Reliability Billing and Pricing Network Restoration Congestion and Admission Control Network Signaling Distributed Network Algorithms Network Standards High-Speed Network Protocols Network and Protocol Performance Integrated Control of Networks Optical Networks Intelligent Networks Personal Communications Systems Internet Photonic Switching Internetworking Protocol Design and Analysis Lightwave Networks Quality of Service Mobility Routing and Routing Protocols Multicast/Broadcast Algorithms Security and Privacy Multimedia Protocols Switch Architectures Multimedia Terminals and Systems Testbeds and Measurements Multiple Access Traffic Management and Control Network Architectures Video Networking Network Design and Planning Wireless Networks and Protocols PAPER SUBMISSION ================ Papers must be submitted electronically in the manner and format detailed below. Authors for whom this presents a severe problem should contact one of the technical program committee co-chairs to discuss alternatives. Papers must be formatted according to the IEEE standard format except for the font size, which must be 11pt. To make it easy to adhere to the formatting standard we offer templates and samples for LaTex, MSWord, and FrameMaker (consult at the web pages referenced on top of this message). Submission must be in PDF. However, the committee will also accept Postscript from Latex, FrameMaker, or MSWord source file. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. (Postscript output from MSWord typically does not work on non-Microsoft platforms. The use of the Apple LaserWriter II printer driver is strongly recommended). The above formatted papers can be submitted in a compressed form (gzip, zip, compress). Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, ----------------------------------------------------- |papers with more than 11 pages will not be reviewed| ----------------------------------------------------- (this is roughly equivalent to 20 double-spaced pages). Papers must be submitted electronically using the Web site at . This web page contains exact and detailed instructions. The submission process includes providing detailed contact information. To save space authors can omit this information from the paper itself. Authors will receive an immediate notification of the successful receipt of the file containing their paper. Subsequently, a formal notification will be sent after verifying that the paper can be printed successfully. --------------------------------------------------------- |Submissions will only be accepted until July 1st, 1999.| --------------------------------------------------------- Submission deadlines are strict! Papers that have been improperly submitted or improperly formatted by the submission date will not be considered. To avoid last minute problems, authors are encouraged to submit their papers well in advance of the deadline. THE REVIEW PROCESS ================== Each paper will typically be reviewed by three independent reviewers, whose reviews will be relayed to the corresponding author. To facilitate the review process authors will be asked to classify the paper according to a list of categories so that the most appropriate reviewers handle the paper. This year a new step will be introduced into the process whereby authors will have a chance to provide a limited rebuttal on the reviews before the program committee makes its final decision. TRAVEL GRANTS ============= Limited travel assistance to students, post-docs and junior faculty for defraying some of the costs of presenting a paper in the conference will be available. Please refer to the conference web sites for further details later this year. IMPORTANT DATES =============== Complete paper due July 1, 1999 Notification of acceptance October 31, 1999 Final version due December 3, 1999 PROGRAM COMMITTEE CO-CHAIRS [infocom@comnet9.technion.ac.il] =========================== Raphael Rom, Technion, Israel Henning Schulzrinne, Columbia University, USA From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 00:39:16 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24310 for ; Thu, 24 Jun 1999 00:39:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA20579 for tcp-impl-outgoing; Wed, 23 Jun 1999 21:35:00 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA20575 for ; Wed, 23 Jun 1999 21:34:58 -0400 (EDT) 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 SAA13328; Wed, 23 Jun 1999 18:34:56 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id SAA14845; Wed, 23 Jun 1999 18:34:55 -0700 (PDT) Date: Wed, 23 Jun 1999 18:34:55 -0700 (PDT) Message-Id: <199906240134.SAA14845@rum.isi.edu> To: tcp-impl@grc.nasa.gov, minshall@siara.com Subject: Re: Nagle -- again X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From owner-tcp-impl@lerc.nasa.gov Thu Jun 17 20:10:54 1999 > To: tcp-impl@grc.nasa.gov > Subject: Nagle -- again > Date: Thu, 17 Jun 1999 19:27:13 -0700 > From: Greg Minshall > > All and sundry, > > We last talked about this in March. The I-D i had submitted last fall has > either expired or is about to expire. So... > > My plan is to submit the updated version of my I-D (that i sent to this list a > long time ago -- Fri, 26 Feb 1999) to the Internet Drafts directory (soon, > given that the cut-off for the Oslo IETF is coming up, and i don't want it to > be "out of print" that long). ... One observation - the paper indicates that there _must_ be at least one ACK every two packets. This is not strictly required, at least last time I checked. Presuming that, would you propose to allow K-1 outstanding partial packets, given one ACK per K packets? Some other notes: - the paper uses analysis based on ethernet MSS's, how do things change if Internet default MSSs are assumed? - Table 3 doesn't match the other tables (either) for original nagle Joe From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 02:48:06 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08188 for ; Thu, 24 Jun 1999 02:48:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA24650 for tcp-impl-outgoing; Wed, 23 Jun 1999 23:58:15 -0400 (EDT) Received: from pneumatic-tube.sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id XAA24645 for ; Wed, 23 Jun 1999 23:58:13 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA3047097; Wed, 23 Jun 1999 20:58:00 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA01306; Wed, 23 Jun 1999 20:57:59 -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 UAA08469; Wed, 23 Jun 1999 20:57:58 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199906240357.UAA08469@bossette.engr.sgi.com> Subject: Re: Nagle -- again To: touch@ISI.EDU (Joe Touch) Date: Wed, 23 Jun 1999 20:57:58 -0700 (PDT) Cc: tcp-impl@grc.nasa.gov, minshall@siara.com In-Reply-To: <199906240134.SAA14845@rum.isi.edu> from "Joe Touch" at Jun 23, 99 06:34:55 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@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Joe Touch wrote: > > One observation - the paper indicates that there _must_ be at least > one ACK every two packets. This is not strictly required, at least > last time I checked. > I've been meaning to bring that up for a while. The `ack every other segment' algorithm recommended in RFC-1122 is bad news for high bandwidth, low packet size media. In particular I'm thinking of gigabit Ethernet without jumbograms. When we get an ack for every 2 packets, i.e. one ack for every ~2920 bytes of application data, then if we want to obtain a TCP goodput of, say, 600 Mbits/sec on a single connection, then our sending machine will be receiving approx. 26000 ACKs per second which places a substuntial load on the sending hosts's stack (interrupt processing, IP packet processing, TCP processing). In other, lower bandwidth, scenarios the ACK every other packet scheme can improve performance by keeping a steady flow of ACKs that stop the source from hitting the end of its congestion window. So, two things: (a) the SHOULD in RFC-1122 should remain a SHOULD and not become a MUST, IMO (b) I'm sure there is a clever algorithm to be found that decides when the optimal time to send an ACK is; anybody got any ideas? Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 03:06:34 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08332 for ; Thu, 24 Jun 1999 03:06:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA25355 for tcp-impl-outgoing; Thu, 24 Jun 1999 00:19:12 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA25351 for ; Thu, 24 Jun 1999 00:19:11 -0400 (EDT) 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 VAA19526; Wed, 23 Jun 1999 21:19:09 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id VAA15240; Wed, 23 Jun 1999 21:19:09 -0700 (PDT) Date: Wed, 23 Jun 1999 21:19:09 -0700 (PDT) Message-Id: <199906240419.VAA15240@rum.isi.edu> To: sm@bossette.engr.sgi.com Subject: Re: Nagle -- again Cc: minshall@siara.com, tcp-impl@grc.nasa.gov, touch@ISI.EDU Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > Subject: Re: Nagle -- again > To: touch@ISI.EDU (Joe Touch) > Date: Wed, 23 Jun 1999 20:57:58 -0700 (PDT) > Cc: tcp-impl@grc.nasa.gov, minshall@siara.com > > Joe Touch wrote: > > > > One observation - the paper indicates that there _must_ be at least > > one ACK every two packets. This is not strictly required, at least > > last time I checked. > > > > I've been meaning to bring that up for a while. The `ack every other > segment' algorithm recommended in RFC-1122 is bad news for high bandwidth, > low packet size media. In particular I'm thinking of gigabit Ethernet > without jumbograms. When we get an ack for every 2 packets, i.e. one > ack for every ~2920 bytes of application data, then if we want to obtain a > TCP goodput of, say, 600 Mbits/sec on a single connection, then our > sending machine will be receiving approx. 26000 ACKs per second which > places a substuntial load on the sending hosts's stack (interrupt > processing, IP packet processing, TCP processing). This is indeed problem. However, it appears that a significant part of the issue is the lack of a reasonable sized MTU, i.e., sticking with non jumbograms. Relying on ACK reduction alone won't fix that. The key issue is whether ACK clocking is important. It is implicit, but only if the ACK frequency is high enough. If ACKs are less frequent, the source becomes more bursty (allowed to send K packets when an ACK arrives). > (a) the SHOULD in RFC-1122 should remain a SHOULD and not become > a MUST, IMO It seems useful to require _either_ a minimum acceptable ACK frequency or a separate clocking mechanism that spaces transmission. This could be something negotiated on a per-pair basis. > (b) I'm sure there is a clever algorithm to be found that decides > when the optimal time to send an ACK is; anybody got any ideas? Clever, _and_ runs as needed for a gigabit, if you please :-) Joe From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 03:29:06 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08435 for ; Thu, 24 Jun 1999 03:29:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA25956 for tcp-impl-outgoing; Thu, 24 Jun 1999 00:43:31 -0400 (EDT) Received: from daffy.ee.lbl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA25952 for ; Thu, 24 Jun 1999 00:43:29 -0400 (EDT) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id VAA18403; Wed, 23 Jun 1999 21:43:27 -0700 (PDT) Message-Id: <199906240443.VAA18403@daffy.ee.lbl.gov> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again In-reply-to: Your message of Wed, 23 Jun 1999 20:57:58 PDT. Date: Wed, 23 Jun 1999 21:43:27 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > (a) the SHOULD in RFC-1122 should remain a SHOULD and not become > a MUST, IMO RFC 2581 makes it clear that this is a SHOULD and not a MUST (for precisely the reason you raise, that there are some scenarios where an implementation will have a good reason to ack less often). Vern From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 16:02:35 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21137 for ; Thu, 24 Jun 1999 16:02:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA14145 for tcp-impl-outgoing; Thu, 24 Jun 1999 12:58:30 -0400 (EDT) Received: from Arachnid.NTRG.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA14138 for ; Thu, 24 Jun 1999 12:58:27 -0400 (EDT) Received: from ehsco.com ([209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 181 for ; Thu, 24 Jun 1999 09:58:25 -0700 Message-ID: <377263B0.1FBB44AB@ehsco.com> Date: Thu, 24 Jun 1999 09:58:24 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again References: <199906240357.UAA08469@bossette.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I also think ACK-for-every-2nd is bad, although I've thought about this in terms of half-duplex links where ACKs just mean the sender can't keep streaming data. > (b) I'm sure there is a clever algorithm to be found that decides > when the optimal time to send an ACK is; anybody got any ideas? My thinking: the receiver should ACK when enough data has been received to fill 50% of the outstanding receive window. No more, no less. If the reciever publishes an 8k rwin, then it should ACK once half of the window (or a near quantity of MSS segments) is received. If the rwin advertisement drops to 4k for some reason, the the recipient should ACK at 2k. Etc. This would obviously be very problematic with slow start and congestion avoidance. There is also a problem of the receiver not being aware of RTT changes in a bulk-transfer environment, and they should not use 50% if the sender will fill rwin before the ACK arrives. Imbalanced links (satellite for sends but modems for ACKs) are also problematic. I don't think the scheme is usable until these issues are resolved. Given all of those issues, the only thing that can be done in the current model is to ACK every other segment. Having a negotiated virtual circuit (with explicit markings for link characteristics) would allow for a more accurate ACK strategy. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 16:03:17 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21178 for ; Thu, 24 Jun 1999 16:03:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA15027 for tcp-impl-outgoing; Thu, 24 Jun 1999 13:06:06 -0400 (EDT) Received: from Arachnid.NTRG.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA15023 for ; Thu, 24 Jun 1999 13:06:04 -0400 (EDT) Received: from ehsco.com ([209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 434 for ; Thu, 24 Jun 1999 10:06:03 -0700 Message-ID: <3772657A.9A943FCC@ehsco.com> Date: Thu, 24 Jun 1999 10:06:02 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again References: <199906240357.UAA08469@bossette.engr.sgi.com> <377263B0.1FBB44AB@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Given all of those issues, the only thing that can be done in the > current model is to ACK every other segment. Another possible solution to the problem is the use of a Mega ACK, where the recipient ONLY sends an ACK after (A) a discontiguous segment is received or (B) no more data arrives. (B) is the killer, since it would introduce delay at the end of a successful transfer unless the receiver knew how much data was being transferred (which is not possible except with some bulk transfers). It may be that a MACK option would be useful for bulk transfer apps. (B) would also introduce a LOT of delays in the event of a lossy link. This could be resolved with the use of an explicit NACK though, and also illustrates that a MACK option should be limited to applications that can tell the recipient exactly how much data is coming. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 17:43:38 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23285 for ; Thu, 24 Jun 1999 17:43:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA01043 for tcp-impl-outgoing; Thu, 24 Jun 1999 15:10:32 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA01039 for ; Thu, 24 Jun 1999 15:10:30 -0400 (EDT) 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 MAA29907; Thu, 24 Jun 1999 12:10:29 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id MAA16098; Thu, 24 Jun 1999 12:10:28 -0700 (PDT) Date: Thu, 24 Jun 1999 12:10:28 -0700 (PDT) Message-Id: <199906241910.MAA16098@rum.isi.edu> To: ehall@ehsco.com Subject: Re: Nagle -- again Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 10:45:17 1999 > Date: Thu, 24 Jun 1999 09:58:24 -0700 > From: "Eric A. Hall" > X-Accept-Language: en > CC: tcp-impl@grc.nasa.gov > Subject: Re: Nagle -- again > > > I also think ACK-for-every-2nd is bad, although I've thought about this > in terms of half-duplex links where ACKs just mean the sender can't keep > streaming data. > > > (b) I'm sure there is a clever algorithm to be found that decides > > when the optimal time to send an ACK is; anybody got any ideas? > > My thinking: the receiver should ACK when enough data has been received > to fill 50% of the outstanding receive window. No more, no less. This would encourage bursts of 1/2 the window size. Having ACKs more frequent avoids those bursts. Joe From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 17:57:11 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23421 for ; Thu, 24 Jun 1999 17:57:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA02792 for tcp-impl-outgoing; Thu, 24 Jun 1999 15:24:21 -0400 (EDT) Received: from Arachnid.NTRG.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA02786 for ; Thu, 24 Jun 1999 15:24:20 -0400 (EDT) Received: from ehsco.com ([209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 528; Thu, 24 Jun 1999 12:24:17 -0700 Message-ID: <377285E0.BAB2D256@ehsco.com> Date: Thu, 24 Jun 1999 12:24:17 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch CC: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again References: <199906241910.MAA16098@rum.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > > My thinking: the receiver should ACK when enough data has been received > > to fill 50% of the outstanding receive window. No more, no less. > > This would encourage bursts of 1/2 the window size. I prefaced this in terms of half-duplex links. Half/half is better than 2/2/2/2/2/etc in terms of actual utilization. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 18:36:31 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24076 for ; Thu, 24 Jun 1999 18:36:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA07665 for tcp-impl-outgoing; Thu, 24 Jun 1999 16:04:49 -0400 (EDT) Received: from ns1.siara.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA07661 for ; Thu, 24 Jun 1999 16:04:48 -0400 (EDT) Received: from siara-serv1. by ns1.siara.com via smtpd (for fw01.lerc.nasa.gov [139.88.145.14]) with SMTP; 24 Jun 1999 20:35:00 UT Received: from red.mtv.siara.com by siara.com with smtp id m10xFjO-001FKBC; Thu, 24 Jun 1999 13:04:18 -0700 (PDT) Received: from red.mtv.siara.com by red.mtv.siara.com (8.8.7) id NAA08953; Thu, 24 Jun 1999 13:04:54 -0700 (PDT) Message-Id: <199906242004.NAA08953@red.mtv.siara.com> X-Mailer: exmh version 2.0.2 2/24/98 To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: touch@ISI.EDU (Joe Touch), tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again In-reply-to: Your message of "Wed, 23 Jun 1999 20:57:58 PDT." <199906240357.UAA08469@bossette.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jun 1999 13:04:54 -0700 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk i've been *told* that Linux will let exactly one ACK live in the i/f output queue, updating it with new acknowledgments and window updates. this can reduce the number of ACKs (though breaking the clock). however, if your host is generating 52,000 *data* packets per second, i wonder if getting 26,000 ACKs per second *should* be a problem. (i don't doubt that it *is* a problem, but *should* it be a problem?) cheers, Greg M. From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 18:36:33 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24086 for ; Thu, 24 Jun 1999 18:36:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA07387 for tcp-impl-outgoing; Thu, 24 Jun 1999 16:01:56 -0400 (EDT) Received: from ns1.siara.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA07370 for ; Thu, 24 Jun 1999 16:01:53 -0400 (EDT) Received: from siara-serv1. by ns1.siara.com via smtpd (for fw01.lerc.nasa.gov [139.88.145.14]) with SMTP; 24 Jun 1999 20:32:05 UT Received: from red.mtv.siara.com by siara.com with smtp id m10xFgZ-001FKCC; Thu, 24 Jun 1999 13:01:23 -0700 (PDT) Received: from red.mtv.siara.com by red.mtv.siara.com (8.8.7) id NAA08932; Thu, 24 Jun 1999 13:02:00 -0700 (PDT) Message-Id: <199906242002.NAA08932@red.mtv.siara.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Joe Touch cc: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again In-reply-to: Your message of "Wed, 23 Jun 1999 18:34:55 PDT." <199906240134.SAA14845@rum.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jun 1999 13:01:55 -0700 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Joe, > One observation - the paper indicates that there _must_ be at least > one ACK every two packets. This is not strictly required, at least > last time I checked. yes, sorry. > Presuming that, would you propose to allow K-1 outstanding partial > packets, given one ACK per K packets? no. > - the paper uses analysis based on ethernet MSS's, > how do things change if Internet default MSSs are assumed? well, i suspect that ethernet MSS ~== Internet default MSS, however if you mean 512 or 576 bytes, i'm not sure. i'll (possibly) get back to you/the list on this. > - Table 3 doesn't match the other tables (either) for original nagle yes, table 1 is from one run on one kernel; table 3 is from one run on a kernel that had could switch between the two implementations. also, note our (rueful) disclaimer: We intend to do a further study using a careful statistical analysis of a large set of trials (and apologize for the use of single trials in this paper) ;-) Greg From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 19:35:49 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24732 for ; Thu, 24 Jun 1999 19:35:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA13665 for tcp-impl-outgoing; Thu, 24 Jun 1999 17:03:11 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA13661 for ; Thu, 24 Jun 1999 17:03:08 -0400 (EDT) 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 OAA10131; Thu, 24 Jun 1999 14:03:07 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id OAA16174; Thu, 24 Jun 1999 14:03:07 -0700 (PDT) Date: Thu, 24 Jun 1999 14:03:07 -0700 (PDT) Message-Id: <199906242103.OAA16174@rum.isi.edu> To: touch@ISI.EDU, ehall@ehsco.com Subject: Re: Nagle -- again Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 13:04:33 1999 > Date: Thu, 24 Jun 1999 12:24:17 -0700 > From: "Eric A. Hall" > X-Accept-Language: en > To: Joe Touch > CC: tcp-impl@grc.nasa.gov > Subject: Re: Nagle -- again > > > > > My thinking: the receiver should ACK when enough data has been received > > > to fill 50% of the outstanding receive window. No more, no less. > > > > This would encourage bursts of 1/2 the window size. > > I prefaced this in terms of half-duplex links. Half/half is better than > 2/2/2/2/2/etc in terms of actual utilization. How does a system know the links are half duplex? Also, half half isn't better than 2/2/2/2, where power is concerned. Running at 1/2 speed all the time consumes less power than running full speed for half the time. For some half-duplex links, where line speed can be configured, this could affect power consumption. Joe From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 19:36:17 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24748 for ; Thu, 24 Jun 1999 19:36:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA13204 for tcp-impl-outgoing; Thu, 24 Jun 1999 16:59:20 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA13189 for ; Thu, 24 Jun 1999 16:59:17 -0400 (EDT) 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 NAA09661; Thu, 24 Jun 1999 13:59:15 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id NAA16167; Thu, 24 Jun 1999 13:59:15 -0700 (PDT) Date: Thu, 24 Jun 1999 13:59:15 -0700 (PDT) Message-Id: <199906242059.NAA16167@rum.isi.edu> To: touch@ISI.EDU, minshall@siara.com Subject: Re: Nagle -- again Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 13:40:17 1999 > To: Joe Touch > cc: tcp-impl@grc.nasa.gov > Subject: Re: Nagle -- again > Date: Thu, 24 Jun 1999 13:01:55 -0700 > From: Greg Minshall > > Joe, > > > One observation - the paper indicates that there _must_ be at least > > one ACK every two packets. This is not strictly required, at least > > last time I checked. > > yes, sorry. > > > Presuming that, would you propose to allow K-1 outstanding partial > > packets, given one ACK per K packets? > > no. > > > - the paper uses analysis based on ethernet MSS's, > > how do things change if Internet default MSSs are assumed? > > well, i suspect that ethernet MSS ~== Internet default MSS, however if you > mean 512 or 576 bytes, i'm not sure. i'll (possibly) get back to you/the list > on this. I mean 512 or 576. Internet default MSS is 576. > > - Table 3 doesn't match the other tables (either) for original nagle > > yes, table 1 is from one run on one kernel; table 3 is from one run on a > kernel that had could switch between the two implementations. also, note our > (rueful) disclaimer: It was just that the difference was high enough to raise the issue of variance, and whether Table 1's discrepencies (partial being better than full buffering) were 'signal'. Joe From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 19:49:07 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24970 for ; Thu, 24 Jun 1999 19:49:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA14120 for tcp-impl-outgoing; Thu, 24 Jun 1999 17:07:21 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA14116 for ; Thu, 24 Jun 1999 17:07:19 -0400 (EDT) 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 OAA10685; Thu, 24 Jun 1999 14:07:18 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id OAA16180; Thu, 24 Jun 1999 14:07:18 -0700 (PDT) Date: Thu, 24 Jun 1999 14:07:18 -0700 (PDT) Message-Id: <199906242107.OAA16180@rum.isi.edu> To: sm@bossette.engr.sgi.com, minshall@siara.com Subject: Re: Nagle -- again Cc: touch@ISI.EDU, tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 13:44:17 1999 > To: sm@bossette.engr.sgi.com (Sam Manthorpe) > cc: touch@ISI.EDU (Joe Touch), tcp-impl@grc.nasa.gov > Subject: Re: Nagle -- again > Date: Thu, 24 Jun 1999 13:04:54 -0700 > From: Greg Minshall > > i've been *told* that Linux will let exactly one ACK live in the i/f output > queue, updating it with new acknowledgments and window updates. this can > reduce the number of ACKs (though breaking the clock). > > however, if your host is generating 52,000 *data* packets per second, i wonder > if getting 26,000 ACKs per second *should* be a problem. (i don't doubt that > it *is* a problem, but *should* it be a problem?) It will always be more computation than processing less ACKs. However, it should be possible to have a network interface where incoming interrupts are suppressed for a time (maybe for all packets, maybe for solo ACKs, ???), such that the source scans the input as part of its packet output routine. I.e., the normal 'inner loop' could be: send a packet process an ACK (or one every other, etc). This would cut the number of input packet interrupts. I would claim that processing ACKs at this rate is part of the price of playing nice, allowing the source to avoid bursts. If you want to negotiate around it for sources that can pace, that's even better. But the default can be 'play nice'. Joe From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 20:11:44 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25313 for ; Thu, 24 Jun 1999 20:11:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA15719 for tcp-impl-outgoing; Thu, 24 Jun 1999 17:28:25 -0400 (EDT) Received: from ns1.siara.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA15714 for ; Thu, 24 Jun 1999 17:28:23 -0400 (EDT) Received: from siara-serv1. by ns1.siara.com via smtpd (for fw01.lerc.nasa.gov [139.88.145.14]) with SMTP; 24 Jun 1999 21:58:35 UT Received: from red.mtv.siara.com by siara.com with smtp id m10xH2H-001FKIC; Thu, 24 Jun 1999 14:27:53 -0700 (PDT) Received: from red.mtv.siara.com by red.mtv.siara.com (8.8.7) id OAA09316; Thu, 24 Jun 1999 14:28:30 -0700 (PDT) Message-Id: <199906242128.OAA09316@red.mtv.siara.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Joe Touch cc: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again In-reply-to: Your message of "Thu, 24 Jun 1999 13:59:15 PDT." <199906242059.NAA16167@rum.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jun 1999 14:28:30 -0700 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Joe, > It was just that the difference was high enough to > raise the issue of variance, and whether Table 1's discrepencies > (partial being better than full buffering) were 'signal'. a legitimate concern. i don't focus on the minor differences, and the "partial being better than full" is one of the minor differences that may well be due to statistical fluctuations. the keys points are: 1) turn off Nagle and you may become a very *bad* netizen; 2) Nagle + delayed ACKs (or, really, even + RTT) can slow down the timely transmission of some data, and maybe we could do better. Greg From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 20:32:06 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25646 for ; Thu, 24 Jun 1999 20:32:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA17165 for tcp-impl-outgoing; Thu, 24 Jun 1999 17:51:23 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA17156 for ; Thu, 24 Jun 1999 17:51:22 -0400 (EDT) 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 OAA14288; Thu, 24 Jun 1999 14:51:21 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id OAA16721; Thu, 24 Jun 1999 14:51:21 -0700 (PDT) Date: Thu, 24 Jun 1999 14:51:21 -0700 (PDT) Message-Id: <199906242151.OAA16721@rum.isi.edu> To: touch@ISI.EDU, minshall@siara.com Subject: Re: Nagle -- again Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From minshall@siara.com Thu Jun 24 14:28:25 1999 > To: Joe Touch > cc: tcp-impl@grc.nasa.gov > Subject: Re: Nagle -- again > Date: Thu, 24 Jun 1999 14:28:30 -0700 > From: Greg Minshall > > Joe, > > > It was just that the difference was high enough to > > raise the issue of variance, and whether Table 1's discrepencies > > (partial being better than full buffering) were 'signal'. > > a legitimate concern. i don't focus on the minor differences, and the > "partial being better than full" is one of the minor differences that may well > be due to statistical fluctuations. > > the keys points are: 1) turn off Nagle and you may become a very *bad* > netizen; I don't follow that - it seems like it requires "and implement applications poorly), in which case you're bad anyway, no? > 2) Nagle + delayed ACKs (or, really, even + RTT) can slow down the > timely transmission of some data, and maybe we could do better. Agreed. Joe From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 20:45:19 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25762 for ; Thu, 24 Jun 1999 20:45:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA18775 for tcp-impl-outgoing; Thu, 24 Jun 1999 18:15:45 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA18771 for ; Thu, 24 Jun 1999 18:15:44 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id QAA01742 for tcp-impl@grc.nasa.gov env-from ; Thu, 24 Jun 1999 16:15:43 -0600 (MDT) Date: Thu, 24 Jun 1999 16:15:43 -0600 (MDT) From: Vernon Schryver Message-Id: <199906242215.QAA01742@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >however, if your host is generating 52,000 *data* packets per second, i wonder > if getting 26,000 ACKs per second *should* be a problem. (i don't doubt that > it *is* a problem, but *should* it be a problem?) Yes, it *should* be a problem. If your host can handle 78K p/s, then it probably doesn't care whether they contain 48, 64, 1500, or even 4K bytes (assuming you don't finally hit the wall on raw medium speed). If you spend 30% of your maximum p/s rate on acks, then your throughput will be limited to 60% of your max p/s times your MSS, and similarly if you spend 50% or 10% of your p/s rate on acks. And then there are the odd details of various media where it every turn-around of the medium costs as much or more bandwidth than a TCP ACK. Examples of such media include CSMA/CD as implemented by the classic AMD LANCE. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 22:31:50 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28384 for ; Thu, 24 Jun 1999 22:31:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA22018 for tcp-impl-outgoing; Thu, 24 Jun 1999 19:38:39 -0400 (EDT) Received: from zephyr.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA22014 for ; Thu, 24 Jun 1999 19:38:38 -0400 (EDT) From: braden@ISI.EDU Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id QAA16382; Thu, 24 Jun 1999 16:38:34 -0700 (PDT) Date: Thu, 24 Jun 1999 16:38:33 -0700 Posted-Date: Thu, 24 Jun 1999 16:38:33 -0700 Message-Id: <199906242338.AA13249@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Thu, 24 Jun 1999 16:38:33 -0700 To: tcp-impl@grc.nasa.gov, vjs@calcite.rhyolite.com Subject: Re: Nagle -- again Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> *> Yes, it *should* be a problem. If your host can handle 78K p/s, then it *> probably doesn't care whether they contain 48, 64, 1500, or even 4K bytes *> (assuming you don't finally hit the wall on raw medium speed). If you *> spend 30% of your maximum p/s rate on acks, then your throughput will be *> limited to 60% of your max p/s times your MSS, and similarly if you spend *> 50% or 10% of your p/s rate on acks. *> I am not sure I believe in the significance of this reasoning. VJ TCP deliberately chose an approach (e.g., ACK clocking) that gives great robustness and adaptability to a wide range of speeds and delays, while not being strictly optimum in any particular circumstance. Personally, I believe this is still the right approach; optimization has a cost and is likely to limit robustness and adaptability, and the latter are the more important. Bob Braden *> And then there are the odd details of various media where it every *> turn-around of the medium costs as much or more bandwidth than a TCP ACK. *> Examples of such media include CSMA/CD as implemented by the classic AMD *> LANCE. *> *> *> Vernon Schryver vjs@rhyolite.com *> From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 23:50:03 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00405 for ; Thu, 24 Jun 1999 23:50:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA25004 for tcp-impl-outgoing; Thu, 24 Jun 1999 21:18:30 -0400 (EDT) Received: from ns1.siara.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA25000 for ; Thu, 24 Jun 1999 21:18:29 -0400 (EDT) Received: from siara-serv1. by ns1.siara.com via smtpd (for fw01.lerc.nasa.gov [139.88.145.14]) with SMTP; 25 Jun 1999 01:48:42 UT Received: from red.mtv.siara.com by siara.com with smtp id m10xKcx-001FK9C; Thu, 24 Jun 1999 18:17:59 -0700 (PDT) Received: from red.mtv.siara.com by red.mtv.siara.com (8.8.7) id SAA09921; Thu, 24 Jun 1999 18:18:35 -0700 (PDT) Message-Id: <199906250118.SAA09921@red.mtv.siara.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Joe Touch cc: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again In-reply-to: Your message of "Thu, 24 Jun 1999 14:51:21 PDT." <199906242151.OAA16721@rum.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jun 1999 18:18:35 -0700 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Joe, no, i think this is important: >> the keys points are: 1) turn off Nagle and you may become a very *bad* >> netizen; >I don't follow that - it seems like it requires "and implement >applications poorly", in which case you're bad anyway, no? the point of the paper (understated) and of much of my experience is that it is *very hard* to implement applications ``right'' (with respect to buffering). most people are going to get it wrong. and, even when it is done right, minor changes (bug fixes, adding features) are likely to make it wrong again (in a sense, "proper buffering" is an unstable point, whereas "improper buffering" is a stable point). Nagle protects the net *not* from "poorly written" applications, but rather from applications that aren't "very well written". this may seem like a subtle point, but i think the distinction is very important. Greg From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 23:50:08 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00417 for ; Thu, 24 Jun 1999 23:50:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA24537 for tcp-impl-outgoing; Thu, 24 Jun 1999 21:01:54 -0400 (EDT) Received: from pneumatic-tube.sgi.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA24533 for ; Thu, 24 Jun 1999 21:01:52 -0400 (EDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA3149356; Thu, 24 Jun 1999 18:01:46 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA75755; Thu, 24 Jun 1999 18:01:45 -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 SAA12627; Thu, 24 Jun 1999 18:01:43 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199906250101.SAA12627@bossette.engr.sgi.com> Subject: Re: Nagle -- again To: minshall@siara.com (Greg Minshall) Date: Thu, 24 Jun 1999 18:01:43 -0700 (PDT) Cc: touch@ISI.EDU, tcp-impl@grc.nasa.gov In-Reply-To: <199906242004.NAA08953@red.mtv.siara.com> from "Greg Minshall" at Jun 24, 99 01:04:54 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@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Greg Minshall wrote: > > however, if your host is generating 52,000 *data* packets per second, i wonder > if getting 26,000 ACKs per second *should* be a problem. (i don't doubt that > it *is* a problem, but *should* it be a problem?) > Hmm, not sure what you mean here. `should' according to which principle? Do you mean that ACK packets should be cheap compared to data packets because they are so much smaller? The relationship between packet size and processing time is generally far from linear, especially in systems which have zero-copy stacks. It is possible to modify your network stack to reduce the overhead of a large number of ACKs (e.g. poll for packets instead of relying interrupts). Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com From owner-tcp-impl@lerc.nasa.gov Thu Jun 24 23:50:38 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00428 for ; Thu, 24 Jun 1999 23:50:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA24850 for tcp-impl-outgoing; Thu, 24 Jun 1999 21:13:10 -0400 (EDT) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA24846 for ; Thu, 24 Jun 1999 21:13:07 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id TAA07363 for tcp-impl@grc.nasa.gov env-from ; Thu, 24 Jun 1999 19:13:06 -0600 (MDT) Date: Thu, 24 Jun 1999 19:13:06 -0600 (MDT) From: Vernon Schryver Message-Id: <199906250113.TAA07363@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: braden@ISI.EDU > *> Yes, it *should* be a problem. If your host can handle 78K p/s, then it > I am not sure I believe in the significance of this reasoning. VJ TCP > deliberately chose an approach (e.g., ACK clocking) that gives great > robustness and adaptability to a wide range of speeds and delays, while > not being strictly optimum in any particular circumstance. Personally, > I believe this is still the right approach; optimization has a cost and > is likely to limit robustness and adaptability, and the latter are the > more important. I was not advocating or opposing changes to ACK clocking. I was talking about the cases that I think Sam was talking about. In those cases, ACK clocking is a bad thing, as are most of the other the TCP improvements including slow start. When you are going full blast over a local network, you have not hit the wall on raw medium speed, and you are dealing with small packets (now <=4 KBytes), then your hosts are limited (to a good first approximation) by their raw packet per second rates. To predict your best throughput on media faster than your CPU's, multiply your p/s rate by 60% of your MSS, or to predict your maximum p/s rate, divide your throughput by 0.6 of your MSS. I think the 30% of packets that are Acks does far worse to TCP throughput than merely make it not strictly optimum. That factor of 0.6 in the formula *hurts*. I also don't have any wonderful ideas for reducing the number of Acks only when it would not be naughty. ........... ] From: Joe Touch ] ... ] It will always be more computation than processing less ACKs. ] However, it should be possible to have a network interface ] where incoming interrupts are suppressed for a time (maybe ] for all packets, maybe for solo ACKs, ???), such that the ] source scans the input as part of its packet output routine. ] I.e., the normal 'inner loop' could be: ] send a packet ] process an ACK ] ] (or one every other, etc). ] ] This would cut the number of input packet interrupts. For more than 10 years, Sam's employer has been shipping systems that do more sophisticated kinds of "interrupt rate limiting," "interrupt throttling," "interrupt merging," or "interrupt bursting" than that loop, using timers, counters, and other stuff in hardware, software, and firmware. Other UNIX vendors have also been in that market for a long time. My experience was that TCP goes fastest at about 0.1 interrupts/packet. Fewer interrupts/packet allow the inevitable, occassional miss in the game of patty-cake among hardware, board software, and host software to take so long to be recovered by an interrupt that throughput starts to decline. If your ratio of CPU cycle rate to medium bit rate is more than 10X from 1:1, I suspect that rule of thumb would break down, and you'd want more or less than 0.1 interrupts/packet. Some media, notably FDDI if you build the hardware right, enforce such interrupt rate limiting. Once you grab the token and start transmitting, you cannot get any input or input interrupts. The half-duplex nature of a token ring caused bursts of ACKs to arrive at 20+ Kp/s. Today FDDI is slow, but 10 years ago you had to work very hard (and foolishly) to have as many as one host interrupt per Ack. Because of the way the BSD IP input queue and tcp_output() work, if your host has cycles to spare while running at 100% of the medium, then something like the loop described above is exactly what you get, just as at slow speed over WANs. That is the whole point of Ack clocking. On the other hand, when the limit is CPU cycles, I doubt it is good to have the interrupt service routine doing a lot of fiddling with windows and sequence numbers that will be duplicated by tcp_input() and tcp_output(). At 78 Kp/s, you have only 13 usec for absolutely everything you are going to do with a packet. Even at 500 MHz, and even if you reduce interrupts, that's not a lot of cycles. Many people have proposed various things, such as TCP agglomeration (segment assembly) in firmware or hardware, but there are almost always good reasons to not implement them. ] I would claim that processing ACKs at this rate is part ] of the price of playing nice, allowing the source to ] avoid bursts. If you want to negotiate around it for ] sources that can pace, that's even better. But the ] default can be 'play nice'. It seems hard to figure out how to reduce the number of ACKs on a fast LAN without being naughty in other important cases, which is why none of the UNIX vendors (as far as I know) have shipped anything that doesn't always play nice by default, even when it would help a lot (1/0.6) to cheat. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Fri Jun 25 00:05:56 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00715 for ; Fri, 25 Jun 1999 00:05:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA25266 for tcp-impl-outgoing; Thu, 24 Jun 1999 21:27:52 -0400 (EDT) Received: from ns1.siara.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA25260 for ; Thu, 24 Jun 1999 21:27:51 -0400 (EDT) Received: from siara-serv1. by ns1.siara.com via smtpd (for fw01.lerc.nasa.gov [139.88.145.14]) with SMTP; 25 Jun 1999 01:58:03 UT Received: from red.mtv.siara.com by siara.com with smtp id m10xKm0-001FK9C; Thu, 24 Jun 1999 18:27:20 -0700 (PDT) Received: from red.mtv.siara.com by red.mtv.siara.com (8.8.7) id SAA09956; Thu, 24 Jun 1999 18:27:56 -0700 (PDT) Message-Id: <199906250127.SAA09956@red.mtv.siara.com> X-Mailer: exmh version 2.0.2 2/24/98 To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: tcp-impl@grc.nasa.gov Subject: Re: Nagle -- again In-reply-to: Your message of "Thu, 24 Jun 1999 18:01:43 PDT." <199906250101.SAA12627@bossette.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jun 1999 18:27:56 -0700 From: Greg Minshall Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Sam, "should" from the principle of how expensive (oh lord, this really isn't anything worth getting into, huh?) interrupts should be on a system. jumbograms, reduced numbers of ACKs, etc., are all based on the premise that it is *very* expensive to process a single packet (interrupt time, context switch, etc.). it is the case that per-packet processing costs dominate (ref lots of papers on the issue, with at least one [1993] SIGCOMM paper pointing out that data costs, also), but it would be nice (principle) if system designers made sure this cost less onerous rather than more onerous over time. i can (will) be accused of being somewhat utopian. i accept this as being basically valid; i understand the growing disparity between CPU cycle times and memory access times. but i think it is worth spending time pushing back. (you, and Joe T., are right in saying that sometimes polling can be used to reduce the per-packet costs.) Greg From owner-tcp-impl@lerc.nasa.gov Fri Jun 25 18:11:32 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06778 for ; Fri, 25 Jun 1999 18:11:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA28754 for tcp-impl-outgoing; Fri, 25 Jun 1999 14:42:27 -0400 (EDT) Received: from tnt.isi.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA28748 for ; Fri, 25 Jun 1999 14:42:25 -0400 (EDT) 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 LAA26481; Fri, 25 Jun 1999 11:42:23 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id LAA01476; Fri, 25 Jun 1999 11:42:23 -0700 (PDT) Date: Fri, 25 Jun 1999 11:42:23 -0700 (PDT) Message-Id: <199906251842.LAA01476@rum.isi.edu> To: touch@ISI.EDU, minshall@siara.com Subject: Re: Nagle -- again Cc: tcp-impl@grc.nasa.gov X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From minshall@siara.com Thu Jun 24 18:18:31 1999 > To: Joe Touch > cc: tcp-impl@grc.nasa.gov > Subject: Re: Nagle -- again > Date: Thu, 24 Jun 1999 18:18:35 -0700 > From: Greg Minshall > > Joe, > > no, i think this is important: > > >> the keys points are: 1) turn off Nagle and you may become a very *bad* > >> netizen; > > >I don't follow that - it seems like it requires "and implement > >applications poorly", in which case you're bad anyway, no? > > the point of the paper (understated) and of much of my experience is that it > is *very hard* to implement applications ``right'' (with respect to > buffering). most people are going to get it wrong. and, even when it is done > right, minor changes (bug fixes, adding features) are likely to make it wrong > again (in a sense, "proper buffering" is an unstable point, whereas "improper > buffering" is a stable point). Nagle protects the net *not* from "poorly > written" applications, but rather from applications that aren't "very well > written". this may seem like a subtle point, but i think the distinction is > very important. Agreed. I would hope that better libraries would be the place to put this collective wisdom, rather than encumbering the protocol with it, though :-) Joe From owner-tcp-impl@lerc.nasa.gov Mon Jun 28 16:46:00 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12941 for ; Mon, 28 Jun 1999 16:45:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA26973 for tcp-impl-outgoing; Mon, 28 Jun 1999 13:13:26 -0400 (EDT) Received: from mailhost.iprg.nokia.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA26967 for ; Mon, 28 Jun 1999 13:13:24 -0400 (EDT) Received: from vienna.iprg.nokia.com (vienna.iprg.nokia.com [205.226.11.35]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id KAA10303 for ; Mon, 28 Jun 1999 10:13:16 -0700 (PDT) From: Fred Bauer Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id KAA16939 for tcp-impl@lerc.nasa.gov; Mon, 28 Jun 1999 10:13:14 -0700 (PDT) Date: Mon, 28 Jun 1999 10:13:14 -0700 (PDT) Message-Id: <199906281713.KAA16939@vienna.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000 Call For Papers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk INFOCOM 2000 >>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>>> <<<< >>>> DEADLINE EXTENDED UNTIL JULY 5 (23:59 EDT), 1999 <<<< >>>> <<<< >>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Since the distribution of papers to TPC members has been postponed to July 6, 1999, the program committee of Infocom 2000 has decided to postpone the deadline for submitting papers to the conference until July 5 (23:59 EDT), 1999. INFOCOM 2000 LAST CALL FOR PAPERS IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom (general) http://www.comsoc.org/confs/infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies ******************************************* * * * PAPER SUBMISSION ENDS ON JULY 5, 1999 * * * * No extensions beyond this date * * will be granted. * * * * To avoid last minute problems, * * authors are encouraged to submit * * their papers well in advance of the * * deadline. * * * ******************************************* SCOPE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. The conference is sponsored by the technical committees on computer communications of the IEEE Communications and Computers Societies. The Infocom 2000 organizing committee is soliciting original papers describing state-of-the-art research and development in all areas of computer networking and data communications. Topics of interest include, but are not limited to, the following: Active Networks Network Management and Control BISDN and ATM Network Reliability Billing and Pricing Network Restoration Congestion and Admission Control Network Signaling Distributed Network Algorithms Network Standards High-Speed Network Protocols Network and Protocol Performance Integrated Control of Networks Optical Networks Intelligent Networks Personal Communications Systems Internet Photonic Switching Internetworking Protocol Design and Analysis Lightwave Networks Quality of Service Mobility Routing and Routing Protocols Multicast/Broadcast Algorithms Security and Privacy Multimedia Protocols Switch Architectures Multimedia Terminals and Systems Testbeds and Measurements Multiple Access Traffic Management and Control Network Architectures Video Networking Network Design and Planning Wireless Networks and Protocols PAPER SUBMISSION ================ Papers must be submitted electronically in the manner and format detailed below. Authors for whom this presents a severe problem should contact one of the technical program committee co-chairs to discuss alternatives. Papers must be formatted according to the IEEE standard double-column format except for the font size, which must be 11pt. To make it easy to adhere to the formatting standard we offer templates and samples for LaTex, MSWord, and FrameMaker (consult at the web pages referenced on top of this message). Submission must be in PDF. However, the committee will also accept Postscript from Latex, FrameMaker, or MSWord source file. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. (Postscript output from MSWord typically does not work on non-Microsoft platforms. The use of the Apple LaserWriter II printer driver is strongly recommended). The above formatted papers can be submitted in a compressed form (gzip, zip, compress). Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, ------------------------------------------------------ |papers with more than 11 pages will not be reviewed.| ------------------------------------------------------ Papers must be submitted electronically using the Web site at . This web page contains exact and detailed instructions. The submission process includes providing detailed contact information. Authors may omit this information from the paper itself. Authors will receive an immediate notification of the successful receipt of the file containing their paper. Subsequently, a notification will be sent if the paper cannot be printed successfully. --------------------------------------------------------- |Submissions will only be accepted until July 5th, 1999.| --------------------------------------------------------- Submission deadlines are strict! Papers that have been improperly submitted or improperly formatted by the submission date will not be considered. To avoid last minute problems, authors are encouraged to submit their papers well in advance of the deadline. THE REVIEW PROCESS ================== Each paper will typically be reviewed by three independent reviewers, whose reviews will be relayed to the corresponding author. To facilitate the review process authors will be asked to classify the paper according to a list of categories so that the most appropriate reviewers handle the paper. This year a new step will be introduced into the process whereby authors will have a chance to provide a limited rebuttal on the reviews before the program committee makes its final decision. TRAVEL GRANTS ============= Limited travel assistance to students, post-docs and junior faculty for defraying some of the costs of presenting a paper in the conference will be available. Please refer to the conference web sites for further details later this year. IMPORTANT DATES =============== Complete paper due July 5, 1999 Notification of acceptance October 31, 1999 Final version due December 3, 1999 PROGRAM COMMITTEE CO-CHAIRS [infocom@comnet9.technion.ac.il] =========================== Raphael Rom, Technion, Israel Henning Schulzrinne, Columbia University, USA From owner-tcp-impl@lerc.nasa.gov Tue Jun 29 13:06:36 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15405 for ; Tue, 29 Jun 1999 13:06:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA01113 for tcp-impl-outgoing; Tue, 29 Jun 1999 09:48:37 -0400 (EDT) Received: from atlrel1.hp.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA01108 for ; Tue, 29 Jun 1999 09:48:35 -0400 (EDT) Received: from loiter.cup.hp.com (raj@loiter.cup.hp.com [15.8.80.103]) by atlrel1.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id JAA05146; Tue, 29 Jun 1999 09:48:02 -0400 (EDT) Received: (from raj@localhost) by loiter.cup.hp.com (8.8.6/8.7.3 TIS Messaging 5.0) id GAA04428; Tue, 29 Jun 1999 06:48:27 -0700 (PDT) From: Rick Jones Message-Id: <199906291348.GAA04428@loiter.cup.hp.com> Subject: Re: Nagle -- again To: minshall@siara.com (Greg Minshall) Date: Tue, 29 Jun 1999 6:48:27 PDT Cc: tcp-impl@grc.nasa.gov In-Reply-To: <199906242004.NAA08953@red.mtv.siara.com>; from "Greg Minshall" at Jun 24, 99 1:04 pm X-Mailer: Elm [revision: 212.2] Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > however, if your host is generating 52,000 *data* packets per > second, i wonder if getting 26,000 ACKs per second *should* be a > problem. (i don't doubt that it *is* a problem, but *should* it be > a problem?) depends on ones definition of "problem." with copy-avoidance and checksum offload, the processing costs of an ACK are not that much less than a data packet, so 26k ACKs would probably be about 25 to 30 percent of the CPU consumed. one of those lifetime employment discussion areas - save CPU cycles, or send lots of acks to avoid possible burst problems... :) rick jones