From owner-tcp-impl@lerc.nasa.gov Thu Mar 2 23:46:35 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 XAA06688 for ; Thu, 2 Mar 2000 23:46:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA21480 for tcp-impl-outgoing; Thu, 2 Mar 2000 20:44:51 -0500 (EST) 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 UAA21470 for ; Thu, 2 Mar 2000 20:44:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA06314; Thu, 2 Mar 2000 20:44:47 -0500 (EST) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006293; Thu, 2 Mar 00 20:44:14 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17043 for ; Thu, 2 Mar 2000 17:44:10 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id RAA24990; Thu, 2 Mar 2000 17:44:10 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with SMTP id e231i8L11845; Thu, 2 Mar 2000 17:44:08 -0800 (PST) Date: Thu, 2 Mar 2000 16:20:10 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TCP RDMA option to accelerate NFS, CIFS, SCSI, etc. To: "David R. Cheriton" Cc: Alan Cox , julian_satran@il.ibm.com, David Robinson , ips@ece.cmu.edu, tcp-impl@grc.nasa.gov In-Reply-To: "Your message with ID" <3.0.3.32.20000227175017.006baa14@ruby.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I think it would be only fair for this group to expect you to > provide a more fully worked out design and evaluation of your > proposed NIC if this is really to be taken as a serious alternative > to an RDMA option. I for one dont find it a competitive design > (it is also one that was previously considered.) David, I suspect that it is the proponents of the RDMA option in TCP that have to make the case that RDMA is useful and not the other way around. Erik From owner-tcp-impl@lerc.nasa.gov Mon Mar 6 08:09: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 IAA03825 for ; Mon, 6 Mar 2000 08:09:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA03259 for tcp-impl-outgoing; Mon, 6 Mar 2000 05:04:04 -0500 (EST) 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 EAA02541; Mon, 6 Mar 2000 04:44:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA08000; Mon, 6 Mar 2000 04:44:06 -0500 (EST) Received: from smtp2.cluster.oleane.net(195.25.12.17) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007977; Mon, 6 Mar 00 04:43:25 -0500 Received: from oleane (dyn-1-1-132.Vin.dialup.oleane.fr [195.25.4.132]) by smtp2.cluster.oleane.net with SMTP id KAA78930; Mon, 6 Mar 2000 10:42:56 +0100 (CET) Message-ID: <00f401bf874f$be56f800$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: SIP 2000 International Conference Date: Mon, 6 Mar 2000 10:38:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01BF8758.19B928A0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_00F1_01BF8758.19B928A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unknown and even rejected by many vendors and operators only a few = months ago, SIP is on the brink of making a definitive name for itself.=20 Visit the SIP 2000 International Conference programme: http://www.upperside.fr/basip.htm =20 ------=_NextPart_000_00F1_01BF8758.19B928A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unknown and even rejected by many vendors and operators only a few = months=20 ago, SIP is on the brink of making a definitive name for itself.
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.= htm
 
 
------=_NextPart_000_00F1_01BF8758.19B928A0-- From owner-tcp-impl@lerc.nasa.gov Fri Mar 17 20:18:04 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 UAA04379 for ; Fri, 17 Mar 2000 20:18:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA10639 for tcp-impl-outgoing; Fri, 17 Mar 2000 17:24:20 -0500 (EST) 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 RAA10622 for ; Fri, 17 Mar 2000 17:24:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA26422; Fri, 17 Mar 2000 17:24:18 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026384; Fri, 17 Mar 00 17:23:53 -0500 Received: (from touch@localhost) by boreas.isi.edu (8.8.7/8.8.6) id OAA08736 for tcp-impl@grc.nasa.gov; Fri, 17 Mar 2000 14:23:52 -0800 (PST) Date: Fri, 17 Mar 2000 14:23:52 -0800 (PST) From: Joe Touch Message-Id: <200003172223.OAA08736@boreas.isi.edu> To: tcp-impl@grc.nasa.gov Subject: Announcing X-Bone VPN/overlay software release Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x XX XX X-BONE Overlay System x x X X x x XX Software Release x x X X x x XX XX March 2000 x x x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx The X-Bone system for automated deployment of VPN / overlay networks is now publicly available. This is the first major public release, v1.2. X-Bone dynamically deploys and manages Internet overlays to reduce configuration effort and increase network component sharing. X-Bone discovers, configures, and monitors network resources to create overlays over existing IP networks. The X-Bone is implemented in Perl, and open source is provided. The X-Bone can be used for: - deploying VPNs - sharing lab or wide-area networks for multiple, concurrent projects for testing protocols and apps on new topologies X-Bone uses two-layer IP in IP tunneled overlays and supports existing applications and unmodified routing, multicast, and DNS services. X-Bone also support IPSec within overlays. Applications can use the X-Bone without modification or recompilation. The X-Bone is available for the following operating systems: - FreeBSD CAIRN 2.5, 3.*, 3.* + KAME IPsec patches - Linux RedHat 6.0, 6.0 + NIST Cerberus IPsec patches, 6.1 The FreeBSD port and Linux RPM have been submitted to the FreeBSD ports and RedHat Linux RPMs sites; further information and details and the port and RPM files are currently available at: http://www.isi.edu/xbone/ - Joe Touch Project Leader, X-Bone group, USC/ISI touch@isi.edu http://www.isi.edu/touch +1 (310) 448-9151 ------------------------------------------------------------------- Effort sponsored by the Defense Advanced Research Projects Agency (DARPA)and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-98-1-0200. Copyright (c) 1998-2000 by the University of Southern California. All rights reserved. ------------------------------------------------------------------- From owner-tcp-impl@lerc.nasa.gov Fri Mar 17 21:12:02 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 VAA24633 for ; Fri, 17 Mar 2000 21:12:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA16433 for tcp-impl-outgoing; Fri, 17 Mar 2000 18:52:51 -0500 (EST) 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 SAA16421 for ; Fri, 17 Mar 2000 18:52:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA05167; Fri, 17 Mar 2000 18:52:49 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005157; Fri, 17 Mar 00 18:52:23 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id PAA23908 for ; Fri, 17 Mar 2000 15:52:21 -0800 (PST) Message-ID: <38D2C517.1536BECB@isi.edu> Date: Fri, 17 Mar 2000 15:51:51 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Announcing X-Bone VPN/overlay software release References: <200003172223.OAA08736@boreas.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 To clarify: We're hoping this tool will be useful for researchers in deploying testbeds and configuring TCP (and other) experiments. - Joe Joe Touch wrote: > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > x x > x XX XX X-BONE Overlay System x > x X X x > x XX Software Release x > x X X x > x XX XX March 2000 x > x x > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > From owner-tcp-impl@lerc.nasa.gov Fri Mar 17 22:39: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 WAA29330 for ; Fri, 17 Mar 2000 22:39:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA21291 for tcp-impl-outgoing; Fri, 17 Mar 2000 20:23:21 -0500 (EST) Received: from seraph2.lerc.nasa.gov (firewall-user@guardian02.lerc.nasa.gov [139.88.146.11]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA21262 for ; Fri, 17 Mar 2000 20:23:15 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id UAA04260; Fri, 17 Mar 2000 20:23:14 -0500 (EST) Received: from hilbert.umkc.edu(134.193.4.60) by seraph2.lerc.nasa.gov via smap (V5.0) id xma004179; Fri, 17 Mar 00 20:22:30 -0500 Received: (qmail 423744 invoked from network); 18 Mar 2000 01:19:41 -0000 Received: from lucy.ssb.umkc.edu (HELO kasey.umkc.edu) (david@134.193.69.99) by hilbert.umkc.edu with SMTP; 18 Mar 2000 01:19:41 -0000 Message-ID: <38D2D9E2.2201AC88@kasey.umkc.edu> Date: Sat, 18 Mar 2000 01:20:34 +0000 From: "David L. Nicol" Organization: University of Missouri - Kansas City network operations X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-mosix i586) X-Accept-Language: en MIME-Version: 1.0 To: "mosix@cs.huji.ac.il" , ietf-web@ietf.org, mallman@lerc.nasa.gov, floyd@ee.lbl.gov, craig@bbn.com, vern@aciri.org, tcp-impl@grc.nasa.gov, rfc-editor@rfc-editor.org Subject: I-D: a tcp extension to allow transfer of virtual circuits Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Experimental David Nicol University of Missouri - Kansas City March 2000 a tcp extension to allow transfer of virtual circuits Status of this memo this request for comments is being written after realizing that several independent problems could be solved by the method described herein, which works entirely at the transport layer. I would like to see this proposal considered for adoption as an IETF standard, if it is deemed acceptable. In particular, the physical format of the commands, beyond that it may make sense to encapsulate them in the data portion of invalid reset packets, is left to be determined by discussion. Summary the TCP virtual circuit as defined in Jon Postel's 1981 standard and subsequently clarified offers no facility for moving an end point of an established virtual circuit to a different peer. There are situations in which this would be desirable. This memo suggests a method of implementing such a mechanism in such a way that it will co-exist seamlessly with nonextended TCP, and will work over any link layer that supports the TCP transport layer abstraction. 1: INTRODUCTION Thinking about migratable sockets and load sharing, I realized that there is an entire class of unimplemented interface problems, such as how to move a running xterm from one display to another, and how to implement "user roaming" without channeling all network traffic through a central forwarding agent, which could all be solved without making massive changes to all existing socket based applications, by adding a new primitive to TCP allowing a peer to "transfer" its end of a virtual circuit to another machine. 2: IMPLEMENTATION OF THE TRANSFER IMPERATIVE EVENT This primitive would be a communication wedged into the cracks in current TCP implementation, either by claiming a "reserved control bit" or by sending information in the data space of a RST segment. Packing information into a RST packet looks more doable at this time, since the RST segment has some spare data area in it, and the implementation guidleines in the standard include a variety of situations in which RST segments are to be dropped. The primitives would include "prepare-to-accept transfer from host:socket" to which the response would be a host identifier:socket number which the connection could be transferred to; and "transfer to host:socket" which would cause the requested peer to send further packets in the stream being transferred to the new host. Or the transfer could take place in a single step, by sending extended RST packets to both peers which are to synchronize and carry on the virtual circuit. 3: ONE EXAMPLE OF LIFE MADE EASIER BY USE OF THIS EXTENSION As an example of this extension in use, imagine a situation in which you have an x-application running on host A, displayed on display server B, and you wish to move the display to display server C. A:3841 <-----> B:6000 ESTABLISHED C To transfer the window, B would open a connection to the X-server on C and display a placeholding window there, with similar characteristics as the window A is displaying on B. A:3861 <------> B:6000 ESTABLISHED C:6000 <------> B:3094 ESTABLISHED To this point, all has been accomplished with current TCP. Using current standards, an extended X-server may relay the packets from A to C via B, however there is no way to phase B's role out. The extension I am proposing in this message would allow B to send a message to A and C, so that A and C continue a data stream with each other, without B being involved any more. B would accomplish this by sending A a transfer initation message on the A:3861-B:6000 channel, stating "prepare to transfer this channel to C:6000, passively." This message could take the form of an invalid RST segment including a data block with enough information to carry the message. A replies with the number of a socket on A which would be able to accept this new connection with C. Usually this will be the current socket number, but there may be cases when a new number will need to be selected. In these rare cases, A reestablishes the connection being reset for transfer and initiates a transfer of the A-B circuit to a new port number on A which will not collide with an existing A-C virtual circuit. This has the effect of A initiating a connection open, or opening a socket with the same number as the one connected to B, for listening. A:3861 <------> B:6000 TRANSFERING C:6000 <------> B:3094 ESTABLISHED A:3861 LISTEN A can then send B another extended RST packet, indicating that it is ready to transfer the connection to C. A noncompliant TCP will of course ignore an invalid reset segment. This preliminary step having succeeded, B now sends C a message on the C:6000 <------> B:3094 channel, stating "transfer this connection to A:3861, actively" A and C now establish the new connection, using a slow start. A:3861 <------> B:6000 C:6000 <------> B:3094 A:3861 <------> C:6000 and close their connections with B. A:3861 <------> C:6000 4: NO EFFECT ON HIGHER LAYERS There will be no indication that this has occurred, above the transport layer: it will be indistinguishable from a normal traffic hiccup. On receipt of ACK of FIN packets, B's system call, if it had been blocking for completion of the transfer function, can return with a success code. 5: FAST TRANSFERRING WITH KNOWN-COMPLIANT TCP If it is known in advance that both peers' TCPs support transferring, the extended RSTs could be sent to both, immediately, and then again, in case of a port number collission. 6. SECURITY IMPLICATIONS To prevent connection transfer being used as a way to tunnel through common firewall implementations, the resulting connection must be nominally established as if it were new. 7. STATUS DISINFORMATION For backwards compatability with applications that may rely on functions such as getpeername and sin_port member data, the transfer messages may include an option flag "OPT_REMEMBER" which will cause the TCP software to remember what the original host:socket was, instead of the current peer, after a transfer, for purposes of responding to status requests. 8. USE CASE: ROAMING To use this extension to aid roaming, transfers would be arranged by the "home server" after connections are established, instead of the home server continuing to forward all traffic. 9. USE CASE: PROCESS MIGRATION LOAD BALANCING In process migration based load balancing, tcp connections (with compliant peers) could be transferred at migration time and handled by the TCP on the host machine. terminology: In the above example, the "B" host is the "transfer initiating peer." A and C are "transfer end peers." On backwards compatability: I believe that the RST loading method would be the best way to implement these extensions. The TCP wishing to initiate the transfer could send RST packets to both peers, containing the full description of the current connection and the connection to be established, actively. A TCP compliant with this standard will attempt a simultaneous open with the new peer instead of the old one, and send an acknowledgement. An old TCP will merely reset the current connection as if there had been a problem, and the transfer initiating peer can return from the transferring function with an error code. FUNCTIONAL SPECIFICATION: The privelege to perform the transfer operation will need to be carefully delegated by the implementing operating system. Since circuit transfer operations may be initiated by a process outside the scope of the local connection name, both fully specified pairs will need to appear in the invocation of a circuit transfer initation call, such as Join Format: JOIN ( first local address, first local port, first foreign address, first foreign port, second local address, second local port, second foreign address, second foreign port ) This call would cause the two fully specified connections to be validated for existence and establishment, and then combined as described in the example. Transfer Format: TRANSFER ( local address, local port, foreign address, foreign port, second foreign address, second foreign port ) This call would be in effect similar to a http Location: directive; causing an extended RST to be sent, which would indicate that the connection would be better carried out with the TCP at the second link and port, which doesn't know you're coming, but which may be better prepared to provide the desired service. Widely adopted implementation of this extension could greatly ease design of graceful load balancing, as after a server is operating at capacity instead of merely saying "Sorry, full up!" it could explicitly and instantly (no waiting for backup MX records to propagate through the DNS) refer the connection to another server. references: rfcs 793, 2414, 1379, 2525, 721, 875 Author: David Nicol davidnicol@davidnicol.com post office box 45163 kansas city Missouri 64171 From owner-tcp-impl@lerc.nasa.gov Mon Mar 20 23:09:36 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 XAA09606 for ; Mon, 20 Mar 2000 23:09:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA19213 for tcp-impl-outgoing; Mon, 20 Mar 2000 20:39:07 -0500 (EST) 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 UAA19204 for ; Mon, 20 Mar 2000 20:39:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA23269; Mon, 20 Mar 2000 20:39:05 -0500 (EST) Received: from nassau.proxinet.com(166.90.59.24) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023241; Mon, 20 Mar 00 20:38:33 -0500 Received: from pumatech.com (IDENT:wuchang@localhost [127.0.0.1]) by nassau.proxinet.com (8.9.3/8.9.3) with ESMTP id RAA32520 for ; Mon, 20 Mar 2000 17:43:10 -0800 Message-ID: <38D6D3AE.5B079D60@pumatech.com> Date: Mon, 20 Mar 2000 17:43:10 -0800 From: Wu-chang Feng Reply-To: wfeng@pumatech.com X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementors Subject: Pathologic Solaris TCP behavior Content-Type: multipart/mixed; boundary="------------2C9147D1CB27CF1AE77149AF" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------2C9147D1CB27CF1AE77149AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Has anyone experienced problems with Solaris TCP where you basically get modem-speed performance over a full duplex ethernet link? I have two, factory-installed Netra T1 boxes running Solaris 7. They're connected through an ethernet switch, but when I do an ftp between them, I get a trickle because of packets which are lost after every 6-7 packets. On the incoming interface of the destination machine (which is completely unloaded) I get a large number of Ierrs..... --------------------------------------------------------------------------- pumaweb006 ~ % netstat -i Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 loopback localhost 1527068 0 1527068 0 0 0 hme0 1500 p006-be p006-be 34108 0 9366 0 0 0 hme1 1500 p006 p006 3039955 17817 1164113 0 0 0 --------------------------------------------------------------------------- Attached is a tcpdump of the ftp connection..... --------------2C9147D1CB27CF1AE77149AF Content-Type: text/plain; charset=us-ascii; name="tmpfile" Content-Disposition: inline; filename="tmpfile" Content-Transfer-Encoding: 7bit 17:22:32.419072 216.10.101.75.ftp-data > p006.56818: . 131072:132532(1460) ack 1 win 24820 (DF) 17:22:32.419108 p006.56818 > 216.10.101.75.ftp-data: . ack 133992 win 24820 (DF) 17:22:32.419538 216.10.101.75.ftp-data > p006.56818: . 133992:135452(1460) ack 1 win 24820 (DF) 17:22:32.419599 216.10.101.75.ftp-data > p006.56818: P 135452:136344(892) ack 1 win 24820 (DF) 17:22:32.419640 p006.56818 > 216.10.101.75.ftp-data: . ack 135452 win 24820 (DF) 17:22:32.420016 216.10.101.75.ftp-data > p006.56818: . 136344:137804(1460) ack 1 win 24820 (DF) 17:22:32.420136 216.10.101.75.ftp-data > p006.56818: . 137804:139264(1460) ack 1 win 24820 (DF) 17:22:32.420205 p006.56818 > 216.10.101.75.ftp-data: . ack 139264 win 24820 (DF) 17:22:32.420596 216.10.101.75.ftp-data > p006.56818: . 139264:140724(1460) ack 1 win 24820 (DF) 17:22:32.420709 216.10.101.75.ftp-data > p006.56818: . 140724:142184(1460) ack 1 win 24820 (DF) 17:22:32.420777 p006.56818 > 216.10.101.75.ftp-data: . ack 142184 win 24820 (DF) 17:22:35.419098 216.10.101.75.ftp-data > p006.56818: . 139264:140724(1460) ack 1 win 24820 (DF) 17:22:35.419125 p006.56818 > 216.10.101.75.ftp-data: . ack 142184 win 24820 (DF) 17:22:35.419531 216.10.101.75.ftp-data > p006.56818: . 142184:143644(1460) ack 1 win 24820 (DF) 17:22:35.419594 216.10.101.75.ftp-data > p006.56818: P 143644:144536(892) ack 1 win 24820 (DF) 17:22:35.419650 p006.56818 > 216.10.101.75.ftp-data: . ack 143644 win 24820 (DF) 17:22:35.420027 216.10.101.75.ftp-data > p006.56818: . 144536:145996(1460) ack 1 win 24820 (DF) 17:22:35.420144 216.10.101.75.ftp-data > p006.56818: . 145996:147456(1460) ack 1 win 24820 (DF) 17:22:35.420217 p006.56818 > 216.10.101.75.ftp-data: . ack 147456 win 24820 (DF) 17:22:35.420626 216.10.101.75.ftp-data > p006.56818: . 147456:148916(1460) ack 1 win 24820 (DF) 17:22:35.420742 216.10.101.75.ftp-data > p006.56818: . 148916:150376(1460) ack 1 win 24820 (DF) 17:22:35.420815 p006.56818 > 216.10.101.75.ftp-data: . ack 150376 win 24820 (DF) 17:22:38.419135 216.10.101.75.ftp-data > p006.56818: . 147456:148916(1460) ack 1 win 24820 (DF) 17:22:38.419160 p006.56818 > 216.10.101.75.ftp-data: . ack 150376 win 24820 (DF) 17:22:38.419577 216.10.101.75.ftp-data > p006.56818: . 150376:151836(1460) ack 1 win 24820 (DF) 17:22:38.419640 216.10.101.75.ftp-data > p006.56818: P 151836:152728(892) ack 1 win 24820 (DF) 17:22:38.419688 p006.56818 > 216.10.101.75.ftp-data: . ack 151836 win 24820 (DF) 17:22:38.420066 216.10.101.75.ftp-data > p006.56818: . 152728:154188(1460) ack 1 win 24820 (DF) 17:22:38.420183 216.10.101.75.ftp-data > p006.56818: . 154188:155648(1460) ack 1 win 24820 (DF) 17:22:38.420257 p006.56818 > 216.10.101.75.ftp-data: . ack 155648 win 24820 (DF) 17:22:38.420644 216.10.101.75.ftp-data > p006.56818: . 155648:157108(1460) ack 1 win 24820 (DF) 17:22:38.420763 216.10.101.75.ftp-data > p006.56818: . 157108:158568(1460) ack 1 win 24820 (DF) 17:22:38.420839 p006.56818 > 216.10.101.75.ftp-data: . ack 158568 win 24820 (DF) 17:22:41.419183 216.10.101.75.ftp-data > p006.56818: . 155648:157108(1460) ack 1 win 24820 (DF) 17:22:41.419205 p006.56818 > 216.10.101.75.ftp-data: . ack 158568 win 24820 (DF) 17:22:41.419603 216.10.101.75.ftp-data > p006.56818: . 158568:160028(1460) ack 1 win 24820 (DF) 17:22:41.419670 216.10.101.75.ftp-data > p006.56818: P 160028:160920(892) ack 1 win 24820 (DF) 17:22:41.419709 p006.56818 > 216.10.101.75.ftp-data: . ack 160028 win 24820 (DF) 17:22:41.420082 216.10.101.75.ftp-data > p006.56818: . 160920:162380(1460) ack 1 win 24820 (DF) 17:22:41.420201 216.10.101.75.ftp-data > p006.56818: . 162380:163840(1460) ack 1 win 24820 (DF) 17:22:41.420268 p006.56818 > 216.10.101.75.ftp-data: . ack 163840 win 24820 (DF) 17:22:41.420650 216.10.101.75.ftp-data > p006.56818: . 163840:165300(1460) ack 1 win 24820 (DF) 17:22:41.420769 216.10.101.75.ftp-data > p006.56818: . 165300:166760(1460) ack 1 win 24820 (DF) 17:22:41.420840 p006.56818 > 216.10.101.75.ftp-data: . ack 166760 win 24820 (DF) --------------2C9147D1CB27CF1AE77149AF-- From owner-tcp-impl@lerc.nasa.gov Tue Mar 21 00:45: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 AAA17046 for ; Tue, 21 Mar 2000 00:45:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA25183 for tcp-impl-outgoing; Mon, 20 Mar 2000 22:38:23 -0500 (EST) 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 WAA25168 for ; Mon, 20 Mar 2000 22:38:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA06667; Mon, 20 Mar 2000 22:38:20 -0500 (EST) Received: from pneumatic-tube.sgi.com(204.94.214.22) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006652; Mon, 20 Mar 00 22:38:05 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA08843; Mon, 20 Mar 2000 19:41:34 -0800 (PST) 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 TAA77381; Mon, 20 Mar 2000 19:38:01 -0800 (PST) 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 TAA37265; Mon, 20 Mar 2000 19:45:17 -0800 (PST) Message-Id: <200003210345.TAA37265@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: wfeng@pumatech.com Cc: tcp-impl@grc.nasa.gov Subject: Re: Pathologic Solaris TCP behavior From: Zachary Amsden In-Reply-To: Your message of "Mon, 20 Mar 2000 17:43:10 PST." <38D6D3AE.5B079D60@pumatech.com> Date: Mon, 20 Mar 2000 19:45:16 -0800 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > Has anyone experienced problems with Solaris TCP where you basically > get modem-speed performance over a full duplex ethernet link? I have > two, factory-installed Netra T1 boxes running Solaris 7. They're > connected through an ethernet switch, but when I do an ftp between > them, I get a trickle because of packets which are lost after every > 6-7 packets. On the incoming interface of the destination machine > (which is completely unloaded) I get a large number of Ierrs..... The TCP trace you included is completely consistent with ACK loss producing unnecessary retransmissions, as far as I can tell. This is a strong indicator that there is a link layer problem, perhaps bad cabling or a cheap switch. I highly doubt that Sun would let such a glaring problem in their stack go unnoticed. -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols From owner-tcp-impl@lerc.nasa.gov Tue Mar 21 02:48: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 CAA12478 for ; Tue, 21 Mar 2000 02:48:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA00018 for tcp-impl-outgoing; Tue, 21 Mar 2000 00:27:53 -0500 (EST) 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 AAA29999 for ; Tue, 21 Mar 2000 00:27:51 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id AAA18911; Tue, 21 Mar 2000 00:27:50 -0500 (EST) Received: from drawbridge.ascend.com(198.4.92.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018891; Tue, 21 Mar 00 00:27:20 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id VAA10245; Mon, 20 Mar 2000 21:20:47 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 21 Mar 2000 05:27:19 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id VAA01936; Mon, 20 Mar 2000 21:27:17 -0800 (PST) Received: from scamp.eng.ascend.com (scamp.eng.ascend.com [172.20.8.27]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id VAA23949; Mon, 20 Mar 2000 21:27:18 -0800 (PST) Received: from igoyret-pc.eng.ascend.com by scamp.eng.ascend.com (8.8.8+Sun/SMI-SVR4) id VAA28689; Mon, 20 Mar 2000 21:27:17 -0800 (PST) Message-Id: <3.0.5.32.20000320212829.00b08e30@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 20 Mar 2000 21:28:29 -0800 To: Zachary Amsden From: Ignacio Goyret Subject: Re: Pathologic Solaris TCP behavior Cc: wfeng@pumatech.com, tcp-impl@grc.nasa.gov In-Reply-To: <200003210345.TAA37265@clock.engr.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk At 07:45 PM 3/20/00 -0800, Zachary Amsden wrote: > >> Has anyone experienced problems with Solaris TCP where you basically >> get modem-speed performance over a full duplex ethernet link? I have >> two, factory-installed Netra T1 boxes running Solaris 7. They're >> connected through an ethernet switch, but when I do an ftp between >> them, I get a trickle because of packets which are lost after every >> 6-7 packets. On the incoming interface of the destination machine >> (which is completely unloaded) I get a large number of Ierrs..... > >The TCP trace you included is completely consistent with ACK loss producing >unnecessary retransmissions, as far as I can tell. This is a strong indicator >that there is a link layer problem, perhaps bad cabling or a cheap switch. I >highly doubt that Sun would let such a glaring problem in their stack go >unnoticed. I agree with Zachary: there must be a link layer problem. My guess is that one of the links (sun1<->switch or switch<->sun2) is not set as you expect. I've seen these kinds of errors when one end of the link thinks is set for half-duplex but the other end thinks it should be full-duplex. The full-duplex side will ignore collisions but the other end will get mighty upset. From owner-tcp-impl@lerc.nasa.gov Tue Mar 21 04:08:42 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 EAA11418 for ; Tue, 21 Mar 2000 04:08:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA03918 for tcp-impl-outgoing; Tue, 21 Mar 2000 01:43:40 -0500 (EST) 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 BAA03912 for ; Tue, 21 Mar 2000 01:43:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA26033; Tue, 21 Mar 2000 01:43:37 -0500 (EST) Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025968; Tue, 21 Mar 00 01:42:38 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA26221; Tue, 21 Mar 2000 01:42:22 -0500 (EST) Date: Tue, 21 Mar 2000 01:42:22 -0500 (EST) From: der Mouse Message-Id: <200003210642.BAA26221@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: Wu-chang Feng Cc: tcp-impl@grc.nasa.gov Subject: Re: Pathologic Solaris TCP behavior Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Has anyone experienced problems with Solaris TCP where you basically > get modem-speed performance over a full duplex ethernet link? This sounds to me a lot more like broken full-duplex than like a broken TCP stack. I had very similar performance problems with a NetBSD/alpha machine on 100baseTX until I disabled autonegotiation, hardwiring both ends to 100/full. In another case I know of, the problem was that the OS (a Linux variant, in this case) claimed the card was in full-duplex but it was not in fact so. Do you have the switch set to autonegotiate? The Netras? Try hand-configuring full-duplex. If that fails try hand-configuring half-duplex. Also try hand-configuring the speed, if the cards are 100-capable; if your wiring is not up to scratch it may work at 10 but produce piles of errors at 100. > On the incoming interface of the destination machine (which is > completely unloaded) I get a large number of Ierrs..... This is a very strong indication that the problem is high packet loss caused by broken hardware behavior, not a TCP stack problem at all. The stack is probably doing as well as it can given the high loss rates it's faced with. My first guess is a duplex mismatch; my second is attempting 100baseTX over wiring that's not up to spec for 100Mbit. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Tue Mar 21 15:41:21 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 PAA21733 for ; Tue, 21 Mar 2000 15:41:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA11115 for tcp-impl-outgoing; Tue, 21 Mar 2000 12:52:46 -0500 (EST) 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 MAA11083 for ; Tue, 21 Mar 2000 12:52:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA07226; Tue, 21 Mar 2000 12:52:41 -0500 (EST) Received: from holmes.proxinet.com(166.90.59.6) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007210; Tue, 21 Mar 00 12:52:38 -0500 Received: from pumatech.com (adsl-63-195-81-47.dsl.snfc21.pacbell.net [63.195.81.47]) by holmes.proxinet.com (8.8.7/8.8.7) with ESMTP id JAA19626 for ; Tue, 21 Mar 2000 09:57:21 -0800 Message-ID: <38D7B729.E3513F27@pumatech.com> Date: Tue, 21 Mar 2000 09:53:46 -0800 From: Wu-chang Feng Reply-To: wfeng@pumatech.com X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementors Subject: Re: Pathologic Solaris TCP behavior References: <38D6D3AE.5B079D60@pumatech.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 Thanks everyone for all of the responses. They were right on target. Turning off auto negotiation on the switch worked like a charm! :) Wu From owner-tcp-impl@lerc.nasa.gov Thu Mar 23 05:00: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 FAA19722 for ; Thu, 23 Mar 2000 05:00:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA10185 for tcp-impl-outgoing; Thu, 23 Mar 2000 01:54:47 -0500 (EST) 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 BAA10170 for ; Thu, 23 Mar 2000 01:54:45 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA20301; Thu, 23 Mar 2000 01:54:45 -0500 (EST) Received: from unknown(203.197.140.35) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020199; Thu, 23 Mar 00 01:54:30 -0500 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 23 Mar 2000 12:33:05 +0530 Received: from shankarv.future.futsoft.com ([10.0.14.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA02873 for ; Thu, 23 Mar 2000 12:14:17 +0530 Message-Id: <001e01bf9494$7277fcc0$0f0e000a@future.futsoft.com> From: "Shankar Vasudevan" To: "TCP-IMPL" Subject: TCP & Path MTU Discovery. Date: Thu, 23 Mar 2000 12:23:01 +0530 Organization: Future Software Pvt Ltd MIME-Version: 1.0 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 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01BF94C2.87D65480" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01BF94C2.87D65480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Can someone point out a TCP implementation that uses the PMTU-D as = defined in RFC 1191. Can any one tell me if there is any reference doc that discusses about the interface that TCP should have to learn changes in TCP ?=20 thanx in advance, shankar ------=_NextPart_000_001B_01BF94C2.87D65480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Can someone point out a TCP = implementation that=20 uses the PMTU-D as defined in RFC 1191.
 
Can any one tell me if there is any = reference doc=20 that discusses about
the interface that TCP should have to = learn changes=20 in TCP ?
 
 
thanx in advance,
shankar
------=_NextPart_000_001B_01BF94C2.87D65480-- From owner-tcp-impl@lerc.nasa.gov Thu Mar 23 06:36:30 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 GAA22192 for ; Thu, 23 Mar 2000 06:36:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA16536 for tcp-impl-outgoing; Thu, 23 Mar 2000 03:48:04 -0500 (EST) 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 DAA16530 for ; Thu, 23 Mar 2000 03:48:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA01517; Thu, 23 Mar 2000 03:48:02 -0500 (EST) Received: from twig.rodents.montreal.qc.ca(216.46.5.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001405; Thu, 23 Mar 00 03:47:28 -0500 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA04860; Thu, 23 Mar 2000 03:46:04 -0500 (EST) Date: Thu, 23 Mar 2000 03:46:04 -0500 (EST) From: der Mouse Message-Id: <200003230846.DAA04860@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: "Shankar Vasudevan" Cc: tcp-impl@grc.nasa.gov Subject: Re: TCP & Path MTU Discovery. Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Can someone point out a TCP implementation that uses the PMTU-D as > defined in RFC 1191. NetBSD, at least in recent versions, is supposed to do this if you turn on the proper sysctl (net.inet.ip.mtudisc). Presumably the other BSD variants are comparable, though I haven't verified it myself. I also haven't checked how precisely compatible with 1191 the implementation actually is. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Thu Mar 23 15:43:44 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 PAA13358 for ; Thu, 23 Mar 2000 15:43:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA19139 for tcp-impl-outgoing; Thu, 23 Mar 2000 13:22:43 -0500 (EST) 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 NAA19124 for ; Thu, 23 Mar 2000 13:22:41 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA04128; Thu, 23 Mar 2000 13:22:40 -0500 (EST) Received: from vanguard.logictier.com(209.246.46.130) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003846; Thu, 23 Mar 00 13:22:20 -0500 Received: from logictier.com (adsl-63-195-68-50.dsl.snfc21.pacbell.net [63.195.68.50]) by vanguard.logictier.com (8.9.1/8.9.1) with ESMTP id NAA10222 for ; Thu, 23 Mar 2000 13:21:38 -0500 (EST) Message-Id: <200003231821.NAA10222@logictier.com> To: tcp-impl@grc.nasa.gov Subject: Re: TCP & Path MTU Discovery. In-reply-to: Your message of "Thu, 23 Mar 2000 03:46:04 EST." <200003230846.DAA04860@Twig.Rodents.Montreal.QC.CA> From: "Kevin Lahey" Date: Thu, 23 Mar 2000 10:22:29 -0800 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk In message <200003230846.DAA04860@Twig.Rodents.Montreal.QC.CA>der Mouse writes >> Can someone point out a TCP implementation that uses the PMTU-D as >> defined in RFC 1191. > >NetBSD, at least in recent versions, is supposed to do this if you turn >on the proper sysctl (net.inet.ip.mtudisc). Presumably the other BSD >variants are comparable, though I haven't verified it myself. > >I also haven't checked how precisely compatible with 1191 the >implementation actually is. I wrote the NetBSD PMTUD implementation, so I'm bound to think that it is pretty comformant. :-) At the same time as I was writing it, a NASA intern and I checked out a number of other implementations to verify how conformant they were. I remember checking FreeBSD, Linux, IRIX, Solaris, HP-UX, Windows (NT and possibly 98), and UNICOS. All of 'em were fairly close, with a few minor nits for some of 'em, mostly outlined in a I-D I wrote that seems to have expired without me making a last set of revisions... :-( Cheers, Kevin Lahey kml@logictier.com From owner-tcp-impl@lerc.nasa.gov Thu Mar 23 16:40: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 QAA01099 for ; Thu, 23 Mar 2000 16:40:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24651 for tcp-impl-outgoing; Thu, 23 Mar 2000 13:59:34 -0500 (EST) 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 NAA24617 for ; Thu, 23 Mar 2000 13:59:31 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA04361; Thu, 23 Mar 2000 13:59:29 -0500 (EST) Received: from laurin.munich.netsurf.de(194.64.166.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004212; Thu, 23 Mar 00 13:59:24 -0500 Received: from fred.muc.de (ns1206.munich.netsurf.de [195.180.235.206]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id TAA16212; Thu, 23 Mar 2000 19:59:05 +0100 (MET) Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 12YCXY-0000Dw-00; Thu, 23 Mar 2000 19:41:04 +0100 Date: Thu, 23 Mar 2000 19:41:03 +0100 From: Andi Kleen To: Shankar Vasudevan Cc: TCP-IMPL Subject: Re: TCP & Path MTU Discovery. Message-ID: <20000323194103.A854@fred.muc.de> References: <001e01bf9494$7277fcc0$0f0e000a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <001e01bf9494$7277fcc0$0f0e000a@future.futsoft.com>; from Shankar Vasudevan on Thu, Mar 23, 2000 at 11:07:15AM +0100 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Thu, Mar 23, 2000 at 11:07:15AM +0100, Shankar Vasudevan wrote: > Hi, > > Can someone point out a TCP implementation that uses the PMTU-D as defined in RFC 1191. Linux 2.0+ implements path mtu discovery. 2.0 was a rather low tech implementation (no shared pmtus between sockets), but in 2.2+ it is fairly complete. Only thing missing is path mtu black hole detection (it seems very few TCPs implement that) -Andi -- This is like TV. I don't like TV. From owner-tcp-impl@lerc.nasa.gov Fri Mar 24 04:37:49 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 EAA24716 for ; Fri, 24 Mar 2000 04:37:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA21162 for tcp-impl-outgoing; Fri, 24 Mar 2000 02:00:56 -0500 (EST) Received: from seraph2.lerc.nasa.gov (firewall-user@guardian02.lerc.nasa.gov [139.88.146.11]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA21158 for ; Fri, 24 Mar 2000 02:00:55 -0500 (EST) Received: by seraph2.lerc.nasa.gov; id CAA15094; Fri, 24 Mar 2000 02:00:55 -0500 (EST) Received: from unknown(203.197.140.35) by seraph2.lerc.nasa.gov via smap (V5.0) id xma014580; Fri, 24 Mar 00 02:00:34 -0500 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 24 Mar 2000 12:08:27 +0530 Received: from shankarv.future.futsoft.com ([10.0.14.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA21785; Fri, 24 Mar 2000 11:49:00 +0530 Message-Id: <005001bf955a$19773020$0f0e000a@future.futsoft.com> From: "Shankar Vasudevan" To: "David Bein" , "der Mouse" , "Kevin Lahey" , "Andi Kleen" Cc: "TCP-IMPL" References: <001e01bf9494$7277fcc0$0f0e000a@future.futsoft.com> <38DA16D2.933E3F18@world.std.com> Subject: Re: TCP & Path MTU Discovery. Date: Fri, 24 Mar 2000 11:57:58 +0530 Organization: Future Software Pvt Ltd MIME-Version: 1.0 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 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01BF9588.32E4A780" Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004D_01BF9588.32E4A780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Thanx a lot for ur suggestions. Am now having lots of codes to look = into :) It gave me a lot of inputs, especially David with his detailed = mail gave lot of inputs.=20 The following is off the topic of this mailing list. so pl. excuse me. Am implementing PMTU-D for a router. Can we detect that a PMTU-D is = not converging ? RFC says we should force it to converge ? First of all = how do I detect that a discovery is not converging ?=20 And also where do I store my PMTU information? If i store it in the = routing table wouldn't that be wasting a lot of memory, since this is a = router and it would have routes to all possible destination ? If i put = it in a separate table then I wouldn't be able to give a per-route = configuration whether we should do PMTU-D or not. Thanx a lot , regards Shankar ------=_NextPart_000_004D_01BF9588.32E4A780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

Thanx a lot for ur suggestions. Am now = having lots=20 of codes to look into :) It gave me = a lot of=20 inputs, especially  David with = his=20 detailed mail gave lot of = inputs.=20

The following is off the topic of this = mailing=20 list. so pl. excuse me.

Am implementing PMTU-D for a router. = Can we detect=20 that a PMTU-D is not converging ? RFC says we should force it to = converge ?=20 First of all how do I detect that a discovery is not converging ? =

And also where do I store my PMTU = information? If i=20 store it in the routing table wouldn't that be wasting a lot of = memory, since=20 this is a router and it would have routes to all possible destination = ? =20 If i put it in a separate table then I wouldn't be able to give a = per-route=20 configuration whether we should do PMTU-D or not.

Thanx a lot ,

regards

Shankar

 

------=_NextPart_000_004D_01BF9588.32E4A780-- From owner-tcp-impl@lerc.nasa.gov Wed Mar 29 22:48:52 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 WAA29829 for ; Wed, 29 Mar 2000 22:48:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA10210 for tcp-impl-outgoing; Wed, 29 Mar 2000 20:11:56 -0500 (EST) 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 UAA10204; Wed, 29 Mar 2000 20:11:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA24566; Wed, 29 Mar 2000 20:11:53 -0500 (EST) Received: from bbcr.uwaterloo.ca(129.97.34.2) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024559; Wed, 29 Mar 00 20:11:36 -0500 Received: from bbcr.uwaterloo.ca (boutaba.uwaterloo.ca [129.97.34.80]) by bbcr.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id OAA25896; Wed, 29 Mar 2000 14:52:33 -0500 (EST) Message-ID: <38E25E42.E4A502C9@bbcr.uwaterloo.ca> Date: Wed, 29 Mar 2000 14:49:23 -0500 From: Raouf Boutaba Organization: University of waterloo X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: NETWORKIN 2000 Call For Participation Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by bbcr.uwaterloo.ca id OAA25896 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id UAB10205 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit [My apologies if you receive this more than once] ****************************************************** !! Early registration DEADLINE: April 15 !! /////////////////////////////////////// Call for participation Networking 2000 May 14-19, 2000 Paris, France ////////////////////////////////////// The year 2000 deserves the organization of exceptional events. Networking'2000 intends to be one of them. With three international conferences in parallel tracks, three outstanding invited speakers, twelves tutorials and nine mini-conferences, Networking'2000 will be THE first networking week of the millenium. You must be there. More information available at: http://netconf.lip6.fr/net2000 http://www.prism.uvsq.fr/~net2000 Networking 2000 conference is a joint conference of: HPN (High Performance Networking) Aaren 1987, Liège 1988, Berlin 1990, Liège 1992, Grenoble 1994, Palma 1995, New York 1997, Vienna 1998, Paris 2000. BC (Broadband Communications) Paris 1995, Montreal 1996, Lisboa 1997, Stuttgart 1998, Hong-Kong 1999, Paris 2000. PCN (Performance of Communication Networks) Paris 1981, Zürich 1984, Rio de Janeiro 1987, Barcelona 1990, Raleigh 1993, Lund 1998, Paris 2000.