From owner-tcp-impl@lerc.nasa.gov Mon May 1 16:53:48 2000 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 QAA06153 for ; Mon, 1 May 2000 16:53:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA27402 for tcp-impl-outgoing; Mon, 1 May 2000 13:48:11 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA27387 for ; Mon, 1 May 2000 13:48:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA03004; Mon, 1 May 2000 13:48:07 -0400 (EDT) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002956; Mon, 1 May 00 13:47:46 -0400 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.3) with ESMTP id KAA96842; Mon, 1 May 2000 10:47:33 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <200005011747.KAA96842@elk.aciri.org> To: fdufour@erols.com cc: tcp-impl@grc.nasa.gov From: Sally Floyd Subject: Re: Question regarding direction TCP/IP development Date: Mon, 01 May 2000 10:47:33 -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Would anyone be able to give me a good feel for what >direction TCP/IP will take with respect to congestion >control? You could look at my viewgraphs from a talk last year on "On the Evolution of End-to-end Congestion Control in the Internet: An idiosyncratic View", from October 1999, or an earlier talk on "On the Evolution of End-to-end Congestion Control in the Internet" from April 1999. The viewgraphs are pointed-to on my web page at "http://www.aciri.org/floyd/talks.html". The section on pages 18-27, from the October talk, mentions briefly some of the changes in progress, such as ECN, and the section beginning on page 28 talks about some of the different views for the long-term evolution of end-to-end congestion control. (This is elaborated on in the viewgraphs from the April talk.) - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-tcp-impl@lerc.nasa.gov Wed May 3 15:35:57 2000 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 PAA09749 for ; Wed, 3 May 2000 15:35:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA10212 for tcp-impl-outgoing; Wed, 3 May 2000 12:37:00 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA10165; Wed, 3 May 2000 12:36:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA26809; Wed, 3 May 2000 12:36:56 -0400 (EDT) Received: from marjan.fesb.hr(161.53.166.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026727; Wed, 3 May 00 12:36:40 -0400 Received: from jurica (jurica.fesb.hr [161.53.166.43]) by marjan.fesb.hr (8.9.3/8.9.3) with SMTP id QAA28417; Wed, 3 May 2000 16:00:17 +0200 (MET DST) Message-ID: <059f01bfb508$a8ce4740$2ba635a1@fesb.hr> From: "SoftCOM Secretary" To: "SoftCOM Mailing List" Subject: Second Call for Papers Date: Wed, 3 May 2000 16:01:17 +0200 Organization: FESB, University of Split MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dear All A Gentle Reminder * Kindly ignore this email if you have received this before. Please give * this remainder to your coleagues that might be interested. Thank you for your kind attention and cooperation. *********************************************************** The 8th IEEE International Conference on Software, Telecommunications and Computer networks (SoftCOM 2000) will be held from October 11-14, 2000 aboard the luxury ship Marko Polo travelling on the route Split (Croatia) - Rijeka (Croatia) - Trieste (Italy) - Venice (Italy) - Dubrovnik (Croatia). The aim of the conference is to provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of telecommunication and computer networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can be obtained at this web site: http://www.fesb.hr/SoftCOM We look forward to your participation. Thank you. SoftCOM 2000 Organizing Committee From owner-tcp-impl@lerc.nasa.gov Thu May 11 09:53:10 2000 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 JAA28109 for ; Thu, 11 May 2000 09:53:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA24676 for tcp-impl-outgoing; Thu, 11 May 2000 06:58:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA24668 for ; Thu, 11 May 2000 06:58:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA10099; Thu, 11 May 2000 06:58:12 -0400 (EDT) Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010067; Thu, 11 May 00 06:57:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23563; Thu, 11 May 2000 06:57:44 -0400 (EDT) Message-Id: <200005111057.GAA23563@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: tcp-impl@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-tcpimpl-pmtud-03.txt Date: Thu, 11 May 2000 06:57:44 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Implementation Working Group of the IETF. Title : TCP Problems with Path MTU Discovery Author(s) : K. Lahey Filename : draft-ietf-tcpimpl-pmtud-03.txt Pages : 16 Date : 10-May-00 This memo catalogs several known TCP implementation problems dealing with Path MTU Discovery [RFC1191], including the long-standing black hole problem, stretch ACKs due to confusion between MSS and segment size, and MSS advertisement based on PMTU. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpimpl-pmtud-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpimpl-pmtud-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000510111808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpimpl-pmtud-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpimpl-pmtud-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510111808.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-tcp-impl@lerc.nasa.gov Mon May 15 12:28:39 2000 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 MAA06705 for ; Mon, 15 May 2000 12:28:39 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA14777 for tcp-impl-outgoing; Mon, 15 May 2000 09:18:03 -0400 (EDT) Received: from guns (guns.lerc.nasa.gov [139.88.44.160]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA14717; Mon, 15 May 2000 09:17:34 -0400 (EDT) Message-Id: <200005151317.JAA14717@lombok-fi.lerc.nasa.gov> To: tcp-impl@grc.nasa.gov Cc: "Vern Paxson" , kml@logictier.com From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: WG last call on pmtud doc Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Whole Lotta Love Date: Mon, 15 May 2000 09:17:34 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk We are starting a WG last call on the I-D "TCP Problems with Path MTU Discovery" (draft-ietf-tcpimpl-pmtud-03.txt). We plan to submit the draft to the IESG as a candidate for an Informational RFC. Please send comments on the draft to the list or the author before 5/31. Thanks, allman From owner-tcp-impl@lerc.nasa.gov Mon May 22 14:16:29 2000 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 OAA07356 for ; Mon, 22 May 2000 14:16:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA00009 for tcp-impl-outgoing; Mon, 22 May 2000 11:20:28 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA29962 for ; Mon, 22 May 2000 11:20:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA26552; Mon, 22 May 2000 11:20:22 -0400 (EDT) Received: from prv-mail20.provo.novell.com(137.65.81.122) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026510; Mon, 22 May 00 11:20:21 -0400 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 22 May 2000 08:50:58 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 22 May 2000 08:50:48 -0600 From: "Ramesh Shankar" To: Subject: Slow start question ... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id LAA29996 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit If the peer to which a TCP connection has been established is on a "direct connected" network (i.e. the route doesn't point to a gateway), why exactly is slow start required? Linux and NetBSD seem to do slow start for this case while FreeBSD doesn't seem to (I haven't picked through the source to verify this though). Since slow start is meant to "probe the available network bandwidth" of a route (involving routers), it seems to me that I really shouldn't have to use slow start for the case mentioned above. One of the e-mails in this list mentioned a case where the outbound interface queue was overwhelmed by a burst of packets when slow start was not used. Slow start seems to be a wrong way to solve this problem. This problem could happen even when too many connections are opened, and hence is a fundamental inter-layer flow control problem. Any insight would be greatly appreciated. Thanks, S.R. From owner-tcp-impl@lerc.nasa.gov Mon May 22 15:19:15 2000 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 PAA08376 for ; Mon, 22 May 2000 15:19:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA19330 for tcp-impl-outgoing; Mon, 22 May 2000 12:59:38 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA19313 for ; Mon, 22 May 2000 12:59:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA14914; Mon, 22 May 2000 12:59:36 -0400 (EDT) Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014847; Mon, 22 May 00 12:59:06 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 12tvVH-0001Uy-00; Mon, 22 May 2000 17:56:31 +0100 Subject: Re: Slow start question ... To: RSHANKAR@novell.com (Ramesh Shankar) Date: Mon, 22 May 2000 17:56:30 +0100 (BST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: from "Ramesh Shankar" at May 22, 2000 08:50:48 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > If the peer to which a TCP connection has been established is on a "direct connected" network (i.e. the route doesn't point to a gateway), why exactly is slow start required? Linux and NetBSD seem to do slow start for this case while FreeBSD doesn't seem to (I haven't picked through the source to verify this though). Since slow start is meant to "probe the available network bandwidth" of a route (involving routers), it seems to me that I really shouldn't have to use slow start for the case mentioned above. Your definition of direct connected includes things like ATM networks, slow dialup links, and even IPIP tunnels across the internet. Are you telling me you dont want slow start on these ? The fundamental flaw in your argument is to assume the routers are at IP level. There are resource issues both on all networks including your own buffering on modems, switches, bridges and other devices below the IP layer. The slow start procedure makes us behave well to them as well. Alan From owner-tcp-impl@lerc.nasa.gov Mon May 22 15:28:56 2000 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 PAA08617 for ; Mon, 22 May 2000 15:28:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21839 for tcp-impl-outgoing; Mon, 22 May 2000 13:16:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA21788 for ; Mon, 22 May 2000 13:16:12 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA17774; Mon, 22 May 2000 13:16:08 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017708; Mon, 22 May 00 13:15:36 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id KAA29318; Mon, 22 May 2000 10:15:34 -0700 Reply-To: mahdavi@novell.com To: "Ramesh Shankar" Cc: Subject: Re: Slow start question ... References: From: Jamshid Mahdavi Date: 22 May 2000 10:15:34 -0700 In-Reply-To: "Ramesh Shankar"'s message of "Mon, 22 May 2000 08:50:48 -0600" Message-ID: Lines: 37 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk There is also no way of knowing what the layer 2 topology is. For example, you could be sending out of a 100 Mb/s interface, but the receiver might only be on a 10 Mb/s interface. These days, pretty much anything can be bridged together; wireless, DSL, ATM, and more could all be quietly masquerading as part of your "local ethernet". Since there can be congestion on any of these transitions, it is still necessary to do slowstart and congestion avoidance to hosts on the local network. --J "Ramesh Shankar" writes: > If the peer to which a TCP connection has been established is on a > "direct connected" network (i.e. the route doesn't point to a > gateway), why exactly is slow start required? Linux and NetBSD seem > to do slow start for this case while FreeBSD doesn't seem to (I > haven't picked through the source to verify this though). Since slow > start is meant to "probe the available network bandwidth" of a route > (involving routers), it seems to me that I really shouldn't have to > use slow start for the case mentioned above. > > One of the e-mails in this list mentioned a case where the outbound > interface queue was overwhelmed by a burst of packets when slow > start was not used. Slow start seems to be a wrong way to solve this > problem. This problem could happen even when too many connections > are opened, and hence is a fundamental inter-layer flow control > problem. > > Any insight would be greatly appreciated. > > Thanks, > > S.R. From owner-tcp-impl@lerc.nasa.gov Mon May 22 19:16:27 2000 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 TAA11008 for ; Mon, 22 May 2000 19:16:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA17658 for tcp-impl-outgoing; Mon, 22 May 2000 16:06:41 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA17628 for ; Mon, 22 May 2000 16:06:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA16693; Mon, 22 May 2000 16:06:38 -0400 (EDT) Message-Id: <200005222006.QAA16693@seraph3.lerc.nasa.gov> Received: from be.be.com(208.243.144.2) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016662; Mon, 22 May 00 16:06:13 -0400 Received: (qmail 5995 invoked from network); 22 May 2000 20:15:09 -0000 Received: from gpz.be.com (10.113.216.32) by mail.be.com with SMTP; 22 May 2000 20:15:09 -0000 To: Alan Cox Subject: Re: Slow start question ... Cc: RSHANKAR@novell.com (Ramesh Shankar), tcp-impl@grc.nasa.gov Date: Mon, 22 May 2000 13:08:57 PDT From: "Howard Berkey" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Reply-To: howard@be.com X-Mailer: BeOS Mail Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Seems like a moot point anyway, since in the case of sending to someone on the same LAN segment as yourself (i.e. not routed), slow start will be exited quickly if the amount of data being transferred on the connection exceeds a couple mtu's in size. Howard >> If the peer to which a TCP connection has been established is on a "direct connected" network (i.e. the route doesn't point to a gateway), why exactly is slow start required? Linux and NetBSD seem to do slow start for this case while FreeBSD doesn't seem to (I haven't picked through the source to verify this though). Since slow start is meant to "probe the available network bandwidth" of a route (involving routers), it seems to me that I really shouldn't have to use slow start for the case mentioned above. > >Your definition of direct connected includes things like ATM networks, slow >dialup links, and even IPIP tunnels across the internet. > >Are you telling me you dont want slow start on these ? > >The fundamental flaw in your argument is to assume the routers are at IP level. >There are resource issues both on all networks including your own buffering >on modems, switches, bridges and other devices below the IP layer. The >slow start procedure makes us behave well to them as well. > >Alan > > From owner-tcp-impl@lerc.nasa.gov Mon May 22 23:17:58 2000 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 XAA14549 for ; Mon, 22 May 2000 23:17:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA08107 for tcp-impl-outgoing; Mon, 22 May 2000 20:50:58 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA08093 for ; Mon, 22 May 2000 20:50:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA22416; Mon, 22 May 2000 20:50:57 -0400 (EDT) Received: from prv-mail20.provo.novell.com(137.65.81.122) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022391; Mon, 22 May 00 20:50:24 -0400 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 22 May 2000 17:21:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 22 May 2000 17:21:39 -0600 From: "Ramesh Shankar" To: Subject: Any successor to the sockets APIs ??? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id UAA08099 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit I am curious to know whether there is any work in progress on a successor to the BSD (or for that matter Winsock) sockets API. The following are the reasons for the question: - The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been known for sometime now. Winsock has some interesting APIs which seem to help somewhat better than BSD sockets APIs. - I have been reading about the performance issues with persistent HTTP connection, pipelined requests and how the responses have to be sequential as there is no clear way to demarcate invidual TCP sessions etc (Work by Jeff Mogul and Venkata Padmanabhan). Is there a move towards some kind of APIs like that? (I haven't yet finished the Ph.D. thesis though to understand more details on the nature of APIs). Any pointers would be greatly appreciated. S.R. From owner-tcp-impl@lerc.nasa.gov Mon May 22 23:32:57 2000 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 XAA15022 for ; Mon, 22 May 2000 23:32:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA09223 for tcp-impl-outgoing; Mon, 22 May 2000 21:13:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA09203 for ; Mon, 22 May 2000 21:13:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA24897; Mon, 22 May 2000 21:13:27 -0400 (EDT) Received: from prv-mail20.provo.novell.com(137.65.81.122) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024845; Mon, 22 May 00 21:12:53 -0400 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 22 May 2000 17:45:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 22 May 2000 17:45:23 -0600 From: "Ramesh Shankar" To: Subject: What is so special about 2*MSL? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id VAA09209 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit It is not very clear to me what is the purpose of selecting 2*MSL to be the duration a connection which has performed active close has to be in the TIME_WAIT state instead of MSL. TIME_WAIT serves two different purposes: 1. Rejection old duplicates of a connection from previous incarnation(s). 2. Retransmission of last ACK if ACK sent during connection close got lost. This ensures reliable connection close. If we were to consider 1, then it is quite clear that waiting for 1 MSL is more than enough for old duplicates to die off. Now, 2 really depends on the RTT of the connection. If one imagines that it takes 1MSL (i.e. extreme case) for our ACK to reach peer, then in the case our ACK does get lost, by the time the peer retransmits the FIN, we would have anyway exited the TIME_WAIT state. RFC 1185, Appendix A has some insight into the details of the choice, but doesn't go far enough to tell why 2MSL and why not 1MSL or 1.5 MSL etc. I am pretty sure that there is some historical reason also associated with the choice of this specific value. Some of the references of Appendix A of RFC 1185 are probably very hard to get now (Any idea how I can get them)? May be the answer is simple like: Be paranoid and wait for more than 1 MSL and it is easy to implement 2 * MSL in programming rather than 1.75 * MSL :-))). Thanks in advance, S.R. From owner-tcp-impl@lerc.nasa.gov Tue May 23 03:39:18 2000 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 DAA28227 for ; Tue, 23 May 2000 03:39:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA19139 for tcp-impl-outgoing; Tue, 23 May 2000 01:00:02 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA19115 for ; Tue, 23 May 2000 01:00:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA18976; Tue, 23 May 2000 00:59:59 -0400 (EDT) Received: from camel.ethereal.net(216.200.22.209) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018956; Tue, 23 May 00 00:59:22 -0400 Received: (from jkb@localhost) by camel.ethereal.net (8.10.0.Beta10/8.10.0.Beta10) id e4N4xIQ43984; Mon, 22 May 2000 21:59:18 -0700 (PDT) Date: Mon, 22 May 2000 21:59:18 -0700 From: Jan Koum To: Jamshid Mahdavi Cc: Ramesh Shankar , tcp-impl@grc.nasa.gov, Matthew Dillon , jayanth@freebsd.org Subject: Re: Slow start question ... Message-ID: <20000522215918.D39617@ethereal.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.1i In-Reply-To: ; from mahdavi@novell.com on Mon, May 22, 2000 at 10:15:34AM -0700 X-Operating-System: FreeBSD camel.ethereal.net 3.4-RELEASE FreeBSD 3.4-RELEASE X-Unix-Uptime: 8:11PM up 17 days, 6:48, 30 users, load averages: 1.15, 1.17, 1.16 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk looking at freebsd, it seem that slowstart *is* disabled for local network: $ sysctl -a|grep slowstart net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 65535 this is probably correct for 95% of the time, since having bridged wireless and atm are not very common. but you are right, to be 100% correct, freebsd should probably also have local slowstart enabled. -- yan On Mon, May 22, 2000 at 10:15:34AM -0700, Jamshid Mahdavi wrote: > > There is also no way of knowing what the layer 2 topology is. For > example, you could be sending out of a 100 Mb/s interface, but the > receiver might only be on a 10 Mb/s interface. These days, pretty > much anything can be bridged together; wireless, DSL, ATM, and more > could all be quietly masquerading as part of your "local ethernet". > > Since there can be congestion on any of these transitions, it is still > necessary to do slowstart and congestion avoidance to hosts on the > local network. > > --J > > > "Ramesh Shankar" writes: > > > If the peer to which a TCP connection has been established is on a > > "direct connected" network (i.e. the route doesn't point to a > > gateway), why exactly is slow start required? Linux and NetBSD seem > > to do slow start for this case while FreeBSD doesn't seem to (I > > haven't picked through the source to verify this though). Since slow > > start is meant to "probe the available network bandwidth" of a route > > (involving routers), it seems to me that I really shouldn't have to > > use slow start for the case mentioned above. > > > > One of the e-mails in this list mentioned a case where the outbound > > interface queue was overwhelmed by a burst of packets when slow > > start was not used. Slow start seems to be a wrong way to solve this > > problem. This problem could happen even when too many connections > > are opened, and hence is a fundamental inter-layer flow control > > problem. > > > > Any insight would be greatly appreciated. > > > > Thanks, > > > > S.R. From owner-tcp-impl@lerc.nasa.gov Tue May 23 07:31:26 2000 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 HAA00546 for ; Tue, 23 May 2000 07:31:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA00528 for tcp-impl-outgoing; Tue, 23 May 2000 04:28:35 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA00512 for ; Tue, 23 May 2000 04:28:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA10753; Tue, 23 May 2000 04:28:33 -0400 (EDT) Received: from laurin.munich.netsurf.de(194.64.166.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010738; Tue, 23 May 00 04:28:27 -0400 Received: from fred.muc.de (none@ns1086.munich.netsurf.de [195.180.235.86]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id KAA25686; Tue, 23 May 2000 10:28:18 +0200 (MET DST) Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 12uA3D-0000GD-00; Tue, 23 May 2000 10:28:31 +0200 Date: Tue, 23 May 2000 10:28:31 +0200 From: Andi Kleen To: Ramesh Shankar Cc: tcp-impl@grc.nasa.gov Subject: Re: Any successor to the sockets APIs ??? Message-ID: <20000523102831.B974@fred.muc.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: ; from Ramesh Shankar on Tue, May 23, 2000 at 05:25:56AM +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Tue, May 23, 2000 at 05:25:56AM +0200, Ramesh Shankar wrote: > I am curious to know whether there is any work in progress on a successor to the BSD (or for that matter Winsock) sockets API. The following are the reasons for the question: > > - The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been known for sometime now. Winsock has some interesting APIs which seem to help somewhat better than BSD sockets APIs. Single Unix defines a replacement: real time signals that carry fd event notifications. They unfortunately require a non standard extension to set the SIGIO signal for a fd to be really useful (or another non standard extension for queued SIGIO). At least in modern Linux it is supported. poll() is still needed as fallback when signals get lost. From first tests queued SIGIO with a sigwaitinfo() main loop scales very nicely for web servers. -Andi From owner-tcp-impl@lerc.nasa.gov Tue May 23 12:13:24 2000 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 MAA05850 for ; Tue, 23 May 2000 12:13:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA16852 for tcp-impl-outgoing; Tue, 23 May 2000 08:41:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA16805 for ; Tue, 23 May 2000 08:41:21 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA08158; Tue, 23 May 2000 08:41:19 -0400 (EDT) Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008096; Tue, 23 May 00 08:40:51 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 12uDxB-00037H-00; Tue, 23 May 2000 13:38:33 +0100 Subject: Re: Any successor to the sockets APIs ??? To: RSHANKAR@novell.com (Ramesh Shankar) Date: Tue, 23 May 2000 13:38:30 +0100 (BST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: from "Ramesh Shankar" at May 22, 2000 05:21:39 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > - The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been known for sometime now. Winsock has some interesting APIs which seem to help somewhat better than BSD sockets APIs. Linux supports event based real time signalling (kind of vaguely akin to the VMS AST setup). There are plenty of people who find poll/select scale nicely. Under load your syscalls/task count drops which materially improves your throughput. Thus as the load goes up degradation is good. Point a big internet client simulation (not crap like specweb) at a threaded or multiprocess server like apache and then try it with thttpd. Its not the simple set of equations some people think. [Apache btw suffers, thttpd just keeps going. apache is faster for small loads] Alan From owner-tcp-impl@lerc.nasa.gov Tue May 23 12:38:05 2000 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 MAA06286 for ; Tue, 23 May 2000 12:38:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA23944 for tcp-impl-outgoing; Tue, 23 May 2000 09:30:11 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA23910 for ; Tue, 23 May 2000 09:30:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA16021; Tue, 23 May 2000 09:30:08 -0400 (EDT) Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015926; Tue, 23 May 00 09:29:33 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 12uEhE-0003CI-00; Tue, 23 May 2000 14:26:08 +0100 Subject: Re: Slow start question ... To: howard@be.com Date: Tue, 23 May 2000 14:26:07 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), RSHANKAR@novell.com (Ramesh Shankar), tcp-impl@grc.nasa.gov In-Reply-To: from "Howard Berkey" at May 22, 2000 01:08:57 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Seems like a moot point anyway, since in the case of sending to someone > on the same LAN segment as yourself (i.e. not routed), slow start will > be exited quickly if the amount of data being transferred on the > connection exceeds a couple mtu's in size. The difference is in that tiny time period starting up if there is congestion we don't swamp the lan. But yes the only reason to disable slow start is benchmarketing. For real world use it should be lost in the noise From owner-tcp-impl@lerc.nasa.gov Tue May 23 13:24:23 2000 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 NAA06761 for ; Tue, 23 May 2000 13:24:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA03718 for tcp-impl-outgoing; Tue, 23 May 2000 10:39:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA03673 for ; Tue, 23 May 2000 10:39:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA27072; Tue, 23 May 2000 10:39:55 -0400 (EDT) Received: from naughty.monkey.org(63.77.239.20) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027028; Tue, 23 May 00 10:39:51 -0400 Received: by naughty.monkey.org (Postfix, from userid 1035) id 21684108607; Tue, 23 May 2000 10:39:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by naughty.monkey.org (Postfix) with ESMTP id 1ECD5107740; Tue, 23 May 2000 10:39:42 -0400 (EDT) Date: Tue, 23 May 2000 10:39:41 -0400 (EDT) From: Chuck Lever To: tcp-impl@grc.nasa.gov Cc: RSHANKAR@novell.com Subject: Re: Any successor to the sockets APIs ??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk hi ramesh & al. - our research shows that providing a more efficient poll() interface scales as well as the new RT signals. niels provos implemented /dev/poll in Linux (see our Freenix track paper for Usenix 2000). we benchmarked thttpd using /dev/poll against phhttpd, an experimental web server that uses Posix RT signals. RT signals are still a young programming model, so there are issues with using them: portability among operating systems, how to share them among libraries, lack of support for sharing signal queues among threads, and so on. of great concern to us is the use of poll() for handling an RT signal queue overflow: poll() must be much more efficient to be an effective overflow remedy. at this point, i don't think we understand how to use RT signals most effectively. but poll is well-understood, so it's easy to change applications to use /dev/poll and see a significant scalability improvement. - Chuck Lever -- corporate: personal: The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/ Date: Tue, 23 May 2000 10:28:31 +0200 From: Andi Kleen To: Ramesh Shankar Cc: tcp-impl@grc.nasa.gov Subject: Re: Any successor to the sockets APIs ??? On Tue, May 23, 2000 at 05:25:56AM +0200, Ramesh Shankar wrote: > I am curious to know whether there is any work in progress on a successor to the BSD (or for that matter Winsock) sockets API. The following are the reasons for the question: > > - The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been known for sometime now. Winsock has some interesting APIs which seem to help somewhat better than BSD sockets APIs. Single Unix defines a replacement: real time signals that carry fd event notifications. They unfortunately require a non standard extension to set the SIGIO signal for a fd to be really useful (or another non standard extension for queued SIGIO). At least in modern Linux it is supported. poll() is still needed as fallback when signals get lost. >From first tests queued SIGIO with a sigwaitinfo() main loop scales very nicely for web servers. - -Andi From owner-tcp-impl@lerc.nasa.gov Tue May 23 15:22:45 2000 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 PAA08390 for ; Tue, 23 May 2000 15:22:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA19326 for tcp-impl-outgoing; Tue, 23 May 2000 12:30:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA19310 for ; Tue, 23 May 2000 12:30:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA15696; Tue, 23 May 2000 12:30:57 -0400 (EDT) Received: from wren.cs.unc.edu(152.2.128.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015677; Tue, 23 May 00 12:30:52 -0400 Received: from cs.unc.edu (root@buzzard.cs.unc.edu [152.2.129.17]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id MAA25788; Tue, 23 May 2000 12:30:45 -0400 (EDT) Message-ID: <392AB240.6EF60106@cs.unc.edu> Date: Tue, 23 May 2000 12:30:56 -0400 From: Michele Clark Reply-To: clark@cs.unc.edu X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Koum CC: tcp-impl@grc.nasa.gov Subject: Re: Slow start question ... References: <20000522215918.D39617@ethereal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Which version are you running? In FreeBSD 2.2.8, there's a sysctl option net.inet.tcp.no_local_slowstart. It's default value is 0, I believe, which forces slow start on the local network. (This option wasn't present before 2.2.8.) -Michele Jan Koum wrote: > > looking at freebsd, it seem that slowstart *is* disabled for local > network: > > $ sysctl -a|grep slowstart > net.inet.tcp.slowstart_flightsize: 1 > net.inet.tcp.local_slowstart_flightsize: 65535 > > this is probably correct for 95% of the time, since having bridged > wireless and atm are not very common. but you are right, to be 100% > correct, freebsd should probably also have local slowstart enabled. > > -- yan > > On Mon, May 22, 2000 at 10:15:34AM -0700, Jamshid Mahdavi wrote: > > > > There is also no way of knowing what the layer 2 topology is. For > > example, you could be sending out of a 100 Mb/s interface, but the > > receiver might only be on a 10 Mb/s interface. These days, pretty > > much anything can be bridged together; wireless, DSL, ATM, and more > > could all be quietly masquerading as part of your "local ethernet". > > > > Since there can be congestion on any of these transitions, it is still > > necessary to do slowstart and congestion avoidance to hosts on the > > local network. > > > > --J > > > > > > "Ramesh Shankar" writes: > > > > > If the peer to which a TCP connection has been established is on a > > > "direct connected" network (i.e. the route doesn't point to a > > > gateway), why exactly is slow start required? Linux and NetBSD seem > > > to do slow start for this case while FreeBSD doesn't seem to (I > > > haven't picked through the source to verify this though). Since slow > > > start is meant to "probe the available network bandwidth" of a route > > > (involving routers), it seems to me that I really shouldn't have to > > > use slow start for the case mentioned above. > > > > > > One of the e-mails in this list mentioned a case where the outbound > > > interface queue was overwhelmed by a burst of packets when slow > > > start was not used. Slow start seems to be a wrong way to solve this > > > problem. This problem could happen even when too many connections > > > are opened, and hence is a fundamental inter-layer flow control > > > problem. > > > > > > Any insight would be greatly appreciated. > > > > > > Thanks, > > > > > > S.R. From owner-tcp-impl@lerc.nasa.gov Tue May 23 15:27:50 2000 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 PAA08440 for ; Tue, 23 May 2000 15:27:49 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA22923 for tcp-impl-outgoing; Tue, 23 May 2000 12:58:00 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA22903 for ; Tue, 23 May 2000 12:57:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA19881; Tue, 23 May 2000 12:57:58 -0400 (EDT) Received: from info.iet.unipi.it(131.114.9.184) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019840; Tue, 23 May 00 12:57:21 -0400 Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id SAA24184; Tue, 23 May 2000 18:57:24 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200005231657.SAA24184@info.iet.unipi.it> Subject: Re: Slow start question ... In-Reply-To: <392AB240.6EF60106@cs.unc.edu> from Michele Clark at "May 23, 2000 12:30:56 pm" To: clark@cs.unc.edu Date: Tue, 23 May 2000 18:57:24 +0200 (CEST) CC: Jan Koum , tcp-impl@grc.nasa.gov X-Mailer: ELM [version 2.4ME+ PL61 (25)] 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 > Which version are you running? > > In FreeBSD 2.2.8, there's a sysctl option > net.inet.tcp.no_local_slowstart. It's default value is 0, I > believe, which forces slow start on the local network. (This option > wasn't present before 2.2.8.) actually the default is as before so it does not do slow_start on the local network (i.e. blasts a whole window of data at startup). I introduced this because experiments with dummynet (where you usally end up using local machines) would give unrealistic results otherwise. cheers luigi > -Michele > > Jan Koum wrote: > > > > looking at freebsd, it seem that slowstart *is* disabled for local > > network: -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- From owner-tcp-impl@lerc.nasa.gov Tue May 23 15:58:40 2000 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 PAA08791 for ; Tue, 23 May 2000 15:58:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA28779 for tcp-impl-outgoing; Tue, 23 May 2000 13:40:03 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA28753 for ; Tue, 23 May 2000 13:40:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA26621; Tue, 23 May 2000 13:39:59 -0400 (EDT) Message-Id: <200005231739.NAA26621@seraph3.lerc.nasa.gov> Received: from be.be.com(208.243.144.2) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026591; Tue, 23 May 00 13:39:29 -0400 Received: (qmail 16872 invoked from network); 23 May 2000 17:48:25 -0000 Received: from gpz.be.com (10.113.216.32) by mail.be.com with SMTP; 23 May 2000 17:48:25 -0000 To: Alan Cox Subject: Re: Any successor to the sockets APIs ??? Cc: RSHANKAR@novell.com (Ramesh Shankar), tcp-impl@grc.nasa.gov Date: Tue, 23 May 2000 10:42:38 PDT From: "Howard Berkey" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Reply-To: howard@be.com X-Mailer: BeOS Mail Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk >> - The BSD sockets API does not have a really powerful interface for use with event driven programming. select() and poll() are available, but the performance issues associated with it have been known for sometime now. Winsock has some interesting APIs which seem to help somewhat better than BSD sockets APIs. > >Linux supports event based real time signalling (kind of vaguely akin to the >VMS AST setup). There are plenty of people who find poll/select scale nicely. >Under load your syscalls/task count drops which materially improves your >throughput. Thus as the load goes up degradation is good. > >Point a big internet client simulation (not crap like specweb) at a threaded >or multiprocess server like apache and then try it with thttpd. Its not the >simple set of equations some people think. > >[Apache btw suffers, thttpd just keeps going. apache is faster for small loads] > Two issues here cause select and poll to appear bad. The first is crappy OS implementations of select; the second is programmers that don't know how to properly use select in a multithreaded environment. Alan is spot on in that if you know what you are doing, select can be quite scalable, provided your OS doesn't have a brain-dead implementation (and BSD and Linux have pretty good ones). If you just throw several hundred sockets into select() and sit on it with a single thread, of course it will be a poor performer. FWIW, the select() in the networking implementation currently shipping in BeOS is very, very poor. It's one of the reasons we have rewritten the OS networking for the next release. It also seems to me that programming correctly to select() and poll() is far easier and more elegant than doing it asynchronously via SIGIO. That opens lots of potential cans of worms. Howard From owner-tcp-impl@lerc.nasa.gov Tue May 23 16:06:54 2000 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 QAA08921 for ; Tue, 23 May 2000 16:06:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA29068 for tcp-impl-outgoing; Tue, 23 May 2000 13:42:18 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA29055 for ; Tue, 23 May 2000 13:42:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA27008; Tue, 23 May 2000 13:42:15 -0400 (EDT) Received: from camel.ethereal.net(216.200.22.209) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026988; Tue, 23 May 00 13:42:07 -0400 Received: (from jkb@localhost) by camel.ethereal.net (8.10.0.Beta10/8.10.0.Beta10) id e4NHfwo79630; Tue, 23 May 2000 10:41:58 -0700 (PDT) Date: Tue, 23 May 2000 10:41:58 -0700 From: Jan Koum To: Michele Clark Cc: tcp-impl@grc.nasa.gov Subject: Re: Slow start question ... Message-ID: <20000523104158.E47375@ethereal.net> References: <20000522215918.D39617@ethereal.net> <392AB240.6EF60106@cs.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.1i In-Reply-To: <392AB240.6EF60106@cs.unc.edu>; from clark@cs.unc.edu on Tue, May 23, 2000 at 12:30:56PM -0400 X-Operating-System: FreeBSD camel.ethereal.net 3.4-RELEASE FreeBSD 3.4-RELEASE X-Unix-Uptime: 11:39PM up 17 days, 10:16, 19 users, load averages: 0.05, 0.10, 0.08 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk my output is from 4.0 -- i didn't think there was a sysctl in earlier versions since 3.x doesn't have a sysct: /* * Don't force slow-start on local network. */ if (!in_localaddr(inp->inp_faddr)) tp->snd_cwnd = mss; but 2.2.x does seem to have a sysctl: /* * Don't force slow-start on local network. * Make this depend on the sysctl variable below */ if (!no_local_slowstart || !in_localaddr(inp->inp_faddr)) tp->snd_cwnd = mss; and 2.1 does not have a sysctl: /* * Don't force slow-start on local network. */ if (!in_localaddr(inp->inp_faddr)) tp->snd_cwnd = mss; with no_local_slowstart set to 0, this evaluates to true: (!no_local_slowstart || !in_localaddr(inp->inp_faddr) so i think 2.2.8 (just like the comment indicates) does not force slow start on the local network either. -- yan On Tue, May 23, 2000 at 12:30:56PM -0400, Michele Clark wrote: > > Which version are you running? > > In FreeBSD 2.2.8, there's a sysctl option > net.inet.tcp.no_local_slowstart. It's default value is 0, I > believe, which forces slow start on the local network. (This option > wasn't present before 2.2.8.) > > -Michele > > Jan Koum wrote: > > > > looking at freebsd, it seem that slowstart *is* disabled for local > > network: > > > > $ sysctl -a|grep slowstart > > net.inet.tcp.slowstart_flightsize: 1 > > net.inet.tcp.local_slowstart_flightsize: 65535 > > > > this is probably correct for 95% of the time, since having bridged > > wireless and atm are not very common. but you are right, to be 100% > > correct, freebsd should probably also have local slowstart enabled. > > > > -- yan > > > > On Mon, May 22, 2000 at 10:15:34AM -0700, Jamshid Mahdavi wrote: > > > > > > There is also no way of knowing what the layer 2 topology is. For > > > example, you could be sending out of a 100 Mb/s interface, but the > > > receiver might only be on a 10 Mb/s interface. These days, pretty > > > much anything can be bridged together; wireless, DSL, ATM, and more > > > could all be quietly masquerading as part of your "local ethernet". > > > > > > Since there can be congestion on any of these transitions, it is still > > > necessary to do slowstart and congestion avoidance to hosts on the > > > local network. > > > > > > --J > > > > > > > > > "Ramesh Shankar" writes: > > > > > > > If the peer to which a TCP connection has been established is on a > > > > "direct connected" network (i.e. the route doesn't point to a > > > > gateway), why exactly is slow start required? Linux and NetBSD seem > > > > to do slow start for this case while FreeBSD doesn't seem to (I > > > > haven't picked through the source to verify this though). Since slow > > > > start is meant to "probe the available network bandwidth" of a route > > > > (involving routers), it seems to me that I really shouldn't have to > > > > use slow start for the case mentioned above. > > > > > > > > One of the e-mails in this list mentioned a case where the outbound > > > > interface queue was overwhelmed by a burst of packets when slow > > > > start was not used. Slow start seems to be a wrong way to solve this > > > > problem. This problem could happen even when too many connections > > > > are opened, and hence is a fundamental inter-layer flow control > > > > problem. > > > > > > > > Any insight would be greatly appreciated. > > > > > > > > Thanks, > > > > > > > > S.R. From owner-tcp-impl@lerc.nasa.gov Tue May 23 19:01:50 2000 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 TAA12820 for ; Tue, 23 May 2000 19:01:49 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA26523 for tcp-impl-outgoing; Tue, 23 May 2000 16:44:06 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA26438 for ; Tue, 23 May 2000 16:43:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA27370; Tue, 23 May 2000 16:43:57 -0400 (EDT) Received: from smtp10.atl.mindspring.net(207.69.200.246) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027306; Tue, 23 May 00 16:43:24 -0400 Received: from Spence (user-2ini819.dialup.mindspring.com [165.121.32.41]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id QAA26669 for ; Tue, 23 May 2000 16:43:18 -0400 (EDT) Reply-To: From: "John Spence" To: Subject: IPv6 Path MTU Discovery process ... Date: Tue, 23 May 2000 13:29:09 -0700 Message-ID: <000001bfc4f7$069111c0$e502a8c0@zama.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello; I sent an eMail to Jack McGann asking a question about IPv6 Path MTU Discovery. I had a question about how it was described, and thought I had an idea for a better solution. Mr. McGann answered saying that he didn't know if that had been considered, and suggested I distribute it in this forum. Here is the eMail I sent Mr. McGann - please feel free to contact me for questions and to let me know what you think. Best regards; John Spence --------------------- Hello Mr. McCann; I have read with interest "IPv6 Clearly Explained", by Pete Loshin. I read about the Path MTU Discovery process and I had a question. I went to the IETF site and researched the RFC, and I have a thought. The book, and the RFC, describe the process is described as the source node sending the largest packet permissible on it's own network - essentially the first hop. If any intervening link cannot handle packets that large, it discards the packet and sends a ICMPv6 "packet too big" message to the source. The source node drops the size of the packet to within that reported limit, and send the packet again. Perhaps it makes the final destination, perhaps another node requires even a smaller packet size, and generates another "packet too big" message for the source. This could go on for awhile. My question is this. Why not have each node in the path that supports only a smaller MTU than the source node send the "packet too big" message, but still forward a "shell packet" on towards the destination, where the "shell package" contains the minimum MTU so far along that path. Since the goal is to send a packet all the way to the destination, that information may well be needed, and it would reduce latency in a scenario where there was a "stepping down" of the MTU size allowed by intervening links as the packets approached the destination. The source node would simply wait, collecting whatever "packet still too big" ICMP messages it received from the intervening nodes (a node that could accommodate the current MTU would simply forward the shell packet forward, but would not reply to the source node), until it received a confirmation from the true destination that the packet had finally arrives. Looking over the ICMP "packet too big" messages the source had received, it could now choose the best possible MTU and proceed with confidence. Heck - we could even have the "shell packet" continue all the way to the destination node, being adjusted downward by each link along the way (if needed) - without generating any ICMP "packet too big" messages - and then make the true destination node send a message back to the source saying "a 2785byte MTU is cleared all the way through", at which time the real data transmission would begin. You would probably want the very first node that determined it needed a smaller packet generate the ICMP "packet too big" message for the source, just to let the source know it wasn't going to be clear sailing. It could mark the "shell packet" it sent forward to downstream nodes so they knew they weren't the first to demand a smaller MTU. What do you think? Good idea? I'll bet you guys thought of this - just trying to help. You at the IETF are doing a great job. ---------------------------------------------------------------------------- ----- John E Spence ZAMA NETWORKS, INC. Senior UNIX Systems Engineer 12101 International Boulevard, Seattle WA 98168-2569 wk 206.352.9262 NEXTEL 206.571.9792 fx 206.352.3918 jspence@zama.net || http://www.zama.net ------------------------------------------------------------------------- From owner-tcp-impl@lerc.nasa.gov Tue May 23 20:29:43 2000 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 UAA13796 for ; Tue, 23 May 2000 20:29:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA06760 for tcp-impl-outgoing; Tue, 23 May 2000 18:01:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA06746 for ; Tue, 23 May 2000 18:01:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA09960; Tue, 23 May 2000 18:01:18 -0400 (EDT) Received: from lespaul.process.com(192.42.95.27) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009919; Tue, 23 May 00 18:00:48 -0400 Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 May 2000 18:00:47 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBCCC@lespaul.process.com> From: Bernie Volz To: "'jspence@zama.net'" , tcp-impl@grc.nasa.gov Subject: RE: IPv6 Path MTU Discovery process ... Date: Tue, 23 May 2000 18:00:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Seems like a reasonable idea ... some comments follow: I like the idea of having the destination respond with the MTU. It's cleaner since it avoids a lot of responses and figuring out when to stop waiting for a responses (since the destination might be down - so you'd get no response) if you allow potentially all intermediate nodes to response as well. An interesting question to consider is the cost of doing this ... intermediate routers now have to be capable of generating these "shell packets" and end nodes (routers too) would need to understand the "shell packets" and respond accordingly. How well do the characteristics of this "shell packet" need to match the original packet? For example, it is always possible that different types of traffic take different paths. I think from IPv4 experience, while this idea would be an optimization, I doubt that there are many MTU drops that typically occur (at least on todays networks). The value is usually found reasonably fast (with one or two MTU drops) [I don't have any hard data to back this up, it is just a gut feeling!]. I do believe the IPv4 system, on which the IPv6 was likely built, was a "upgrade" and therefore had to work with the existing hardware/software. It is probably a bit late to require IPv6 systems to support this revised technique. But ... - Bernie Volz -----Original Message----- From: John Spence [mailto:jspence@zama.net] Sent: Tuesday, May 23, 2000 4:29 PM To: tcp-impl@grc.nasa.gov Subject: IPv6 Path MTU Discovery process ... Hello; I sent an eMail to Jack McGann asking a question about IPv6 Path MTU Discovery. I had a question about how it was described, and thought I had an idea for a better solution. Mr. McGann answered saying that he didn't know if that had been considered, and suggested I distribute it in this forum. Here is the eMail I sent Mr. McGann - please feel free to contact me for questions and to let me know what you think. Best regards; John Spence --------------------- Hello Mr. McCann; I have read with interest "IPv6 Clearly Explained", by Pete Loshin. I read about the Path MTU Discovery process and I had a question. I went to the IETF site and researched the RFC, and I have a thought. The book, and the RFC, describe the process is described as the source node sending the largest packet permissible on it's own network - essentially the first hop. If any intervening link cannot handle packets that large, it discards the packet and sends a ICMPv6 "packet too big" message to the source. The source node drops the size of the packet to within that reported limit, and send the packet again. Perhaps it makes the final destination, perhaps another node requires even a smaller packet size, and generates another "packet too big" message for the source. This could go on for awhile. My question is this. Why not have each node in the path that supports only a smaller MTU than the source node send the "packet too big" message, but still forward a "shell packet" on towards the destination, where the "shell package" contains the minimum MTU so far along that path. Since the goal is to send a packet all the way to the destination, that information may well be needed, and it would reduce latency in a scenario where there was a "stepping down" of the MTU size allowed by intervening links as the packets approached the destination. The source node would simply wait, collecting whatever "packet still too big" ICMP messages it received from the intervening nodes (a node that could accommodate the current MTU would simply forward the shell packet forward, but would not reply to the source node), until it received a confirmation from the true destination that the packet had finally arrives. Looking over the ICMP "packet too big" messages the source had received, it could now choose the best possible MTU and proceed with confidence. Heck - we could even have the "shell packet" continue all the way to the destination node, being adjusted downward by each link along the way (if needed) - without generating any ICMP "packet too big" messages - and then make the true destination node send a message back to the source saying "a 2785byte MTU is cleared all the way through", at which time the real data transmission would begin. You would probably want the very first node that determined it needed a smaller packet generate the ICMP "packet too big" message for the source, just to let the source know it wasn't going to be clear sailing. It could mark the "shell packet" it sent forward to downstream nodes so they knew they weren't the first to demand a smaller MTU. What do you think? Good idea? I'll bet you guys thought of this - just trying to help. You at the IETF are doing a great job. ---------------------------------------------------------------------------- ----- John E Spence ZAMA NETWORKS, INC. Senior UNIX Systems Engineer 12101 International Boulevard, Seattle WA 98168-2569 wk 206.352.9262 NEXTEL 206.571.9792 fx 206.352.3918 jspence@zama.net || http://www.zama.net ------------------------------------------------------------------------- From owner-tcp-impl@lerc.nasa.gov Tue May 23 22:34:19 2000 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 WAA16570 for ; Tue, 23 May 2000 22:34:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA16540 for tcp-impl-outgoing; Tue, 23 May 2000 20:29:08 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA16527 for ; Tue, 23 May 2000 20:29:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA29967; Tue, 23 May 2000 20:29:05 -0400 (EDT) Received: from sgi.sgi.com(192.48.153.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029926; Tue, 23 May 00 20:28:45 -0400 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA07865; Tue, 23 May 2000 17:28:35 -0700 (PDT) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (clock.engr.sgi.com [163.154.34.45]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA17276; Tue, 23 May 2000 17:28:32 -0700 (PDT) mail_from (zamsden@clock.engr.sgi.com) Received: from clock.engr.sgi.com (localhost [127.0.0.1]) by clock.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA14565; Tue, 23 May 2000 17:42:51 -0700 (PDT) Message-Id: <200005240042.RAA14565@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bernie Volz Cc: tcp-impl@grc.nasa.gov Subject: Re: IPv6 Path MTU Discovery process ... From: Zachary Amsden In-Reply-To: Your message of "Tue, 23 May 2000 18:00:42 EDT." <63D30D6E10CFD11190A90000F805FE8602BEBCCC@lespaul.process.com> Date: Tue, 23 May 2000 17:42:51 -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I think from IPv4 experience, while this idea would be an optimization, I > doubt that there are many MTU drops that typically occur (at least on todays > networks). The value is usually found reasonably fast (with one or two MTU > drops) [I don't have any hard data to back this up, it is just a gut > feeling!]. Yes, but how do you know when you have an MTU drop? There are plenty of black-holing routers out there that won't give you an ICMP_UNCREACH/NEEDFRAG. -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols From owner-tcp-impl@lerc.nasa.gov Tue May 23 22:34:28 2000 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 WAA16581 for ; Tue, 23 May 2000 22:34:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA15877 for tcp-impl-outgoing; Tue, 23 May 2000 20:16:28 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA15852 for ; Tue, 23 May 2000 20:16:23 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA28482; Tue, 23 May 2000 20:16:21 -0400 (EDT) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028400; Tue, 23 May 00 20:15:36 -0400 Received: from pegasus.ee.surrey.ac.uk ([131.227.88.17] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12uOpQ-0002rh-00; Wed, 24 May 2000 01:15:16 +0100 Date: Wed, 24 May 2000 01:15:15 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@pegasus.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: John Spence cc: tcp-impl@grc.nasa.gov Subject: Re: IPv6 Path MTU Discovery process ... In-Reply-To: <000001bfc4f7$069111c0$e502a8c0@zama.net> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Tue, 23 May 2000, John Spence wrote: > My question is this. Why not have each node in the path that supports only a > smaller MTU than the source node send the "packet too big" message, but > still forward a "shell packet" on towards the destination, where the "shell > package" contains the minimum MTU so far along that path. Since the goal is > to send a packet all the way to the destination, that information may well > be needed, and it would reduce latency in a scenario where there was a > "stepping down" of the MTU size allowed by intervening links as the packets > approached the destination. Er, you've just reinvented partial fragmentation. For TCP channels, sending on the first part of the packet payload doesn't really help overall latency; the overall e.g. ftp transfer doesn't get completed any faster. Full fragmentation towards the destination might reduce latency, but introduces other problems... L. PGP From owner-tcp-impl@lerc.nasa.gov Tue May 23 22:46:41 2000 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 WAA16713 for ; Tue, 23 May 2000 22:46:41 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA16787 for tcp-impl-outgoing; Tue, 23 May 2000 20:35:07 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA16781 for ; Tue, 23 May 2000 20:35:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA00716; Tue, 23 May 2000 20:35:05 -0400 (EDT) Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000666; Tue, 23 May 00 20:34:50 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 12uP5X-0004I2-00; Wed, 24 May 2000 01:31:55 +0100 Subject: Re: IPv6 Path MTU Discovery process ... To: Volz@ipworks.com (Bernie Volz) Date: Wed, 24 May 2000 01:31:54 +0100 (BST) Cc: jspence@zama.net ('jspence@zama.net'), tcp-impl@grc.nasa.gov In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEBCCC@lespaul.process.com> from "Bernie Volz" at May 23, 2000 06:00:42 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > An interesting question to consider is the cost of doing this ... > intermediate routers now have to be capable of generating these "shell > packets" and end nodes (routers too) would need to understand the "shell > packets" and respond accordingly. How well do the characteristics of this > "shell packet" need to match the original packet? For example, it is always > possible that different types of traffic take different paths. Also you have to checksum it if you want to trust it - thats more overhead that people just got off routers on the whole > doubt that there are many MTU drops that typically occur (at least on todays > networks). The value is usually found reasonably fast (with one or two MTU > drops) [I don't have any hard data to back this up, it is just a gut > feeling!]. MTU drops can make a mess on lossy wireless links and very slow stuff, but even then I see no material problems From owner-tcp-impl@lerc.nasa.gov Wed May 24 10:34:12 2000 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 KAA06687 for ; Wed, 24 May 2000 10:34:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA21617 for tcp-impl-outgoing; Wed, 24 May 2000 07:57:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA21594 for ; Wed, 24 May 2000 07:57:53 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA12758; Wed, 24 May 2000 07:57:53 -0400 (EDT) Received: from jack.see.plymouth.ac.uk(141.163.49.98) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012660; Wed, 24 May 00 07:56:59 -0400 Received: from jack.see.plym.ac.uk (bogdan@sfres1.see.plymouth.ac.uk [141.163.49.101]) by jack.see.plym.ac.uk (8.9.3/8.9.3) with ESMTP id MAA25699 for ; Wed, 24 May 2000 12:56:02 +0100 Message-ID: <392BC3A7.3E5942A3@jack.see.plym.ac.uk> Date: Wed, 24 May 2000 12:57:27 +0100 From: Bogdan Ghita Organization: NRG X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Determining the number of lost packets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody - if the content of this e-mail is not relevant to the topic of the list, then, if possible, tell me if there is any other mailing list where I could ask the question - I am trying to determine the number of lost packets for TCP connections. I created an emulated 'lossy link' (10% packet loss) using Nistnet, and downloaded a file through this link. I get the number of 'lost' packets within a connection from the program, then compare it to my estimates. The monitoring point is AFTER the lossy link, on the direction of the download. I noticed that the nearest estimator is the number of 'inverted' packets, as in the following example: 12:41:35.990251 50.234.ftp-data > ac.uk.1096: . 5841:7301(1460) ack 1 win 8760 (DF) 12:41:35.990294 ac.uk.1096 > 50.234.ftp-data: . 1:1(0) ack 7301 win 30660 (DF) [tos 0x8] 12:41:36.294567 141.163.50.234.ftp-data > ac.uk.1096: . 8761:10221(1460) ack 1 win 8760 (DF) 12:41:36.294616 ac.uk.1096 > 50.234.ftp-data: . 1:1(0) ack 7301 win 30660 (DF) [tos 0x8] 12:41:38.919563 50.234.ftp-data > ac.uk.1096: P 7301:8761(1460) ack 1 win 8760 (DF) The packet containing data 7301 - 8761 seems to be inverted but, in fact, it was lost, and this is a retransmission. The main problem with counting the inverted packets is that it fails to see a lost packet if it is at the end of a transmission window (there is no packet sent after it, no duplicate ACK and the sender retransmits it when the timer expires), which makes it inaccurate. I have tried also with the Estimated Timeout, but, because I am not measuring it right at the sending endpoint, the measurement is not as acurate as it should be, and it gives me some 'false alarms'. The question is: are there any good estimators for the number of lost packets? Any suggestions / relevant papers are welcome as well. Than kyou very much for your time Best regards Bogdan Ghita From owner-tcp-impl@lerc.nasa.gov Wed May 24 14:13:09 2000 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 OAA10471 for ; Wed, 24 May 2000 14:13:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA23318 for tcp-impl-outgoing; Wed, 24 May 2000 11:34:04 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA23295 for ; Wed, 24 May 2000 11:34:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA18114; Wed, 24 May 2000 11:34:01 -0400 (EDT) Received: from unknown(209.31.7.46) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018048; Wed, 24 May 00 11:33:31 -0400 Received: from ehsco.com (nat-external.ehsco.com [209.31.7.42]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 731; Wed, 24 May 2000 08:33:26 -0700 Message-ID: <392BF644.21D11D54@ehsco.com> Date: Wed, 24 May 2000 08:33:24 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bogdan Ghita CC: tcp-impl@grc.nasa.gov Subject: Re: Determining the number of lost packets References: <392BC3A7.3E5942A3@jack.see.plym.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > The question is: are there any good estimators for the number of lost > packets? Any suggestions / relevant papers are welcome as well. > > Than kyou very much for your time I would start by counting the duplicate ACKs. There are of course some exclude cases but by and large the presence of multiple ACKs is what TCP uses to indicate loss and that seems to be what you're really interested in, right? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com From owner-tcp-impl@lerc.nasa.gov Tue May 30 18:15:51 2000 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 SAA11842 for ; Tue, 30 May 2000 18:15:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA27423 for tcp-impl-outgoing; Tue, 30 May 2000 15:18:12 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA27389 for ; Tue, 30 May 2000 15:18:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA16622; Tue, 30 May 2000 15:18:08 -0400 (EDT) Received: from burdell.cc.gatech.edu(130.207.3.207) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016566; Tue, 30 May 00 15:17:41 -0400 Received: from jibboo.cc.gatech.edu (jibboo.cc.gatech.edu [130.207.8.94]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id PAA02371 for ; Tue, 30 May 2000 15:17:40 -0400 (EDT) Received: from cc.gatech.edu (localhost [127.0.0.1]) by jibboo.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id PAA23161 for ; Tue, 30 May 2000 15:17:39 -0400 (EDT) Message-ID: <393413D2.F332EA5C@cc.gatech.edu> Date: Tue, 30 May 2000 15:17:38 -0400 From: Hyoung-Kee Choi Organization: Georgia Institute of Technology X-Mailer: Mozilla 4.73 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: ko, en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Snoop maxcount 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 am having a problem with Snoop. Snoop abrubtly finished after recording 4 million packets although I did not specify the -c option in the command line. The trace file size is about 510MB after the Snoop run. In addition, has anyone sucessfully recorded packets in one file more than 2GB? Please teach me how i go over it. From owner-tcp-impl@lerc.nasa.gov Wed May 31 06:31:46 2000 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 GAA02621 for ; Wed, 31 May 2000 06:31:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA19622 for tcp-impl-outgoing; Wed, 31 May 2000 03:58:08 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA19615 for ; Wed, 31 May 2000 03:58:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA18124; Wed, 31 May 2000 03:58:06 -0400 (EDT) Received: from lanai.rvs.uni-hannover.de(130.75.3.211) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018091; Wed, 31 May 00 03:57:44 -0400 Received: from animal.rvs.uni-hannover.de (animal.rvs.uni-hannover.de [130.75.3.208]) by rvs.uni-hannover.de (8.9.1/8.9.1) with ESMTP id JAA15140; Wed, 31 May 2000 09:57:33 +0200 (MET DST) Date: Wed, 31 May 2000 09:58:23 +0200 (CEST) From: "Jens-S. Voeckler" To: Hyoung-Kee Choi cc: tcp-impl@grc.nasa.gov Subject: Re: Snoop maxcount In-Reply-To: <393413D2.F332EA5C@cc.gatech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by rvs.uni-hannover.de id JAA15140 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id DAA19616 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, 30 May 2000, Hyoung-Kee Choi wrote: ]I am having a problem with Snoop. Snoop abrubtly finished after ]recording 4 million packets although I did not specify the -c option in ]the command line. The trace file size is about 510MB after the Snoop ]run. I am restarting my snoop every night... ]In addition, has anyone sucessfully recorded packets in one file more ]than 2GB? Using the "largefiles" mount option might be the key here, see mount_ufs. Le deagh dhùrachd, Dipl.-Ing. Jens-S. Vöckler (voeckler@rvs.uni-hannover.de) Institute for Computer Networks and Distributed Systems University of Hanover, Germany; +49 511 762 4726