Received: from cnri by ietf.org id aa27756; 8 Oct 96 6:22 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa06081; 8 Oct 96 6:22 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id EAA17745 for tcplw-list@bsdi.com; Tue, 8 Oct 1996 04:17:11 -0600 (MDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id EAA17742 for ; Tue, 8 Oct 1996 04:17:08 -0600 (MDT) Received: from rsm.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr) by melimelo.enst-bretagne.fr (5.67b8/090294); Tue, 8 Oct 1996 12:16:34 +0200 Received: from albemuth by rsm.enst-bretagne.fr (4.1/SMI-4.1) id AA25590; Tue, 8 Oct 96 11:16:33 +0100 Sender: Hossam.Afifi@enst-bretagne.fr Message-Id: <325A2A01.4632@rennes.enst-bretagne.fr> Date: Tue, 08 Oct 1996 12:16:33 +0200 From: Hossam Afifi Organization: RSM- ENST Bretagne X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: tcplw@bsdi.com Subject: RFC 1323 for ADSL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit RFC 1323 TIME STAMP option can improve TCP (vegas,tri-s and dual) performance in assymetric links in general. The idea is to replace rtt by a forward tt (ftt) and a backward tt (btt). Time differences are used to remove any time shift between peers. A new algorithm is proposed and simulations have been made in http://www.rennes.enst-bretagne.fr/~afifi/docs/atm.html page comments are welcome Hossam Afifi RSM-ENST de Bretagne France   Received: from cnri by ietf.org id aa02934; 14 Oct 96 13:35 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa15278; 14 Oct 96 13:35 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id LAA23962 for tcplw-list@bsdi.com; Mon, 14 Oct 1996 11:31:14 -0600 (MDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id LAA23958 for ; Mon, 14 Oct 1996 11:31:13 -0600 (MDT) Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 14 Oct 1996 10:24:03 -0700 Date: Mon, 14 Oct 96 10:24:53 PDT From: braden@isi.edu Posted-Date: Mon, 14 Oct 96 10:24:53 PDT Message-Id: <9610141724.AA21804@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-6) id ; Mon, 14 Oct 96 10:24:53 PDT To: tcplw@bsdi.com Subject: Question: FRC1323 implementations Cc: heyer@rrze.uni-erlangen.de ----- Begin Included Message ----- >From heyer@rrze.uni-erlangen.de Mon Oct 14 05:28:11 1996 Date: Mon, 14 Oct 1996 14:28:41 +0200 (MET DST) From: Martin Heyer X-Sender: unrz39@asterix Reply-To: Martin Heyer To: van@csam.lbl.gov, braden@isi.edu, dab@cray.com Subject: RFC1323 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 585 X-Lines: 19 Hello, since I don't know who else to ask: can you tell me if there are any implementations of the 'High Performance TCP Options' described in RFC1323 for SunOS or Solaris. This would be of great help for forthcoming tests of a satellite link at our site. Thank you very much in advance, Martin Heyer ---- Martin Heyer Phone: ++49 +9131 858738 Univ. of Erlangen-Nuernberg Fax: ++49 +9131 302941 Regional Computing Center Martensstr. 1 Email: heyer@rrze.uni-erlangen.de 91058 Erlangen - Germany X.400: c=de;a=d400;p=uni-erlangen;ou=rrze;s=heyer ----- End Included Message -----   Received: from cnri by ietf.org id aa03533; 14 Oct 96 14:20 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa16638; 14 Oct 96 14:20 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id MAA27897 for tcplw-list@bsdi.com; Mon, 14 Oct 1996 12:18:43 -0600 (MDT) Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by external.BSDI.COM (8.7.6/8.7.3) with ESMTP id MAA27894 for ; Mon, 14 Oct 1996 12:18:41 -0600 (MDT) Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.7.4/8.7.3) with SMTP id LAA25875; Mon, 14 Oct 1996 11:18:00 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id LAA00668; Mon, 14 Oct 1996 11:17:59 -0700 Message-Id: <199610141817.LAA00668@kohala.kohala.com> From: "W. Richard Stevens" Date: Mon, 14 Oct 1996 11:17:59 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: tcplw@bsdi.com Subject: Re: Question: FRC1323 implementations Cc: heyer@rrze.uni-erlangen.de Sun made the following posting to Usenet last January: > There is a prototype implementation > of the TCP large window extensions for Solaris 2 currently being tested. It is > available at ftp://playground.sun.com/pub/tcp-lfn. Rich Stevens   Received: from cnri by ietf.org id aa04101; 14 Oct 96 14:59 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa18082; 14 Oct 96 14:59 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id MAA00464 for tcplw-list@bsdi.com; Mon, 14 Oct 1996 12:56:44 -0600 (MDT) Received: from sabre.psc.edu (sabre.psc.edu [128.182.61.159]) by external.BSDI.COM (8.7.6/8.7.3) with ESMTP id MAA00461 for ; Mon, 14 Oct 1996 12:56:41 -0600 (MDT) Received: (from mahdavi@localhost) by sabre.psc.edu (8.7.4/8.7.4 PSC 1996/04/22 lambert) id OAA08704; Mon, 14 Oct 1996 14:55:38 -0400 (EDT) Date: Mon, 14 Oct 1996 14:55:38 -0400 (EDT) Message-Id: <199610141855.OAA08704@sabre.psc.edu> From: Jamshid Mahdavi To: braden@isi.edu CC: tcplw@bsdi.com, heyer@rrze.uni-erlangen.de In-reply-to: braden@isi.edu's message of Mon, 14 Oct 96 10:24:53 PDT Subject: Re: Question: FRC1323 implementations Reply-to: mahdavi@psc.edu References: <9610141724.AA21804@can.isi.edu> > since I don't know who else to ask: can you tell me if there are any > implementations of the 'High Performance TCP Options' described in RFC1323 > for SunOS or Solaris. This would be of great help for forthcoming tests of > a satellite link at our site. FYI, I keep a running list of implementation information for things which impact high performance TCP connections at http://www.psc.edu/networking/perf_tune.html It includes info on RFC1323, MTU discovery, default socket buffer sizes, SACK implementations, and notes on how to tune systems where possible. The collected information has been contributed by many, many people, and I am always interested in updates & additions. --Jamshid   Received: from cnri by ietf.org id aa05860; 14 Oct 96 16:41 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa20862; 14 Oct 96 16:41 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id OAA08255 for tcplw-list@bsdi.com; Mon, 14 Oct 1996 14:38:36 -0600 (MDT) Received: from nevin.bellcore.com (nevin.bellcore.com [192.4.15.85]) by external.BSDI.COM (8.7.6/8.7.3) with ESMTP id OAA08249 for ; Mon, 14 Oct 1996 14:38:30 -0600 (MDT) Received: (from isil@localhost) by nevin.bellcore.com (8.7.5/8.7.3) id QAA24270; Mon, 14 Oct 1996 16:37:22 -0400 (EDT) Date: Mon, 14 Oct 1996 16:37:22 -0400 (EDT) From: Isil Sebuktekin Message-Id: <199610142037.QAA24270@nevin.bellcore.com> To: braden@isi.edu, tcplw@bsdi.com Subject: Re: Question: FRC1323 implementations Cc: heyer@rrze.uni-erlangen.de These are some vendor leads I have from mid-to-end 1995. I don't know whether they are still valid or not. Isil Lee Camel Manager - Sun Consulting (415) 688-9147 (415) 812-7001 [fax] lee.camel@sun.com SunIntegration Services, 2550 Garcia Avenue MS MPK02-224, Mountain View, CA 94043. 415-688-9201. Additional information: Improves TCP performance over large BW*delay networks, includes window scaling, time stamps, and PAWS, implements RFC1323. Date: Tue, 16 Jan 1996 14:01:31 -0800 (PST) From: Bob Gilligan Subject: Re: Fast retransmit in Solaris 2.x > > > Solaris 2 does indeed support fast rexmit, plus lots of other modern TCP/IP > > features... > > > Bob Gilligan > > SunSoft Internet Engineering Group > > Bob, > How about window scaling and timestamps? That was context of the orignal message. There is a prototype implementation of the TCP large window extensions for Solaris 2 currently being tested. It is available at ftp://playground.sun.com/pub/tcp-lfn. Bob. > since I don't know who else to ask: can you tell me if there are any > implementations of the 'High Performance TCP Options' described in RFC1323 > for SunOS or Solaris. This would be of great help for forthcoming tests of > a satellite link at our site.   Received: from cnri by ietf.org id aa06211; 14 Oct 96 16:59 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa21506; 14 Oct 96 16:59 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id OAA09513 for tcplw-list@bsdi.com; Mon, 14 Oct 1996 14:57:11 -0600 (MDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id OAA09509 for ; Mon, 14 Oct 1996 14:57:06 -0600 (MDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id VAA14262; Mon, 14 Oct 1996 21:30:56 +0100 From: Luigi Rizzo Message-Id: <199610142030.VAA14262@labinfo.iet.unipi.it> Subject: Re: Question: FRC1323 implementations To: mahdavi@psc.edu Date: Mon, 14 Oct 1996 21:30:56 +0100 (MET) Cc: braden@isi.edu, tcplw@bsdi.com, heyer@rrze.uni-erlangen.de In-Reply-To: <199610141855.OAA08704@sabre.psc.edu> from "Jamshid Mahdavi" at Oct 14, 96 02:55:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text > FYI, I keep a running list of implementation information for things > which impact high performance TCP connections at > > http://www.psc.edu/networking/perf_tune.html > > It includes info on RFC1323, MTU discovery, default socket buffer > sizes, SACK implementations, and notes on how to tune systems where > possible. > > The collected information has been contributed by many, many people, > and I am always interested in updates & additions. If you like, in http://www.psc.edu/networking/tcp.html you can add pointers to a FreeBSD (2.1.X) implementation available from the following URL: http://www.iet.unipi.it/~luigi/sack.diffs Cheers Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ====================================================================   Received: from cnri by ietf.org id aa07722; 16 Oct 96 3:37 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa04643; 16 Oct 96 3:37 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id BAA23801 for tcplw-list@bsdi.com; Wed, 16 Oct 1996 01:32:46 -0600 (MDT) Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id BAA23794 for ; Wed, 16 Oct 1996 01:32:41 -0600 (MDT) Received: from rambo.futures.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 16 Oct 1996 08:31:58 +0100 Received: from maczebedee (actually macsmtp.futures.bt.co.uk) by rambo.futures.bt.co.uk with SMTP (PP); Wed, 16 Oct 1996 08:32:09 +0100 Message-ID: Date: 15 Oct 1996 23:01:09 U From: Martin Tatham Subject: RE: Question: FRC1323 implementations To: mahdavi@psc.edu Cc: tcplw@bsdi.com X-Mailer: Mail*Link SMTP for Quarterdeck Mail; Version 4.0.0 Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; Name="Message Body" Content-Transfer-Encoding: quoted-printable Jamshid, Thanks for the useful reference. > FYI, I keep a running list of implementation information for things > which impact high performance TCP connections at > > http://www.psc.edu/networking/perf_tune.html > > It includes info on RFC1323, MTU discovery, default socket buffer > sizes, SACK implementations, and notes on how to tune systems where > possible. > > The collected information has been contributed by many, many people, > and I am always interested in updates & additions. > > --Jamshid Does anyone have more details on the TCP implementations used in MacOS, = Windows NT, Win95 etc. - default window sizes, Fast Recovery & = Retransmission, etc.? Thanks, -Martin   Received: from cnri by ietf.org id aa24860; 16 Oct 96 13:57 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa17845; 16 Oct 96 13:57 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id LAA01557 for tcplw-list@bsdi.com; Wed, 16 Oct 1996 11:56:10 -0600 (MDT) Received: from ftp.com (ftp.com [128.127.2.122]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id LAA01551 for ; Wed, 16 Oct 1996 11:56:09 -0600 (MDT) Received: from ftp.com by ftp.com ; Wed, 16 Oct 1996 13:55:37 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 16 Oct 1996 13:55:37 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id NAA09688; Wed, 16 Oct 1996 13:55:31 -0400 Message-Id: <199610161755.NAA09688@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: martin.tatham@bt-sys.bt.co.uk, mahdavi@psc.edu Cc: tcplw@bsdi.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Sender: Frank T Solensky Subject: RE: Question: FRC1323 implementations Date: Wed, 16 Oct 1996 13:54:19 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Reply to your message -- >Does anyone have more details on the TCP implementations used in MacOS, >Windows NT, Win95 etc. - default window sizes, Fast Recovery & >Retransmission, etc.? FTP Software just started shipping OnNet 2.0 for Win95; it supports Path MTU, TCP selective ACK, RFC 1323. The default window size is 8KB for TCP and UDP sends and TCP receives, 48KB on UDP receives. Configuration currently is through regedit, with the TCP window size also accessable through a statistics program. We'll be working on a more user-palatible interface in the near future. -- Frank Solensky   Received: from cnri by ietf.org id aa25559; 16 Oct 96 14:15 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa18448; 16 Oct 96 14:15 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id MAA03773 for tcplw-list@bsdi.com; Wed, 16 Oct 1996 12:14:45 -0600 (MDT) Received: from ftp.com (ftp.com [128.127.2.122]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id MAA03770 for ; Wed, 16 Oct 1996 12:14:45 -0600 (MDT) Received: from ftp.com by ftp.com ; Wed, 16 Oct 1996 14:14:14 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 16 Oct 1996 14:14:14 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id OAA11641; Wed, 16 Oct 1996 14:14:08 -0400 Message-Id: <199610161814.OAA11641@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: tcplw@bsdi.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Sender: Frank T Solensky Subject: RE: Question: FRC1323 implementations Date: Wed, 16 Oct 1996 14:12:56 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit >Configuration currently is through regedit, with the TCP window size >also accessable through a statistics program. We'll be working on a >more user-palatible interface in the near future. Let me try that again: Currently, only the TCP window size is configurable though a GUI interface, the rest can be configured through regedit. We'll be adding these configuration options and values to the statistics program in the near future. (What can I say? I think sed and awk are user-friendly) -- Frank   Received: from cnri by ietf.org id aa18006; 17 Oct 96 22:13 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa28282; 17 Oct 96 22:13 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id UAA15537 for tcplw-list@bsdi.com; Thu, 17 Oct 1996 20:09:47 -0600 (MDT) Received: from mailer.psc.edu (mailer.psc.edu [128.182.58.100]) by external.BSDI.COM (8.7.6/8.7.3) with ESMTP id UAA15533 for ; Thu, 17 Oct 1996 20:09:46 -0600 (MDT) Received: from zippy.psc.edu (zippy.psc.edu [128.182.61.149]) by mailer.psc.edu (8.7.4/8.7.4 PSC 1996/04/22 lambert/mailer) with ESMTP id WAA29458; Thu, 17 Oct 1996 22:09:38 -0400 (EDT) Message-Id: <199610180209.WAA29458@mailer.psc.edu> Reply-to: mathis@psc.edu From: Matt Mathis To: tcplw@bsdi.com, end2end-interest@zippy.psc.edu Subject: SACK news! Date: Thu, 17 Oct 1996 22:09:38 -0400 Sender: mathis@zippy.psc.edu First, the SACK proposed standard was published today as RFC2018, ftp://ds.internic.net/rfc/rfc2018.txt. Second, Our SACK and FACK implementations are now available. See the information at http://www.psc.edu/networking/tcp.html. The page will be updated from time to time (and as of this afternoon, it is already out of date!) Included is a pointer to a technical note describing our recent enhancements to the FACK algorithm, with some pretty traces of a real TCP connection. As always feedback welcome, --MM--   Received: from cnri by ietf.org id aa13856; 22 Oct 96 13:43 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa16258; 22 Oct 96 13:43 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id LAA00820 for tcplw-list@bsdi.com; Tue, 22 Oct 1996 11:36:59 -0600 (MDT) Received: from lotus.lotus.com (lotus.com [192.233.136.1]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id LAA00817 for ; Tue, 22 Oct 1996 11:36:56 -0600 (MDT) Received: from internet1.lotus.com by lotus.lotus.com (SMI-8.6/SMI-SVR4) id NAA13594; Tue, 22 Oct 1996 13:32:52 -0400 Received: by internet1.lotus.com (5.x/SMI-SVR4) id AA12547; Tue, 22 Oct 1996 13:29:14 -0400 Message-Id: <9610221729.AA12547@internet1.lotus.com> Received: by Lotus (Lotus Notes Mail Gateway for SMTP V.03 Beta) id A170D67832B44E55852563CB005D5C92; Tue, 22 Oct 96 13:29:13 EDT To: Tcplw From: Robert Ullmann/CAM/Lotus Date: 22 Oct 96 13:31:16 EDT Subject: end run around TCP congestion control Mime-Version: 1.0 Content-Type: Text/Plain Hi, We've been working on audio/video/data sharing on TCP, and been watching what others have been doing. I've been noting something for a while, but a vendor announcement a few weeks ago crystallized the thought. They were proudly announcing that they had achieved a 9:5 performance improvement over TCP on the Internet by using their "Video Datagram Protocol". My immediate thought: yup, and you could've done it with TCP by turning off the congestion controls. And that's just what's happening: there are a couple of dozen protocols out there for streaming or (mostly audio) calls, and all but a couple that I know of use UDP, and try to transmit the full media rate (usually designed for a 28.8 or 14.4 modem/ISP connection) regardless of network congestion. If they get losses, well, they are more-or-less robust. You get breakup or frequency range loss. Never mind that the lost datagrams used network resources before reaching the congestion point, and never mind that the source continues to send until the user can't stand the quality degradation. (Details here vary somewhat between protocols.) One of the reasons we've been developing on TCP is that we need to do fairly demanding streaming, *without* trashing our customers' networks. A typical stream will be 250 Kbytes/second, and typical corporate LANs and "intranets" are already overloaded. This same observation applies to the wide open net, where one ought to be a good citizen. My point is that perhaps we should be encouraging more use of TCP for these applications. The client/peer software is usually a free download, and some vendors are claiming very large numbers of users (much inflated by, for example, the peer s/w being included with a browser, and never used; but the potential is there anyway, so the point is almost moot.) I can see a possible near future where 90+% of the Internet traffic is uncontrolled UDP transmits, with overall losses going up to the 30-40% that these programs can tolerate without becoming unusable. Not a pleasant thought. Best Regards, Robert Ullmann Lotus/IBM Business Multimedia Group (see http://robin.lotus.com)   Received: from cnri by ietf.org id aa15528; 22 Oct 96 14:07 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa16904; 22 Oct 96 14:07 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id MAA02867 for tcplw-list@bsdi.com; Tue, 22 Oct 1996 12:05:05 -0600 (MDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id MAA02857 for ; Tue, 22 Oct 1996 12:04:57 -0600 (MDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18319; Tue, 22 Oct 1996 11:04:36 -0700 Received: from florida.engr.sgi.com (florida.engr.sgi.com [150.166.75.9]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA14013; Tue, 22 Oct 1996 11:04:34 -0700 Received: (from skibo@localhost) by florida.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA04362; Tue, 22 Oct 1996 11:04:33 -0700 From: Thomas Skibo Message-Id: <9610221104.ZM4360@florida.engr.sgi.com> Date: Tue, 22 Oct 1996 11:04:32 -0700 In-Reply-To: Robert Ullmann/CAM/Lotus "end run around TCP congestion control" (Oct 22, 1:31pm) References: <9610221729.AA12547@internet1.lotus.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Robert Ullmann/CAM/Lotus , Tcplw Subject: Re: end run around TCP congestion control Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 22, 1:31pm, Robert Ullmann/CAM/Lotus wrote: > Subject: end run around TCP congestion control > Hi, > > We've been working on audio/video/data sharing on TCP, and been watching what > others have been doing. I've been noting something for a while, but a vendor > announcement a few weeks ago crystallized the thought. They were proudly > announcing that they had achieved a 9:5 performance improvement over TCP on the > Internet by using their "Video Datagram Protocol". My immediate thought: yup, > and you could've done it with TCP by turning off the congestion controls. Actually, I don't think you could. The first time you lost a packet due to congestion, you'd run into retransmissions which are disasterous and useless for video applications. It's not the congestion controls that people are trying to "get around" by UDP. It's the retransmissions. If you are worried about trashing customer's intranets (and anybody trying to make a useful product should), think about implementing similar congestion control and avoidance schemes over UDP (I'm sure it's already been done). -- --- Thomas Skibo Silicon Graphics, Inc. skibo@sgi.com   Received: from cnri by ietf.org id aa24877; 23 Oct 96 15:37 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa20553; 23 Oct 96 15:37 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id NAA11626 for tcplw-list@bsdi.com; Wed, 23 Oct 1996 13:31:47 -0600 (MDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by external.BSDI.COM (8.7.6/8.7.3) with ESMTP id NAA11620 for ; Wed, 23 Oct 1996 13:31:40 -0600 (MDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.7.3/8.7.3) with ESMTP id PAA06779; Wed, 23 Oct 1996 15:29:07 -0400 (EDT) Message-Id: <199610231929.PAA06779@brookfield.ans.net> To: Robert Ullmann/CAM/Lotus cc: Tcplw Reply-To: curtis@ans.net Subject: Re: end run around TCP congestion control In-reply-to: Your message of "22 Oct 1996 13:31:16 EDT." <9610221729.AA12547@internet1.lotus.com> Date: Wed, 23 Oct 1996 15:27:47 -0400 From: Curtis Villamizar In message <9610221729.AA12547@internet1.lotus.com>, Robert Ullmann/CAM/Lotus w rites: > Hi, > > We've been working on audio/video/data sharing on TCP, and been watching what > > others have been doing. I've been noting something for a while, but a vendor > announcement a few weeks ago crystallized the thought. They were proudly > announcing that they had achieved a 9:5 performance improvement over TCP on t > he > Internet by using their "Video Datagram Protocol". My immediate thought: yup, > > and you could've done it with TCP by turning off the congestion controls. > > And that's just what's happening: there are a couple of dozen protocols out > there for streaming or (mostly audio) calls, and all but a couple that I know > > of use UDP, and try to transmit the full media rate (usually designed for a > 28.8 or 14.4 modem/ISP connection) regardless of network congestion. If they > get losses, well, they are more-or-less robust. You get breakup or frequency > range loss. Never mind that the lost datagrams used network resources before > reaching the congestion point, and never mind that the source continues to se > nd > until the user can't stand the quality degradation. (Details here vary somewh > at > between protocols.) > > One of the reasons we've been developing on TCP is that we need to do fairly > demanding streaming, *without* trashing our customers' networks. A typical > stream will be 250 Kbytes/second, and typical corporate LANs and "intranets" > are already overloaded. This same observation applies to the wide open net, > where one ought to be a good citizen. > > My point is that perhaps we should be encouraging more use of TCP for these > applications. The client/peer software is usually a free download, and some > vendors are claiming very large numbers of users (much inflated by, for > example, the peer s/w being included with a browser, and never used; but the > potential is there anyway, so the point is almost moot.) I can see a possible > > near future where 90+% of the Internet traffic is uncontrolled UDP transmits, > > with overall losses going up to the 30-40% that these programs can tolerate > without becoming unusable. Not a pleasant thought. > > Best Regards, > Robert Ullmann > Lotus/IBM Business Multimedia Group > (see http://robin.lotus.com) Robert, At the risk of beating a dead horse.. This will change when fair queueing becomes more common (*FQ, for example the classic SFQ, where S is stochastic). Router vendors are now offering FQ capabilities. At that point protocols with congestion control will work much better than ones without (ie: lower resolution or frame rate but no holes in the picture, or drop to a different compression scheme which might be a little muddier but no crackle). Curtis   Received: from cnri by ietf.org id aa25549; 23 Oct 96 15:56 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa21061; 23 Oct 96 15:56 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id NAA13695 for tcplw-list@bsdi.com; Wed, 23 Oct 1996 13:54:48 -0600 (MDT) Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id NAA13690 for ; Wed, 23 Oct 1996 13:54:47 -0600 (MDT) Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA25098; Wed, 23 Oct 1996 15:50:52 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id PAA44652; Wed, 23 Oct 1996 15:50:50 -0400 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19386; Wed, 23 Oct 1996 15:55:54 -0400 Message-Id: <9610231955.AA19386@ludwigia.raleigh.ibm.com> To: curtis@ans.net Cc: Robert Ullmann/CAM/Lotus , Tcplw Subject: Re: end run around TCP congestion control In-Reply-To: Your message of "Wed, 23 Oct 1996 15:27:47 EDT." <199610231929.PAA06779@brookfield.ans.net> Date: Wed, 23 Oct 1996 15:55:54 -0300 From: Thomas Narten >This will change when fair queueing becomes more common And when will this happen? Seriously, what router vendors ship this today (or have plans to) for handling the general case? It seems that where FQ is used today is to give priority to special traffic (e.g., telnet), rather than to punish the bad guys (i.e., the general case where it's needed). The same question can be asked of RED. What are the real obstacles holding up general deployment? Thomas   Received: from cnri by ietf.org id aa13380; 24 Oct 96 15:24 EDT Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa19724; 24 Oct 96 15:24 EDT Received: (from daemon@localhost) by external.BSDI.COM (8.7.6/8.7.3) id NAA15336 for tcplw-list@bsdi.com; Thu, 24 Oct 1996 13:21:01 -0600 (MDT) Received: from fab.md.interlink.com (fab.md.interlink.com [138.42.32.80]) by external.BSDI.COM (8.7.6/8.7.3) with SMTP id NAA15318 for ; Thu, 24 Oct 1996 13:20:35 -0600 (MDT) Received: by fab.md.interlink.com (5.0/SMI-SVR4) id AA05713; Thu, 24 Oct 1996 15:25:51 +0500 Date: Thu, 24 Oct 1996 15:25:51 +0500 From: Fred Bohle Message-Id: <9610241925.AA05713@fab.md.interlink.com> To: tcplw@bsdi.com Subject: Re: tcp test tool X-Sun-Charset: US-ASCII Greetings, I am in the process of developing a TCP implementation and am looking for a tool to use in debugging it. I am looking for a tool to generate various special cases in TCP, such as packets out of order in all types of combinations, missing packets retransmitted packets. If you have done this type of development, and many of you have, you know the many corners of the code that cannot be reached testing over a link which is almost always reliable. So a test tool would be very useful. Do you have one that you could let me use? Fred P.S. This is going to three lists, thanks for ignoring any duplicates. ------------------------------------------------------------------------ Fred Bohle EMAIL: fab@interlink.com Interlink Computer Sciences AT&T : 410-992-7750 x314 9250 Rumsey Road, Suite 200 Home : 410-643-6720 Columbia, MD 21045-1946 ------------------------------------------------------------------------