From owner-tcpsat@lerc.nasa.gov Thu Feb 3 15:49: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 PAA29410; Thu, 3 Feb 2000 15:49:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA24505 for tcpsat-outgoing; Thu, 3 Feb 2000 14:36:32 -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 OAA24470 for ; Thu, 3 Feb 2000 14:36:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA06990; Thu, 3 Feb 2000 14:36:29 -0500 (EST) Received: from line34.comsat.net.ar(200.47.47.34) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006856; Thu, 3 Feb 00 14:35:45 -0500 Received: from bued146e.siemens.com.ar (localhost [127.0.0.1]) by bued146e.siemens.com.ar with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DF59DV7L; Thu, 3 Feb 2000 16:37:52 -0300 Received: by buea103e.siemens.com.ar with Internet Mail Service (5.5.2650.21) id <1AZWQR7M>; Thu, 3 Feb 2000 16:33:31 -0300 Message-ID: From: "Testasecca, Mariano" To: "'tcpsat@grc.nasa.gov'" Subject: Information about VSATs Date: Thu, 3 Feb 2000 16:33:48 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id OAA24489 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Could anybody facilitate me information of any kind about VSAT´s? Thanks abroad! Mariano Testasecca SIEMENS S.A. División Electromedicina Servicios de Salud - SHS Bolivar 177 1º Piso *+54-11-4340-8400 int. 2796 * mailto:mariano.testasecca@siemens.com.ar From owner-tcpsat@lerc.nasa.gov Thu Feb 3 16:18: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 QAA29750; Thu, 3 Feb 2000 16:18:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA03877 for tcpsat-outgoing; Thu, 3 Feb 2000 15:31:40 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA03865; Thu, 3 Feb 2000 15:31:34 -0500 (EST) Received: from torres (ras133.lerc.nasa.gov [139.88.123.133]) by apataki-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA07812; Thu, 3 Feb 2000 15:31:32 -0500 (EST) Message-Id: <4.1.20000203153301.009922e0@popserve.lerc.nasa.gov> X-Sender: caivanc@popserve.lerc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 03 Feb 2000 15:35:46 -0500 To: "Testasecca, Mariano" From: William D Ivancic Subject: Re: Information about VSATs Cc: "'tcpsat@grc.nasa.gov'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id PAA03866 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit From your signature, it appear that you may be interested in using satellites for telemedicine or other commercial applications. If so, check out Via Satellite or Satellite Communications magazines. There are many VSAT suppliers listed there. Regards, Will Ivancic At 04:33 PM 2/3/00 -0300, Testasecca, Mariano wrote: > >Could anybody facilitate me information of any kind about VSAT´s? >Thanks abroad! > >Mariano Testasecca >SIEMENS S.A. >División Electromedicina >Servicios de Salud - SHS >Bolivar 177 1º Piso >*+54-11-4340-8400 int. 2796 >* mailto:mariano.testasecca@siemens.com.ar > ********************************************* William D. Ivancic NASA Glenn Research Center 21000 Brookpark Rd. MS 54-8 Cleveland, Ohio 44135 USA Phone: 1 216 433 3494 FAX: 1 216 433 8705 Email: William.D.Ivancic@grc.nasa.gov wivancic@grc.nasa.gov http://ctd.grc.nasa.gov/5610/5610.html ********************************************* From owner-tcpsat@lerc.nasa.gov Thu Feb 3 17:32: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 RAA01381; Thu, 3 Feb 2000 17:32:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA14753 for tcpsat-outgoing; Thu, 3 Feb 2000 16:41:11 -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 QAA14730 for ; Thu, 3 Feb 2000 16:41:09 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA25190; Thu, 3 Feb 2000 16:41:08 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025128; Thu, 3 Feb 00 16:40:39 -0500 Received: from churchward.erg.abdn.ac.uk (churchward.erg.abdn.ac.uk [139.133.204.110]) by erg.abdn.ac.uk (8.9.3/8.9.3) with SMTP id VAA02257; Thu, 3 Feb 2000 21:45:33 GMT Received: from churchward.erg.abdn.ac.uk by churchward.erg.abdn.ac.uk (SMI-8.6/SMI-SVR4) id HAA01142; Thu, 3 Feb 2000 07:03:47 GMT Message-Id: <200002030703.HAA01142@churchward.erg.abdn.ac.uk> Date: Thu, 3 Feb 2000 07:03:46 +0000 (GMT) From: Martin Koyabe Reply-To: Martin Koyabe Subject: Re: Information about VSATs To: tcpsat@grc.nasa.gov, Mariano.Testasecca@siemens.com.ar MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: HWUiUDwaUqAKXANI/JEemw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lombok-fi.lerc.nasa.gov id QAA14741 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Mariano, John Everett's Book ' VSATs Very Small Aperture Terminals' could a nice starting point !! -- Martin --------------------------------------------------------------------- Martin L.W.D Koyabe e-mail: koyabe@erg.abdn.ac.uk Electronics Research Group Fraser Noble Building King's College, AB24 3UE (Off) +44-01224-272813 Aberdeen, UK (Mob) +44-07881-610825 > From: "Testasecca, Mariano" > To: "'tcpsat@grc.nasa.gov'" > Subject: Information about VSATs > Date: Thu, 3 Feb 2000 16:33:48 -0300 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id OAA24489 > > > Could anybody facilitate me information of any kind about VSAT´s? > Thanks abroad! > > Mariano Testasecca > SIEMENS S.A. > División Electromedicina > Servicios de Salud - SHS > Bolivar 177 1º Piso > *+54-11-4340-8400 int. 2796 > * mailto:mariano.testasecca@siemens.com.ar > > > > > > > From owner-tcpsat@lerc.nasa.gov Fri Feb 4 05:02: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 FAA21367; Fri, 4 Feb 2000 05:02:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA00419 for tcpsat-outgoing; Fri, 4 Feb 2000 04:00:18 -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 EAA00403 for ; Fri, 4 Feb 2000 04:00:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA28993; Fri, 4 Feb 2000 04:00:15 -0500 (EST) Received: from ahmler2.mail.eds.com(192.85.154.76) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028924; Fri, 4 Feb 00 03:59:53 -0500 Received: from nnsa.eds.com (nnsa-2.eds.com [192.85.154.30]) by ahmler2.mail.eds.com (8.9.3/8.9.3) with ESMTP id DAA06522; Fri, 4 Feb 2000 03:59:50 -0500 (EST) Received: from beahw1075709 ([198.132.114.38]) by nnsa.eds.com (8.9.3/8.9.3) with SMTP id DAA28559; Fri, 4 Feb 2000 03:59:16 -0500 (EST) Message-ID: <000601bf6eee$48023800$267284c6@BE.eds.com> From: "Jan Broux" To: Cc: Subject: Re: Information about VSATs Date: Fri, 4 Feb 2000 10:00:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01BF6EF6.A6E37D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0003_01BF6EF6.A6E37D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mariano, There is quite a lot of info on following site : HNS is one of the VSAT suppliers. http://www.hns.com/products/snd/snd.htm Jan Broux ------=_NextPart_000_0003_01BF6EF6.A6E37D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mariano,
 
There is quite a lot of info on following site = :
HNS is one of the VSAT suppliers.
 
http://www.hns.com/produ= cts/snd/snd.htm
 
Jan Broux
 
------=_NextPart_000_0003_01BF6EF6.A6E37D40-- From owner-tcpsat@lerc.nasa.gov Fri Feb 4 06:30: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 GAA21827; Fri, 4 Feb 2000 06:30:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA04498 for tcpsat-outgoing; Fri, 4 Feb 2000 05:43:06 -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 FAA04348; Fri, 4 Feb 2000 05:38:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA05807; Fri, 4 Feb 2000 05:38:30 -0500 (EST) Received: from ada.cs.ucy.ac.cy(194.42.10.200) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005775; Fri, 4 Feb 00 05:37:57 -0500 Received: from cs099 (cs099.cs.ucy.ac.cy [194.42.10.211]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id MAA33184; Fri, 4 Feb 2000 12:40:13 +0200 Message-ID: <016801bf6efc$637a8110$d30a2ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: Subject: IEEE INFOCOM 2001 Call for participation Date: Fri, 4 Feb 2000 12:40:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit ---------------------------------<>----------------------------------- The 20th Annual Conference of IEEE Communications and Computer Societies C A L L F O R P A P E R S I E E E I N F O C O M 2 0 0 1 The Conference on Computer Communications "20 Years into the Communications Odyssey" http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska Sponsored by the IEEE Communications and Computer Societies CALL FOR PAPERS ================ The major conference on computer communications and networking is celebrating its 20th anniversary in the splendid setting of Anchorage (Alaska) during the week of April 22-26. The conference will bring together researchers and practitioners of every aspect of digital communications and networks, presenting the most up-to-date results and achievements in these fields. The IEEE INFOCOM 2001 program committee is soliciting original papers describing state-of-the-art research and development in all areas of computer networking and data communications. Topics of interest include, but are not limited to, the following: BISDN and ATM Network management and control Billing and pricing Network measurements and testbeds Communication protocols Protocol design and analysis Congestion and admission control Quality of service Flow control Queueing theory Cryptography, information hiding Scheduling Internet and web applications Security and privacy Optical networks Storage area networks Mobile networks Switching and switch architectures Multicast Traffic management and control Multimedia Routing Multiple access Web performance and caching Network architectures Wireless networks PAPER SUBMISSION ================ Papers must be submitted electronically according to the instructions described in and summarized below. Proposals for panels, half- or full-day tutorials should be submitted to the respective chairs. Please refer to the conference web site for further details. Papers must be formatted according to the IEEE standard format except for the font size, which MUST be 11pt. To make it easy to adhere to the formatting standard, we offer templates and samples for LaTex, MSWord, and FrameMaker (please refer to the pertinent web pages at ). ------------------------------------------------------------------- PAPERS THAT DO NOT COMPLY TO THE ABOVE FORMAT CANNOT BE REVIEWED ------------------------------------------------------------------- Submissions must be in PDF or Postscript. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. (Please note that Postscript output from MSWord typically does not work on non-Microsoft platforms. The use of the Apple LaserWriter II printer driver is strongly recommended). The above formatted papers can be submitted in a compressed form (gzip, zip, WinZip, compress). Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, ----------------------------------------------------- PAPERS WITH MORE THAN 11 PAGES CANNOT BE REVIEWED ----------------------------------------------------- (this is roughly equivalent to 20 double-spaced pages). Papers must be submitted electronically using the Web site at . This web page contains exact and detailed instructions about the submission process. Author's contact information must be provided during submission. To save space, authors may omit this information from the paper itself. Authors will receive an immediate notification of the successful receipt of the file containing their paper. Subsequently, a formal notification will be sent after verifying that the paper can be printed successfully. ------------------------------------------------------------------------- | SUBMISSIONS WILL ONLY BE ACCEPTED BETWEEN MAY 1ST AND JULY 5TH, 2000. | ------------------------------------------------------------------------- SUBMISSION DEADLINES ARE STRICT! PAPERS THAT HAVE BEEN IMPROPERLY SUBMITTED OR IMPROPERLY FORMATTED BY THE SUBMISSION DEADLINE WILL NOT BE CONSIDERED. TO AVOID LAST MINUTE PROBLEMS, AUTHORS ARE ENCOURAGED TO SUBMIT THEIR PAPERS WELL IN ADVANCE OF THE DEADLINE. THE REVIEW PROCESS ================== Each paper will typically be reviewed by three independent reviewers, whose reviews will be relayed to the corresponding author. Following last year successful experiment, authors will have a chance to provide a limited rebuttal on the reviews before the program committee makes its final decision. TRAVEL GRANTS ============= Limited travel assistance to students, post-docs and junior faculty presenting a paper in the conference will be available. Please refer to the conference web site for further details. IMPORTANT DATES =============== Complete paper due July 5, 2000 Notification of acceptance October 31, 2000 Final version due December 31, 2000 PROGRAM COMMITTEE CO-CHAIRS [infocom@watson.ibm.com] =========================== Rene L. Cruz, UCSD Giovanni Pacifici, IBM Research From owner-tcpsat@lerc.nasa.gov Mon Feb 7 11:21: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 LAA14039; Mon, 7 Feb 2000 11:21:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA15403 for tcpsat-outgoing; Mon, 7 Feb 2000 10:11:57 -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 KAA15348 for ; Mon, 7 Feb 2000 10:11:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA20938; Mon, 7 Feb 2000 10:11:49 -0500 (EST) Received: from line34.comsat.net.ar(200.47.47.34) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020909; Mon, 7 Feb 00 10:11:27 -0500 Received: from bued146e.siemens.com.ar (localhost [127.0.0.1]) by bued146e.siemens.com.ar with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DF59D5T5; Mon, 7 Feb 2000 12:13:27 -0300 Received: by buea103e.siemens.com.ar with Internet Mail Service (5.5.2650.21) id <1J0GBVG4>; Mon, 7 Feb 2000 12:09:02 -0300 Message-ID: From: "Testasecca, Mariano" To: "'tcpsat@grc.nasa.gov'" Subject: TCP/IP via VSATs Date: Mon, 7 Feb 2000 12:09:19 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id KAA15398 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Does anybody know which are the delays and implications that I should take into account while building a WAN network running TCP/IP under VSATs? Any information, paper or link will be very appreciated. Thanks Mariano Testasecca SIEMENS S.A. División Electromedicina Servicios de Salud - SHS Bolivar 177 1º Piso *+54-11-4340-8400 int. 2796 * mailto:mariano.testasecca@siemens.com.ar From owner-tcpsat@lerc.nasa.gov Mon Feb 7 11:23:20 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 LAA14085; Mon, 7 Feb 2000 11:23:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA15449 for tcpsat-outgoing; Mon, 7 Feb 2000 10:12:31 -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 KAA14244; Mon, 7 Feb 2000 10:05:51 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA19986; Mon, 7 Feb 2000 10:05:49 -0500 (EST) Received: from smtp7.atl.mindspring.net(207.69.128.51) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019858; Mon, 7 Feb 00 10:05:20 -0500 Received: from dave2 (user-33qt8bb.dialup.mindspring.com [199.174.161.107]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with SMTP id KAA13601; Mon, 7 Feb 2000 10:05:15 -0500 (EST) Reply-To: From: "David R. Beering" To: , , Subject: CALL FOR PARTICIPATION - Explicit Corruption Notification Experiments Date: Mon, 7 Feb 2000 09:05:27 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit C A L L F O R P A R T I C I P A T I O N Study of Mechanisms and Algorithms for TCP/IP Explicit Corruption Notification NASA Glenn Research Center at Lewis Field Background: For the past three years a group of researchers, along with a large group of partner organizations from industry and government laboratories, have been engaged in a multi-platform TCP/IP performance experiment using NASA's Advanced Communications Technology Satellite (ACTS). This experiment, currently known as ACTS Experiment 154, has focused on TCP/IP performance optimization over the ACTS Geostationary satellite at data rates of 155Mbps and 622Mbps. As a result of extensive FEC, these channels typically operate error-free, providing an ideal environment for TCP performance testing. More information on the experiment is provided below: Purpose: Testing of TCP/IP performance and interoperability using NASA's Advanced Communications Technology Satellite (ACTS). Testing is conducted in homogeneous host configurations (i.e. Sun-to-Sun) and in heterogeneous host configurations (i.e. Sun to IBM). Primary experiment Components: 1. Single-stream TCP/IP performance testing over satellite channels with bandwidth-delay products of up to 70 MBytes 2. Research and development / discovery of new techniques to help TCP distinguish between channel corruption and congestion Technical Environment: Workstation interfaces (LAN): - 100BaseT - Gigabit Ethernet - ATM (155 Mbps and 622 Mbps) Satellite Channel: - 1 x 155 Mbps SONET - 2 x 155 Mbps SONET - 1 x 622 Mbps SONET WAN Interfaces: - 155 Mbps ATM - 622 Mbps ATM - 155 Mbps PoS - 622 Mbps PoS The 154 Experiment Consortium presently includes the following participants: NASA Glenn Research Center NASA Johnson Space Center NASA Jet Propulsion Laboratory NASA Goddard Space Flight Center US Naval Research Laboratory Lawrence Livermore National Laboratory Marconi Communications Cisco Systems Ampex Data Systems Cabletron Systems Raytheon Telecommunications Spectrum Astro Lockheed Martin Space Systems / Loral Hughes Space & Communications Sun Microsystems Intel Microsoft Compaq IBM Hewlett-Packard NetManage WindRiver Systems More information: For more information on the experiment, including some historical TCP performance test results, please visit our public web site, located at the URL below: http://mrpink.grc.nasa.gov/118x The Opportunity: Our team is in the process of building a new testbed facility that will support links across the ACTS spacecraft at data rates ranging up to 8 Mbps, with any bit error rate. The testbed will utilize laboratories at the NASA Glenn Research Center in Cleveland, the US Naval Research Laboratory in Washington, DC, and Lockheed Martin Space Operations in Houston. We will also be able to leverage the unique ability of ACTS to support satellite links operating at extremely high rates (155Mbps, 622Mbps) for this work, should that be desirable in the context of these tests. The focus of the new laboratory capability will be to specifically study mechanisms that provide explicit notification of link corruption and congestion, with the goal of gaining a better understanding of these mechanisms in order to promote further work on the most promising mechanisms. The eventual goal of this work is the make it possible for Explicit Corruption Nofitication mechanisms to be safe for implementation in the Internet at-large. This work is expected to continue beyond the end of life of the ACTS spacecraft, presently slated for the end of June, 2000. We are soliciting participation from the Internet community through personal invitations, and through this announcement being distributed via the IETF's 'tcpsat', 'pilc', and 'end2end' interest groups. We are in the process of assembling the workstations and networking hardware to support this experiment. This initially will include Unix workstations supporting Solaris 7, and PC platforms supporting Linux. Other platforms and operating system environments will be added depending on requirements. Experiment proposals will be evaluated by our team for their ability to be integrated into and tested in our environment. For those mechanisms selected for testing, we will provide access to the hardware platforms (in-person and/or remote), and satellite time on the ACTS spacecraft for testing and evaluation of the mechanisms. If your organization is involved in the development of algorithms or mechanisms in the area of explicit corruption notification, and you would be interested to participate in this experiment, please contact our team at one of the contact coordinates below: David R. Beering Experiment 154 Coordinator NASA Glenn Research Center drbeering@sprynet.com 630-665-1396 (Office) 630-235-7965 (PCS) or Michael J. Zernic ACTS HDR Experiment Manager NASA Glenn Research Center mzernic@grc.nasa.gov 216-433-5286 (Office) or Mark Solsman United States Naval Research Laboratory Information Technology Division Satellite and Wireless Networking Section solsman@nrl.navy.mil 202-404-4667 (Office) From owner-tcpsat@lerc.nasa.gov Mon Feb 7 11:55:37 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 LAA15085; Mon, 7 Feb 2000 11:55:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA23485 for tcpsat-outgoing; Mon, 7 Feb 2000 10:56:05 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA23466; Mon, 7 Feb 2000 10:55:58 -0500 (EST) Received: from torres (ras106.lerc.nasa.gov [139.88.123.106]) by apataki-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA03748; Mon, 7 Feb 2000 10:55:56 -0500 (EST) Message-Id: <4.1.20000207105601.00a05a40@popserve.lerc.nasa.gov> X-Sender: caivanc@popserve.lerc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Feb 2000 11:00:40 -0500 To: "Testasecca, Mariano" From: William D Ivancic Subject: Re: TCP/IP via VSATs Cc: "'tcpsat@grc.nasa.gov'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id KAA23467 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Figure at least 550 msec delay for a meshed VSAT (one-hop) architecture assuming Geosynchronous satellites. The delay depends on the satellite network archetecture deployed and terrestrial networks that are being utilized. The link characteristics should be provided by the VSAT and Satellite Network providers. Will Ivancic At 12:09 PM 2/7/00 -0300, Testasecca, Mariano wrote: > >Does anybody know which are the delays and implications that I should take >into account while building >a WAN network running TCP/IP under VSATs? >Any information, paper or link will be very appreciated. > >Thanks > >Mariano Testasecca >SIEMENS S.A. >División Electromedicina >Servicios de Salud - SHS >Bolivar 177 1º Piso >*+54-11-4340-8400 int. 2796 >* mailto:mariano.testasecca@siemens.com.ar > ********************************************* William D. Ivancic NASA Glenn Research Center 21000 Brookpark Rd. MS 54-8 Cleveland, Ohio 44135 USA Phone: 1 216 433 3494 FAX: 1 216 433 8705 Email: William.D.Ivancic@grc.nasa.gov wivancic@grc.nasa.gov http://ctd.grc.nasa.gov/5610/5610.html ********************************************* From owner-tcpsat@lerc.nasa.gov Mon Feb 7 13:33:55 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 NAA18418; Mon, 7 Feb 2000 13:33:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA10112 for tcpsat-outgoing; Mon, 7 Feb 2000 12:33:18 -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 MAA10080 for ; Mon, 7 Feb 2000 12:33:14 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA13519; Mon, 7 Feb 2000 12:33:13 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013478; Mon, 7 Feb 00 12:32:43 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.9.3/8.9.3) with ESMTP id RAA13449; Mon, 7 Feb 2000 17:37:51 GMT Message-ID: <389EF37A.D57EBDCC@erg.abdn.ac.uk> Date: Mon, 07 Feb 2000 17:32:51 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov CC: "Testasecca, Mariano" Subject: Re: Information about VSATs References: Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id MAA10090 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit "Testasecca, Mariano" wrote: > Could anybody facilitate me information of any kind about VSAT´s? > Thanks abroad! I believe the mailing list is to deal with understanding issues and suggesting optimizations. However, I enclose a short bibliography on the TCP/IP Issues via VSAT, which may be of use for those joining the group more recently... Gorry Fairhurst. -------------------------------------- Internet Engineering Task Force TCP Over Satellite WG http://tcpsat.grc.nasa.gov/tcpsat/ -------------------------------------- 1. Stevens, W. R., 1997, TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms, RFC 2001, IETF. 2. Kirstein, P. T., et al., 1979, SATNET Applications Activities, Nat. Telecom. Conf., IEEE. 3. Ghani, N. and Dixit, S., 1999, TCP/IP Enhancements for Satellite Networks, IEEE Com. Mag., 37 (7): 64-72. 4. Xylomenos, G. and Polyzos, G. C., 1999, Internet Protocol Performance over Networks with Wireless Links, IEEE Network, 13 (4): 55-63. 5. Allman, M., et al., 1999, Enhancing TCP Over Satellite Channels using Standard Mechanisms, RFC 2488, IETF. 6. Allman, M., et al., 1999, Internet Draft of TCPSAT WG : Ongoing TCP Research Related to Satellites, draft-ietf-tcpsat-res-issues, IETF. 7. Samaraweera, N. and Fairhurst, G., 1998, Reinforcement of TCP/IP Error Recovery for Wireless Communications, Comp Com. Rev., 28 (2): 30-38. (Updated copy submitted to IEEE ToN). 8. Mathis, M., et al., 1996, TCP Selective Acknowledgment Options, RFC 2018, IETF. 9. Allman, M., et al., 1999, TCP Congestion Control, RFC 2581, IETF 10. Saltzer, H. J., et al., 1984, End-to-End Arguments in Systems Design, ACM Trans on Comp Systems, 2 (4): 277-288. 11. Karn, P., et al., 1999, Internet Draft of PILC WG : Advice for Internet Subnetwork Designers, draft-ietf-pilc-link-design.txt, IETF. see also: http://tcpsat.grc.nasa.gov/tcpsat/papers.html -------------------------------------- VSATs Course: Small Terminal Satellite Communications Technology, Applications & Opportunities http://www.amp.york.ac.uk/dept/contedu/flyer/vsats.html Annual 1-Week Course (27th - 31st March 2000), in the heart of the historic City of York, UK. SCOPE: Communications systems using Very Small Aperture Terminals (VSATs) are expanding rapidly world-wide. VSAT systems provide a wide variety of communications requirements and offer considerable opportunities for exploitation, especially Internet and multimedia services. The Course gives a technical foundation for all those entering this area, coupled with an appreciation of the latest developments, and aims to provide the tools and understanding to deal with VSAT systems and their applications -------------------------------------- Workshop on Satellite-Based Information Society (WOSBIS) Annual Workshop sponsored by ACM Sigmobile and technical co-sponsored by IEEE -------------------------------------- From owner-tcpsat@lerc.nasa.gov Mon Feb 7 13:39: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 NAA18517; Mon, 7 Feb 2000 13:39:25 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13089 for tcpsat-outgoing; Mon, 7 Feb 2000 12:52:07 -0500 (EST) 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 MAA13085 for ; Mon, 7 Feb 2000 12:52:05 -0500 (EST) Message-Id: <200002071752.MAA13085@lombok-fi.lerc.nasa.gov> To: tcpsat@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: RFC Editor: RFC 2760 on Ongoing TCP Research Related to Satellites Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Love Stinks Date: Mon, 07 Feb 2000 12:52:05 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk FYI... Thanks everyone! allman ------- Forwarded Message To: IETF-Announce:;@loki.ietf.org Subject: RFC 2760 on Ongoing TCP Research Related to Satellites Cc: rfc-ed@ISI.EDU Date: Fri, 04 Feb 2000 09:24:20 -0800 From: RFC Editor - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2760 Title: Ongoing TCP Research Related to Satellites Author(s): M. Allman, S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke Status: Informational Date: February 2000 Mailbox: mallman@grc.nasa.gov, Spencer.Dawkins.sdawkins@nt.com, Daniel.R.Glover@grc.nasa.gov, jgriner@grc.nasa.gov, johnh@isi.edu, tomh@cs.berkeley.edu, hkruse1@ohiou.edu, ostermann@cs.ohiou.edu, kscott@mitre.org, semke@psc.edu, touch@isi.edu, dtran@grc.nasa.gov Pages: 46 Characters: 111141 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpsat-res-issues-12.txt URL: ftp://ftp.isi.edu/in-notes/rfc2760.txt This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by the IETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks. This document is a product of the TCP Over Satellite Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000204091958.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2760 - --OtherAccess Content-Type: Message/External-body; name="rfc2760.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000204091958.RFC@RFC-EDITOR.ORG> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-tcpsat@lerc.nasa.gov Mon Feb 7 13:59:06 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 NAA19046; Mon, 7 Feb 2000 13:59:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13764 for tcpsat-outgoing; Mon, 7 Feb 2000 12:56:33 -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 MAA13739 for ; Mon, 7 Feb 2000 12:56:31 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA16746; Mon, 7 Feb 2000 12:56:29 -0500 (EST) Received: from mailhost.iprg.nokia.com(205.226.5.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016610; Mon, 7 Feb 00 12:55:45 -0500 Received: from aspen.iprg.nokia.com ([205.226.14.73]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA29498 for ; Mon, 7 Feb 2000 09:55:44 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by aspen.iprg.nokia.com (8.8.8/8.6.12) id JAA00422 for tcpsat@lerc.nasa.gov; Mon, 7 Feb 2000 09:55:43 -0800 (PST) Date: Mon, 7 Feb 2000 09:55:43 -0800 (PST) Message-Id: <200002071755.JAA00422@aspen.iprg.nokia.com> To: tcpsat@lerc.nasa.gov Subject: INFOCOM 2000 Call For Participation Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT ========= Early registration cut-off date: February 28, 2000 (only 3 more weeks) Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-tcpsat@lerc.nasa.gov Tue Feb 8 09:19: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 JAA22462; Tue, 8 Feb 2000 09:19:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA14916 for tcpsat-outgoing; Tue, 8 Feb 2000 08:15:48 -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 IAA14889 for ; Tue, 8 Feb 2000 08:15:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA09458; Tue, 8 Feb 2000 08:15:42 -0500 (EST) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009432; Tue, 8 Feb 00 08:15:24 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Feb 2000 08:15:23 -0500 Message-ID: <8046A317B5F4D21186610008C7EBB696F05549@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'gorry@erg.abdn.ac.uk'" , tcpsat@grc.nasa.gov Cc: "Testasecca, Mariano" Subject: RE: Information about VSATs Date: Tue, 8 Feb 2000 08:10:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Gorry- A nice bibliography. I'd also like to point to one of my favorite tutorial papers: Partridge, C., Shepard, T., 1997, "TCP/IP Performance over Satellite Links," IEEE Network, Sept./Oct. 1997, pp 44-49. --aaron --- Aaron Falk Director - Internet Services Development PanAmSat Corporation Greenwich, Connecticut, USA * Tel: 203.861.8326 * Fax: 203.861.8677 * mailto:afalk@panamsat.com * http://www.panamsat.com -----Original Message----- From: Dr G Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Monday, February 07, 2000 11:33 AM To: tcpsat@grc.nasa.gov Cc: Testasecca, Mariano Subject: Re: Information about VSATs However, I enclose a short bibliography on the TCP/IP Issues via VSAT, which may be of use for those joining the group more recently... Gorry Fairhurst. From owner-tcpsat@lerc.nasa.gov Tue Feb 8 11:45: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 LAA01105; Tue, 8 Feb 2000 11:45:42 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA04640 for tcpsat-outgoing; Tue, 8 Feb 2000 10:24: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 KAA04636 for ; Tue, 8 Feb 2000 10:24:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA26200; Tue, 8 Feb 2000 10:24:44 -0500 (EST) Received: from unknown(202.159.65.208) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025616; Tue, 8 Feb 00 10:22:52 -0500 Received: (from uucp@localhost) by java.ptpn13.com (8.8.7/8.8.7) with UUCP id QAA29167; Tue, 8 Feb 2000 16:39:53 GMT Received: from localhost (dieter@localhost) by banda.ptpn13.com (8.8.7/8.8.7) with ESMTP id WAA01684; Tue, 8 Feb 2000 22:40:19 GMT Date: Tue, 8 Feb 2000 22:40:19 +0000 (UTC) From: "Dr. Dieter Pukatzki" To: "Testasecca, Mariano" , Dieter Pukatzki cc: Klaus Lichtenwalder , "'tcpsat@grc.nasa.gov'" , William D Ivancic Subject: Re: TCP/IP via VSATs (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lombok-fi.lerc.nasa.gov id KAA04637 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Subject: Re: TCP/IP via VSATs > > Figure at least 550 msec delay for a meshed VSAT (one-hop) architecture ~~~~~~~ that is right, figure on 690 to 720 - if there is not much traffic on the line - that's we are getting C-Band in Indonesia > assuming Geosynchronous satellites. The delay depends on the satellite > network archetecture deployed and terrestrial networks that are being utilized. > > The link characteristics should be provided by the VSAT and Satellite > Network providers. > I would'nt bet on that. > > Will Ivancic > > At 12:09 PM 2/7/00 -0300, Testasecca, Mariano wrote: > > > >Does anybody know which are the delays and implications that I should take > >into account while building > >a WAN network running TCP/IP under VSATs? > >Any information, paper or link will be very appreciated. > > A lot depends on 1. SCPC (Single channel per carrier) or MCPC (multiple channel per carrier) -the first is like a leased line andobviously faster 2. the power you beam at the bird (20watt RFs yield obviously more than 5 or 10) 3. Size of the dish - we use 2.4m (almost a minimum for good performance) 4. How well the sat engineers "tuned" your modem, and the quality of the modem 5. How many error correction you get and whether you allocate 20 or 33 % or whatever for error correction channel (On this I am a little foggy, because I am just a user not an engineer) and above all 6. Using SACK (SELECTING Acknowledgement) or not, because getting a "traffic jam" at the reception is your biggest problem There people like mentat (www.mentat.com) who can improve performance using XTCP (Express TCP or so) which Al Weaver invented years ago for gigatransfers. Thats useful for downloading websides or large files. Hint: when you use ping, add the -c option in order not distort the packet loss. I use ftp-transfer rate for performance measure and require 5K/sec or better I measure performa > >Thanks > > > >Mariano Testasecca > >SIEMENS S.A. > >División Electromedicina > >Servicios de Salud - SHS > >Bolivar 177 1º Piso wau, you are as far out as we are in Kalimantan > >*+54-11-4340-8400 int. 2796 > >* mailto:mariano.testasecca@siemens.com.ar > > > > ********************************************* > William D. Ivancic > NASA Glenn Research Center > 21000 Brookpark Rd. MS 54-8 > Cleveland, Ohio 44135 > USA > Phone: 1 216 433 3494 > FAX: 1 216 433 8705 > Email: William.D.Ivancic@grc.nasa.gov > wivancic@grc.nasa.gov > http://ctd.grc.nasa.gov/5610/5610.html > ********************************************* > From owner-tcpsat@lerc.nasa.gov Tue Feb 8 13:32:20 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 NAA06487; Tue, 8 Feb 2000 13:32:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24676 for tcpsat-outgoing; Tue, 8 Feb 2000 12:26:03 -0500 (EST) 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 MAA24671 for ; Tue, 8 Feb 2000 12:26:01 -0500 (EST) Message-Id: <200002081726.MAA24671@lombok-fi.lerc.nasa.gov> To: tcpsat@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: The IESG: WG Action: TCP Over Satellite (tcpsat) to conclude Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Who Made Who Date: Tue, 08 Feb 2000 12:26:01 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk FYI... ------- Forwarded Message From: The IESG To: IETF-Announce:;@loki.ietf.org Subject: WG Action: TCP Over Satellite (tcpsat) to conclude Date: Tue, 08 Feb 2000 10:02:06 -0500 With the publication of RFC 2760, the TCP Over Satellite (tcpsat) Working Group in the Transport Area of the IETF has concluded. The IESG Contact Persons are Scott Bradner and Vern Paxson ------- End of Forwarded Message From owner-tcpsat@lerc.nasa.gov Thu Feb 10 14:14: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 OAA08092; Thu, 10 Feb 2000 14:14:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA27141 for tcpsat-outgoing; Thu, 10 Feb 2000 12:56:15 -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 MAA27092 for ; Thu, 10 Feb 2000 12:56:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA06985; Thu, 10 Feb 2000 12:56:08 -0500 (EST) Received: from vni62.vninet.com(209.118.74.62) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006947; Thu, 10 Feb 00 12:55:42 -0500 Received: by oscar.penguinpowered.com (Postfix, from userid 501) id 05402247D9; Thu, 10 Feb 2000 09:04:04 -0500 (EST) Date: Thu, 10 Feb 2000 09:04:04 -0500 From: Graham Street To: tcpsat@grc.nasa.gov Subject: nt to nt tcpsat problems Message-ID: <20000210090404.A27345@oscar.penguinpowered.com> Reply-To: gstreet@vninet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Hi all, We're trying to run windows file sharing protocols over a tcp sat link and getting miserable performance, even after setting TcpWindowSize to 65536. We can get about 100-250k max. We are trying to get at least one megabit out of it. Is this even possible? We can get 1-2 megabits ftping from a sun box over satellite... does anyone know of any clever (cheap) solutions (spoofing nacks?, translating to udp?) Thanks, Graham Street gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Thu Feb 10 15:11: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 PAA09426; Thu, 10 Feb 2000 15:11:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA10412 for tcpsat-outgoing; Thu, 10 Feb 2000 14:18:54 -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 OAA10374 for ; Thu, 10 Feb 2000 14:18:51 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA23563; Thu, 10 Feb 2000 14:18:50 -0500 (EST) Received: from iserv.intelsat.int(164.86.102.11) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023518; Thu, 10 Feb 00 14:18:11 -0500 Received: from kensington ([208.202.21.22]) by iserv.intelsat.int (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-49113U1000L2S100) with SMTP id AAA26310; Thu, 10 Feb 2000 14:18:03 -0500 From: "Robert Schellhase" To: Cc: Subject: RE: nt to nt tcpsat problems Date: Thu, 10 Feb 2000 14:18:06 -0500 Message-ID: <000001bf73fb$8f1de5b0$1615cad0@kensington> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <20000210090404.A27345@oscar.penguinpowered.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi Graham, I see you have found that Windows supports a registry key for TcpWindowSize. The sad news is that it has no effect, in spite of the fact that Microsoft has a white paper on its own TCP implementation that claims otherwise. You might try the NetManage OnNet kernel for Windows 95/98 at http://www.netmanage.com/products/onnetkernel4/index.asp I don't know what they charge for it, but I think it's affordable and they offer a free demo. Best regards, Robert Schellhase Senior Engineer INTELSAT -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Graham Street Sent: Thursday, February 10, 2000 9:04 AM To: tcpsat@grc.nasa.gov Subject: nt to nt tcpsat problems Hi all, We're trying to run windows file sharing protocols over a tcp sat link and getting miserable performance, even after setting TcpWindowSize to 65536. We can get about 100-250k max. We are trying to get at least one megabit out of it. Is this even possible? We can get 1-2 megabits ftping from a sun box over satellite... does anyone know of any clever (cheap) solutions (spoofing nacks?, translating to udp?) Thanks, Graham Street gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Thu Feb 10 19:23: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 TAA13317; Thu, 10 Feb 2000 19:23:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA29506 for tcpsat-outgoing; Thu, 10 Feb 2000 18:30:27 -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 SAA29476 for ; Thu, 10 Feb 2000 18:30:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA13119; Thu, 10 Feb 2000 18:30:24 -0500 (EST) Received: from palrel1.hp.com(156.153.255.242) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013098; Thu, 10 Feb 00 18:30:21 -0500 Received: from tpantmail1.ssr.hp.com (tpantmail1.ssr.hp.com [15.19.244.37]) by palrel1.hp.com (Postfix) with ESMTP id 8EB7937B for ; Thu, 10 Feb 2000 15:30:14 -0800 (PST) Received: by tpantmail1.ssr.hp.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Feb 2000 18:30:16 -0500 Message-ID: <472E220BA79DD11186340060B06B38D9029A44AA@tpantmail1.ssr.hp.com> From: David Godwin To: "'gstreet@vninet.com'" , tcpsat@grc.nasa.gov Subject: RE: nt to nt tcpsat problems Date: Thu, 10 Feb 2000 18:30:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Hi Graham, Sounds like you might want to try XFTP (see http://roland.grc.nasa.gov/~mallman/papers/wosbis.ps). Also, there are some interesting papers at http://tcpsat.lerc.nasa.gov/tcpsat/papers.html. Best regards, David Godwin Petroleum/C-Store Development Engineer VeriFone, a division of Hewlett-Packard Office: (727) 953-4072 Fax: (727) 953-4001 http://www.verifone.hp.com Mailto:David_Godwin@HP.com > -----Original Message----- > From: Graham Street [SMTP:gstreet@oscar.penguinpowered.com] > Sent: Thursday, February 10, 2000 9:04 AM > To: tcpsat@grc.nasa.gov > Subject: nt to nt tcpsat problems > > Hi all, > > We're trying to run windows file sharing protocols over a tcp sat link > and getting miserable performance, even after setting TcpWindowSize to > 65536. We can get about 100-250k max. We are trying to get at least > one megabit out of it. Is this even possible? We can get 1-2 megabits > ftping from a sun box over satellite... > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > translating > to udp?) > > Thanks, > Graham Street > gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Thu Feb 10 19:36: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 TAA13468; Thu, 10 Feb 2000 19:36:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA01502 for tcpsat-outgoing; Thu, 10 Feb 2000 18:46:13 -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 SAA01468 for ; Thu, 10 Feb 2000 18:46:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA16286; Thu, 10 Feb 2000 18:46:09 -0500 (EST) Received: from iserv.intelsat.int(164.86.102.11) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016240; Thu, 10 Feb 00 18:45:37 -0500 Received: from kensington ([208.202.21.22]) by iserv.intelsat.int (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-49113U1000L2S100) with SMTP id AAA4589; Thu, 10 Feb 2000 18:45:32 -0500 From: "Robert Schellhase" To: "Shvodian, Bill" Cc: Subject: RE: nt to nt tcpsat problems Date: Thu, 10 Feb 2000 18:45:35 -0500 Message-ID: <000601bf7420$ed4c4f80$1615cad0@kensington> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Bill, Thanks for the archive reference. I had not read it. My own observation using a protocol analyzer was that the window size stays at 8 kB. Some other folks here also tried it with the same result. When making changes to the registry, it is necessary to reboot in order for them to take effect, so I did this. I'm not sure what the Path MTU discovery and black hole detect keys have to do with the TCP window size, but I did not tamper with these. The link on Christophe's message to MSDN no longer works, and the current MSDN documentation doesn't mention the need to set these keys in the TcpWindowSize context. Perhaps these two keys were what I was missing, or it is entirely possible that I made some other more fundamental mistake. I would be more than happy to hear from someone who has sucessfully gotten this to work. Robert -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Shvodian, Bill Sent: Thursday, February 10, 2000 5:38 PM To: 'Robert Schellhase' Cc: tcpsat@grc.nasa.gov Subject: RE: nt to nt tcpsat problems Robert, When you say "it has no effect" do you mean that the window stays at the default 8 kB? Has this been reported anywhere? I have read that the machine needs to be re-booted before it takes effect. Here is a tcpsat post from someone named Christophe Orlhac and he doesn't mention a problem: http://tcpsat.grc.nasa.gov/list/archive/0588.html I am interested if you have any more information. Thanks. Bill Shvodian > -----Original Message----- > From: Robert Schellhase [SMTP:robert.schellhase@intelsat.int] > Sent: Thursday, February 10, 2000 2:18 PM > To: gstreet@vninet.com > Cc: tcpsat@grc.nasa.gov > Subject: RE: nt to nt tcpsat problems > > Hi Graham, > I see you have found that Windows supports a registry key for > TcpWindowSize. > The sad news is that it has no effect, in spite of the fact that Microsoft > has a white paper on its own TCP implementation that claims otherwise. > > You might try the NetManage OnNet kernel for Windows 95/98 at > http://www.netmanage.com/products/onnetkernel4/index.asp > > I don't know what they charge for it, but I think it's affordable and they > offer a free demo. > > Best regards, > Robert Schellhase > Senior Engineer > INTELSAT > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Graham Street > Sent: Thursday, February 10, 2000 9:04 AM > To: tcpsat@grc.nasa.gov > Subject: nt to nt tcpsat problems > > > Hi all, > > We're trying to run windows file sharing protocols over a tcp sat link > and getting miserable performance, even after setting TcpWindowSize to > 65536. We can get about 100-250k max. We are trying to get at least > one megabit out of it. Is this even possible? We can get 1-2 megabits > ftping from a sun box over satellite... > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > translating > to udp?) > > Thanks, > Graham Street > gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Thu Feb 10 19:38: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 TAA13483; Thu, 10 Feb 2000 19:38:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA22575 for tcpsat-outgoing; Thu, 10 Feb 2000 17:38:42 -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 RAA22547 for ; Thu, 10 Feb 2000 17:38:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA02685; Thu, 10 Feb 2000 17:38:39 -0500 (EST) Received: from mailgw2a.lmco.com(192.91.147.7) by seraph3.lerc.nasa.gov via smap (V5.0) id xma002649; Thu, 10 Feb 00 17:38:26 -0500 Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id RAA07600; Thu, 10 Feb 2000 17:38:25 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <0FPQ00901K6JGW@lmco.com>; Thu, 10 Feb 2000 17:37:31 -0500 (EST) Received: from emss09m01.ems.lmco.com ([158.183.24.5]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <0FPQ001IOK6HLW@lmco.com>; Thu, 10 Feb 2000 17:37:30 -0500 (EST) Received: by emss09m01.ems.lmco.com with Internet Mail Service (5.5.2580.0) id <1KLZ1Q4X>; Thu, 10 Feb 2000 18:41:54 -0500 Content-return: allowed Date: Thu, 10 Feb 2000 17:37:48 -0500 From: "Shvodian, Bill" Subject: RE: nt to nt tcpsat problems To: "'Robert Schellhase'" Cc: tcpsat@grc.nasa.gov Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2580.0) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT Robert, When you say "it has no effect" do you mean that the window stays at the default 8 kB? Has this been reported anywhere? I have read that the machine needs to be re-booted before it takes effect. Here is a tcpsat post from someone named Christophe Orlhac and he doesn't mention a problem: http://tcpsat.grc.nasa.gov/list/archive/0588.html I am interested if you have any more information. Thanks. Bill Shvodian > -----Original Message----- > From: Robert Schellhase [SMTP:robert.schellhase@intelsat.int] > Sent: Thursday, February 10, 2000 2:18 PM > To: gstreet@vninet.com > Cc: tcpsat@grc.nasa.gov > Subject: RE: nt to nt tcpsat problems > > Hi Graham, > I see you have found that Windows supports a registry key for > TcpWindowSize. > The sad news is that it has no effect, in spite of the fact that Microsoft > has a white paper on its own TCP implementation that claims otherwise. > > You might try the NetManage OnNet kernel for Windows 95/98 at > http://www.netmanage.com/products/onnetkernel4/index.asp > > I don't know what they charge for it, but I think it's affordable and they > offer a free demo. > > Best regards, > Robert Schellhase > Senior Engineer > INTELSAT > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Graham Street > Sent: Thursday, February 10, 2000 9:04 AM > To: tcpsat@grc.nasa.gov > Subject: nt to nt tcpsat problems > > > Hi all, > > We're trying to run windows file sharing protocols over a tcp sat link > and getting miserable performance, even after setting TcpWindowSize to > 65536. We can get about 100-250k max. We are trying to get at least > one megabit out of it. Is this even possible? We can get 1-2 megabits > ftping from a sun box over satellite... > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > translating > to udp?) > > Thanks, > Graham Street > gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Thu Feb 10 19:58:55 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 TAA13603; Thu, 10 Feb 2000 19:58:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA03975 for tcpsat-outgoing; Thu, 10 Feb 2000 19:05:42 -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 TAA03944 for ; Thu, 10 Feb 2000 19:05:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA20274; Thu, 10 Feb 2000 19:05:40 -0500 (EST) Received: from new-frontier-consulting-745192.cust-rtr.swbell.net(151.164.200.70) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020153; Thu, 10 Feb 00 19:04:58 -0500 Received: from houpdc.newf.com (mail.newf.com [216.62.131.2]) by ns.newf.com (8.9.3/8.9.3) with ESMTP id SAA08636; Thu, 10 Feb 2000 18:04:54 -0600 Received: from heliox (216.190.71.51) by houpdc.newf.com (Worldmail 1.3.167); 10 Feb 2000 18:04:54 -0600 Reply-To: From: "Greg Otto" To: "'Robert Schellhase'" , Cc: Subject: RE: nt to nt tcpsat problems Date: Thu, 10 Feb 2000 18:04:20 -0600 Message-ID: <000001bf7423$8bee7080$3347bed8@ottovation.com> 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <000001bf73fb$8f1de5b0$1615cad0@kensington> Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Gentlemen, I did a week long study on this exact problem and the simple answer is "YOU ARE OUT OF LUCK." I have a ticket open with MS on this problem as it is how the CIFS protocol works. CIFS will only negotiate a 4K transfer size when the latency and bandwidth are small (if you are very very ... lucky maybe upto 12K). Basically, in short your throughput will be about equal to 4K/RTT (excluding other various factors). Thus, window size only needs to be 4K for this. It is a higher layer problem!!! While I cannot give you a copy of my report, I do have a couple of graphs I can get to you. Greg -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Robert Schellhase Sent: Thursday, February 10, 2000 1:18 PM To: gstreet@vninet.com Cc: tcpsat@grc.nasa.gov Subject: RE: nt to nt tcpsat problems Hi Graham, I see you have found that Windows supports a registry key for TcpWindowSize. The sad news is that it has no effect, in spite of the fact that Microsoft has a white paper on its own TCP implementation that claims otherwise. You might try the NetManage OnNet kernel for Windows 95/98 at http://www.netmanage.com/products/onnetkernel4/index.asp I don't know what they charge for it, but I think it's affordable and they offer a free demo. Best regards, Robert Schellhase Senior Engineer INTELSAT -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Graham Street Sent: Thursday, February 10, 2000 9:04 AM To: tcpsat@grc.nasa.gov Subject: nt to nt tcpsat problems Hi all, We're trying to run windows file sharing protocols over a tcp sat link and getting miserable performance, even after setting TcpWindowSize to 65536. We can get about 100-250k max. We are trying to get at least one megabit out of it. Is this even possible? We can get 1-2 megabits ftping from a sun box over satellite... does anyone know of any clever (cheap) solutions (spoofing nacks?, translating to udp?) Thanks, Graham Street gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Thu Feb 10 20:57:33 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 UAA14127; Thu, 10 Feb 2000 20:57:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA08841 for tcpsat-outgoing; Thu, 10 Feb 2000 20:06:02 -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 UAA08834 for ; Thu, 10 Feb 2000 20:06:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA02001; Thu, 10 Feb 2000 20:06:00 -0500 (EST) Received: from unknown(199.203.106.24) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001136; Thu, 10 Feb 00 20:04:15 -0500 Received: from pentium (194.133.185.237 [194.133.185.237]) by mail.gilat.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D1M55MA9; Fri, 11 Feb 2000 02:58:30 +0200 Message-ID: <004101bf742b$a60b2ff0$2a051eac@gilat.com> From: "Noam Gonnen - Israel" To: "Robert Schellhase" , Cc: References: <000001bf73fb$8f1de5b0$1615cad0@kensington> Subject: Re: nt to nt tcpsat problems Date: Fri, 11 Feb 2000 03:02:06 +0200 Organization: Gilat Satellite Networks LTD. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Graham, 1) regarding the IPstack and services white paper from MS, for what ever it's worth (concidering what Robert has said), you can find the NT versions (3.51->5) on http://vipe.technion.ac.il/~noamg , including all relevant Reg.Keys etc. 2) You may also want to check with : 2.1) Flash Networks (prod=SatBooster) on http://www.flash-networks.com/, application level spoofing (proxy) 2.2) Fourelle (prod.=Venturi) , uses similar principal, on http://www.fourelle.com/ Sincerely, Noam Gonnen Gilat Satellite Networks LTD. (http://www.gilat.com) Email: noamg@gilat.com Email2: noamg@vipe.technion.ac.il ----- Original Message ----- From: Robert Schellhase To: Cc: Sent: Thursday, February 10, 2000 9:18 PM Subject: RE: nt to nt tcpsat problems > Hi Graham, > I see you have found that Windows supports a registry key for TcpWindowSize. > The sad news is that it has no effect, in spite of the fact that Microsoft > has a white paper on its own TCP implementation that claims otherwise. > > You might try the NetManage OnNet kernel for Windows 95/98 at > http://www.netmanage.com/products/onnetkernel4/index.asp > > I don't know what they charge for it, but I think it's affordable and they > offer a free demo. > > Best regards, > Robert Schellhase > Senior Engineer > INTELSAT > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Graham Street > Sent: Thursday, February 10, 2000 9:04 AM > To: tcpsat@grc.nasa.gov > Subject: nt to nt tcpsat problems > > > Hi all, > > We're trying to run windows file sharing protocols over a tcp sat link > and getting miserable performance, even after setting TcpWindowSize to > 65536. We can get about 100-250k max. We are trying to get at least > one megabit out of it. Is this even possible? We can get 1-2 megabits > ftping from a sun box over satellite... > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > translating > to udp?) > > Thanks, > Graham Street > gstreet@vninet.com > From owner-tcpsat@lerc.nasa.gov Fri Feb 11 07:36: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 HAA05719; Fri, 11 Feb 2000 07:36:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA09671 for tcpsat-outgoing; Fri, 11 Feb 2000 06:20:12 -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 GAA09655 for ; Fri, 11 Feb 2000 06:20:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA13570; Fri, 11 Feb 2000 06:20:10 -0500 (EST) Received: from ntvicrj07.victori.com.br(200.225.23.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013484; Fri, 11 Feb 00 06:19:47 -0500 Received: by ntvicrj07.victori.com.br with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Feb 2000 09:23:11 -0300 Message-ID: <3104310CE765D211A66E00104B87219F562BE9@ntvicrj07.victori.com.br> From: Marcelo Reis To: "'gstreet@vninet.com'" , tcpsat@grc.nasa.gov Subject: RES: nt to nt tcpsat problems Date: Fri, 11 Feb 2000 09:23:10 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Hi Graham, For winsock applications you need also to set two more variables: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\DefaultR eceiveWindow HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\DefaultS endWindow Both of type REG_DWORD. I don't know if it applies to you, but NT4 SP5 has a math error in its tcp stack that causes the retransmit timer to be incorrectly computed, leading to unnecessary retransmissions. There is a new tcpip.sys file that fixes that bug. If you need this file and also the MS bug report regarding this, please let me know. Regards, Marcelo M. Reis marcelor@vicom.com.br > ----- Mensagem original ----- > De: Graham Street [SMTP:gstreet@oscar.penguinpowered.com] > Enviada em: Quinta-feira, 10 de Fevereiro de 2000 11:04 > Para: tcpsat@grc.nasa.gov > Assunto: nt to nt tcpsat problems > > Hi all, > > We're trying to run windows file sharing protocols over a tcp sat link > and getting miserable performance, even after setting TcpWindowSize to > 65536. We can get about 100-250k max. We are trying to get at least > one megabit out of it. Is this even possible? We can get 1-2 megabits > ftping from a sun box over satellite... > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > translating > to udp?) > > Thanks, > Graham Street > gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Fri Feb 11 09:27:55 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 JAA09630; Fri, 11 Feb 2000 09:27:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA19841 for tcpsat-outgoing; Fri, 11 Feb 2000 08:27:28 -0500 (EST) 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 IAA19354; Fri, 11 Feb 2000 08:23:25 -0500 (EST) Message-Id: <200002111323.IAA19354@lombok-fi.lerc.nasa.gov> To: David Godwin From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'gstreet@vninet.com'" , tcpsat@grc.nasa.gov Subject: Re: nt to nt tcpsat problems Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Ramble On Date: Fri, 11 Feb 2000 08:23:25 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > Sounds like you might want to try XFTP (see > http://roland.grc.nasa.gov/~mallman/papers/wosbis.ps). Also, > there are some interesting papers at > http://tcpsat.lerc.nasa.gov/tcpsat/papers.html. Actually, xftp is the *wrong* thing to use. XFTP was an experiment. It is inappropriate for use on shared networks, as its congestion response is not similar to that used by TCP (it ends up being N times more aggressive because you are using N connections). See the following paper for a discussion about why using multiple flows is not appropriate from a congestion control perspective... Floyd, S., and Fall, K., Promoting the Use of End-to-End Congestion Control in the Internet, IEEE/ACM Transactions on Networking, August 1999. http://www.aciri.org/floyd/end2end-paper.html allman --- http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@lerc.nasa.gov Fri Feb 11 09:56:01 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 JAA10506; Fri, 11 Feb 2000 09:55:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA24173 for tcpsat-outgoing; Fri, 11 Feb 2000 08:58:31 -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 IAA24143 for ; Fri, 11 Feb 2000 08:58:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA11615; Fri, 11 Feb 2000 08:58:26 -0500 (EST) Received: from qhars002.nortelnetworks.com(192.100.101.19) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011425; Fri, 11 Feb 00 08:57:47 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Fri, 11 Feb 2000 13:53:49 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <1H5QVC54>; Fri, 11 Feb 2000 13:53:48 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050DB2@zhard000.europe.nortel.com> From: "Julien Godard" To: "'gstreet@vninet.com'" , tcpsat@grc.nasa.gov Subject: RE: nt to nt tcpsat problems Date: Fri, 11 Feb 2000 13:53:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7497.6A52ACB0" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7497.6A52ACB0 Content-Type: text/plain a very usefull webpage : http://www.psc.edu/networking/perf_tune.html You will found all the tips to change the parameters needed for TCP over sat for various operating systems. Cheers Julien Godard System Engineer, Broadband Satellite Networks Nortel Networks London Road Harlow, Essex, CM17 9NA United Kingdom Email : jgodard@nortelnetworks.com Phone : +44 (0) 1279 403769 ESN : 742 3769 Fax : +44 (0) 1279 402400 Company name: Nortel Networks plc Company number: 2515751 Company's registered office address: Maidenhead Office Park, Westacott Way, Maidenhead, Berkshire SL6 3QH. > -----Original Message----- > From: Graham Street [SMTP:gstreet@oscar.penguinpowered.com] > Sent: Thursday, February 10, 2000 2:04 PM > To: tcpsat@grc.nasa.gov > Subject: nt to nt tcpsat problems > > Hi all, > > We're trying to run windows file sharing protocols over a tcp sat link > and getting miserable performance, even after setting TcpWindowSize to > 65536. We can get about 100-250k max. We are trying to get at least > one megabit out of it. Is this even possible? We can get 1-2 megabits > ftping from a sun box over satellite... > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > translating > to udp?) > > Thanks, > Graham Street > gstreet@vninet.com ------_=_NextPart_001_01BF7497.6A52ACB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: nt to nt tcpsat problems

a very usefull = webpage : http://www.psc.edu/networking/perf_tune.html

You will found all = the tips to change the parameters needed for TCP over sat for various = operating systems.

Cheers
Julien = Godard
System Engineer, Broadband = Satellite Networks

Nortel Networks
London Road
Harlow, Essex, CM17 = 9NA
United Kingdom

Email :  = jgodard@nortelnetworks.com
Phone : +44 (0) 1279 = 403769
        ESN : 742 3769
Fax = :     +44 (0) 1279 402400

Company name: Nortel Networks = plc
Company number: 2515751
Company's registered office address: = Maidenhead Office Park,
Westacott Way, Maidenhead, Berkshire = SL6 3QH.



    -----Original Message-----
    From:   Graham Street = [SMTP:gstreet@oscar.penguinpowered.com]
    Sent:   Thursday, February 10, 2000 2:04 PM
    To:     tcpsat@grc.nasa.gov
    Subject:       = nt to nt tcpsat problems

    Hi all,

    We're trying to run windows file = sharing protocols over a tcp sat link
    and getting miserable performance, = even after setting TcpWindowSize to
    65536.   We can get about = 100-250k max.  We are trying to get at least
    one megabit out of it.  Is this = even possible?  We can get 1-2 megabits
    ftping from a sun box over = satellite...

    does anyone know of any clever (cheap) = solutions  (spoofing nacks?, translating
    to udp?)

    Thanks,
    Graham Street
    gstreet@vninet.com

------_=_NextPart_001_01BF7497.6A52ACB0-- From owner-tcpsat@lerc.nasa.gov Fri Feb 11 11:05:06 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 LAA12686; Fri, 11 Feb 2000 11:04:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA06694 for tcpsat-outgoing; Fri, 11 Feb 2000 10:15:31 -0500 (EST) 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 KAA06690 for ; Fri, 11 Feb 2000 10:15:30 -0500 (EST) Message-Id: <200002111515.KAA06690@lombok-fi.lerc.nasa.gov> To: tcpsat@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: The IESG: WG Action: TCP Over Satellite (tcpsat) to conclude Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Ramble On Date: Fri, 11 Feb 2000 10:15:30 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I have recieved a number of questions about the status of the tcpsat mailing list now that the WG has gone dormant. We intend to leave the mailing list, archive and web page up and running. Please feel free to continue using them as you have been. allman --- http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@lerc.nasa.gov Fri Feb 11 11:18:47 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 LAA13003; Fri, 11 Feb 2000 11:18:37 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA08620 for tcpsat-outgoing; Fri, 11 Feb 2000 10:27:09 -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 KAA08573 for ; Fri, 11 Feb 2000 10:27:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA00297; Fri, 11 Feb 2000 10:27:06 -0500 (EST) Received: from store.metrodata.co.uk(194.154.181.2) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000112; Fri, 11 Feb 00 10:26:40 -0500 Received: from poppadom (store.metrodata.co.uk [194.154.181.2]) by store.metrodata.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1XDD60ZY; Fri, 11 Feb 2000 15:26:29 -0000 Message-ID: <012701bf74a4$222b8800$47fe72c1@poppadom> Reply-To: "Mike Holdsworth" From: "Mike Holdsworth" To: Subject: Asymmetric Satellite Links - Terrestrial Extension Date: Fri, 11 Feb 2000 15:24:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, Just been speccing some kit of ours for extending Asymmetric Satellite connections. I'm not sure of the terminology to use in an Application Note i am putting together and was hoping maybe someone could help me. I am more knowledgable about the Data side of things than Satellite and apologise in advance for being doh!!! It is friday after all and I have had only 1 coffee today. Basically we are taking either HSSI or BNC from the Satellite Modulator/Demodulator and plugging it into our kit. We then transport the traffic across a leased line, submarine cable, wireless or Dark Fibre. At the far end we connect into a HSSI Interface on a router (or ATM Switch depending on network topology). This is mainly for IP over Satellite 8Mbits transmit 34Mbits receive, etc. What is the correct terminology for:- (a) When you would use this to connect from a New York Internet Node to London via submarine cable and then have an uplink from London Earthstation to African Earthstation. (b) When you have a Satellite Link from London Earthstation to African Earthstation with Leased Line from African Earthstation across a town to Customer Site. Hope everyone has a great weekend. Mike ~~~~ Mike Holdsworth - WAN Applications Engineer, Metrodata Ltd. Mailto: mike.holdsworth@metrodata.co.uk Tel: +44 (0)1784 744 815 Mob: +44 (0)7887 983 374 --------------------------------------------- http://www.metrodata.co.uk From owner-tcpsat@lerc.nasa.gov Fri Feb 11 12:21:47 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 MAA15078; Fri, 11 Feb 2000 12:21:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA19178 for tcpsat-outgoing; Fri, 11 Feb 2000 11:29:33 -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 LAA19145; Fri, 11 Feb 2000 11:29:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA13612; Fri, 11 Feb 2000 11:29:28 -0500 (EST) Received: from palrel1.hp.com(156.153.255.242) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013556; Fri, 11 Feb 00 11:28:56 -0500 Received: from tpantmail1.ssr.hp.com (tpantmail1.ssr.hp.com [15.19.244.37]) by palrel1.hp.com (Postfix) with ESMTP id D12E2710; Fri, 11 Feb 2000 08:28:52 -0800 (PST) Received: by tpantmail1.ssr.hp.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Feb 2000 11:28:55 -0500 Message-ID: <472E220BA79DD11186340060B06B38D9029A44AE@tpantmail1.ssr.hp.com> From: David Godwin To: "'mallman@grc.nasa.gov'" Cc: "'gstreet@vninet.com'" , tcpsat@grc.nasa.gov Subject: RE: nt to nt tcpsat problems Date: Fri, 11 Feb 2000 11:28:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Hi Mark, Sorry for muddying the waters with my comment regarding XFTP. In my reply, I made the assumption that Graham was using a (momentary) point-to-point connection on a private VSAT network. That is the scenario that is used by most of systems with which I am familiar. Also, I should have made it clear that I have no real experience with the technique described in the XFTP paper... just that I was very impressed that you had found an application-level workaround for an underlying protocol problem. I can certainly understand how the approach could lead to excessive congestion. Thank you for the interesting reference to the Floyd and Fall paper. Best regards, David Godwin Petroleum/C-Store Development Engineer VeriFone, a division of Hewlett-Packard Office: (727) 953-4072 Fax: (727) 953-4001 http://www.verifone.hp.com Mailto:David_Godwin@HP.com > -----Original Message----- > From: Mark Allman [SMTP:mallman@grc.nasa.gov] > Sent: Friday, February 11, 2000 8:23 AM > To: David Godwin > Cc: 'gstreet@vninet.com'; tcpsat@grc.nasa.gov > Subject: Re: nt to nt tcpsat problems > > > > Sounds like you might want to try XFTP (see > > http://roland.grc.nasa.gov/~mallman/papers/wosbis.ps). Also, > > there are some interesting papers at > > http://tcpsat.lerc.nasa.gov/tcpsat/papers.html. > > Actually, xftp is the *wrong* thing to use. XFTP was an > experiment. It is inappropriate for use on shared networks, as its > congestion response is not similar to that used by TCP (it ends up > being N times more aggressive because you are using N connections). > See the following paper for a discussion about why using multiple > flows is not appropriate from a congestion control perspective... > > > Floyd, S., and Fall, K., Promoting the Use of End-to-End > Congestion Control in the Internet, IEEE/ACM Transactions on > Networking, August 1999. > http://www.aciri.org/floyd/end2end-paper.html > > allman > > > --- > http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@lerc.nasa.gov Fri Feb 11 13:21: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 NAA16384; Fri, 11 Feb 2000 13:21:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA27970 for tcpsat-outgoing; Fri, 11 Feb 2000 12:29:39 -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 MAA27945 for ; Fri, 11 Feb 2000 12:29:35 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA25954; Fri, 11 Feb 2000 12:29:34 -0500 (EST) Received: from mayday.interpacket.net(209.198.223.250) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025918; Fri, 11 Feb 00 12:28:58 -0500 Received: (qmail 3885 invoked from network); 11 Feb 2000 17:28:57 -0000 Received: from we-24-130-21-170.we.mediaone.net (HELO ?192.168.0.6?) (24.130.21.170) by bond.interpacket.net with SMTP; 11 Feb 2000 17:28:57 -0000 Mime-Version: 1.0 X-Sender: jonm@bond.interpacket.net Message-Id: In-Reply-To: <012701bf74a4$222b8800$47fe72c1@poppadom> References: <012701bf74a4$222b8800$47fe72c1@poppadom> Date: Fri, 11 Feb 2000 09:28:43 -0800 To: "Mike Holdsworth" From: Jon Mansey Subject: Re: Asymmetric Satellite Links - Terrestrial Extension Cc: tcpsat@grc.nasa.gov Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Mike, The generic terms for both these cases is hybrid fiber/satellite circuits or hybrid fiber/cable or HFC. As an aside, does your customer have service already or is he looking for a service provider. We are the worlds largest satellite IP delivery service and can offer high speed service all over Africa from our uplinks in New York or London. Let me know if we can be of any assistance. Jon. >Hello All, > >Just been speccing some kit of ours for extending Asymmetric Satellite >connections. I'm not sure of the terminology to use in an Application Note i >am putting together and was hoping maybe someone could help me. I am more >knowledgable about the Data side of things than Satellite and apologise in >advance for being doh!!! It is friday after all and I have had only 1 coffee >today. > >Basically we are taking either HSSI or BNC from the Satellite >Modulator/Demodulator and plugging it into our kit. We then transport the >traffic across a leased line, submarine cable, wireless or Dark Fibre. At >the far end we connect into a HSSI Interface on a router (or ATM Switch >depending on network topology). This is mainly for IP over Satellite 8Mbits >transmit 34Mbits receive, etc. > >What is the correct terminology for:- > >(a) When you would use this to connect from a New York Internet Node to >London via submarine cable and then have an uplink from London Earthstation >to African Earthstation. > >(b) When you have a Satellite Link from London Earthstation to African >Earthstation with Leased Line from African Earthstation across a town to >Customer Site. > >Hope everyone has a great weekend. > >Mike >~~~~ >Mike Holdsworth - WAN Applications Engineer, Metrodata Ltd. >Mailto: mike.holdsworth@metrodata.co.uk >Tel: +44 (0)1784 744 815 >Mob: +44 (0)7887 983 374 >--------------------------------------------- >http://www.metrodata.co.uk jon@interpacket.net Chief Science Officer ------------------------------------------------------------------ "Low-cost & high-speed access to the US Internet via Satellite" InterPacket Group, Inc. http://www.interpacket.net 1901 Main St. tel (310) 382 3300 Santa Monica, California 90405 fax (310) 382 3310 ------------------------------------------------------------------ "Unix IS user friendly...It's just selective about who its friends are." From owner-tcpsat@lerc.nasa.gov Mon Feb 14 15:55:16 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 PAA23705; Mon, 14 Feb 2000 15:55:15 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA29473 for tcpsat-outgoing; Mon, 14 Feb 2000 14:51:35 -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 OAA29443 for ; Mon, 14 Feb 2000 14:51:31 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA29129; Mon, 14 Feb 2000 14:51:29 -0500 (EST) Received: from line31.comsat.net.ar(200.47.47.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma028954; Mon, 14 Feb 00 14:50:52 -0500 Received: from bued114a.siemens.com.ar (localhost [127.0.0.1]) by bued114a.siemens.com.ar with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 183QKC2B; Mon, 14 Feb 2000 16:51:36 -0300 Received: by buea103e.siemens.com.ar with Internet Mail Service (5.5.2650.21) id <1YMRZ99Y>; Mon, 14 Feb 2000 16:48:22 -0300 Message-ID: From: "Testasecca, Mariano" To: "'tcpsat@grc.nasa.gov'" Subject: Setting the appropiate MTU Date: Mon, 14 Feb 2000 16:48:35 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id OAA29458 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit What MTU value would be appropiate for Windows 95/98 terminals working as a Windows NT 4.0 running Citrix MetaFrame under a satellite link of a VSAT that provides 4kbps of bandwidth? Thanks to all. Mariano Testasecca SIEMENS S.A. División Electromedicina Servicios de Salud - SHS Bolivar 177 1º Piso *+54-11-4340-8400 int. 2796 * mailto:mariano.testasecca@siemens.com.ar From owner-tcpsat@lerc.nasa.gov Mon Feb 14 17:22: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 RAA25419; Mon, 14 Feb 2000 17:22:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA14598 for tcpsat-outgoing; Mon, 14 Feb 2000 16:27:56 -0500 (EST) 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 QAA14593 for ; Mon, 14 Feb 2000 16:27:55 -0500 (EST) Message-Id: <200002142127.QAA14593@lombok-fi.lerc.nasa.gov> To: tcpsat@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: test, please ignore Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Superunknown Date: Mon, 14 Feb 2000 16:27:55 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Just a test of the list archiver. Please ignore. From owner-tcpsat@lerc.nasa.gov Tue Feb 15 06:28:01 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 GAA21967; Tue, 15 Feb 2000 06:28:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA28322 for tcpsat-outgoing; Tue, 15 Feb 2000 05:01:36 -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 FAA28317 for ; Tue, 15 Feb 2000 05:01:35 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA19013; Tue, 15 Feb 2000 05:01:33 -0500 (EST) Received: from qhars001.nortelnetworks.com(192.100.101.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018977; Tue, 15 Feb 00 05:01:00 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars001.nortel.com; Tue, 15 Feb 2000 09:58:49 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <1956GKA8>; Tue, 15 Feb 2000 09:58:48 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050DC1@zhard000.europe.nortel.com> From: "Julien Godard" To: "'Testasecca, Mariano'" Cc: "'tcpsat@grc.nasa.gov'" Subject: RE: Setting the appropiate MTU Date: Tue, 15 Feb 2000 09:58:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF779B.400C5BF2" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF779B.400C5BF2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable for performance, the bigger the better ! But it may depend also on your network because you may want to avoid fragmentation. You can test your MTU with some free tools such as easyMTU http://members.tripod.com/~EasyMTU/ For example if you use ethernet link, the MTU is 1500, leading to 1448 = bytes of data in each segment (20 IP + 20 TCP + 12 TCP timestamp option + = 1448 data). If your router support this size without fragmentation, it's = fine ! > -----Original Message----- > From: Testasecca, Mariano [SMTP:Mariano.Testasecca@siemens.com.ar] > Sent: Monday, February 14, 2000 7:49 PM > To: 'tcpsat@grc.nasa.gov' > Subject: Setting the appropiate MTU >=20 >=20 > What MTU value would be appropiate for Windows 95/98 terminals = working as > a > Windows NT 4.0 running Citrix MetaFrame under > a satellite link of a VSAT that provides 4kbps of bandwidth? >=20 > Thanks to all. >=20 > Mariano Testasecca > SIEMENS S.A. > Divisi=F3n Electromedicina > Servicios de Salud - SHS > Bolivar 177 1=BA Piso > *+54-11-4340-8400 int. 2796 > * mailto:mariano.testasecca@siemens.com.ar >=20 >=20 >=20 >=20 >=20 >=20 >=20 ------_=_NextPart_001_01BF779B.400C5BF2 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Setting the appropiate MTU

for performance, the = bigger the better !
But it may depend = also on your network because you may want to avoid = fragmentation.
You can test your = MTU with some free tools such as easyMTU http://members.tripod.com/~EasyMTU/
For example if you = use ethernet link, the MTU is 1500, leading to 1448 bytes of data in = each segment (20 IP + 20 TCP + 12 TCP timestamp option + 1448 data). If = your router support this size without fragmentation, it's fine = !

    -----Original Message-----
    From:   Testasecca, Mariano = [SMTP:Mariano.Testasecca@siemens.com.ar]
    Sent:   Monday, February 14, 2000 7:49 PM
    To:     'tcpsat@grc.nasa.gov'
    Subject:       = Setting the appropiate MTU


    What MTU value would be appropiate for = Windows 95/98 terminals working as a
    Windows NT 4.0 running Citrix = MetaFrame under
    a satellite link of a VSAT that = provides 4kbps of bandwidth?

    Thanks to all.

    Mariano Testasecca
    SIEMENS S.A.
    Divisi=F3n Electromedicina
    Servicios de Salud - SHS
    Bolivar 177 1=BA Piso
    *+54-11-4340-8400 int. 2796
    * mailto:mariano.testase= cca@siemens.com.ar







------_=_NextPart_001_01BF779B.400C5BF2-- From owner-tcpsat@lerc.nasa.gov Tue Feb 15 11:36:14 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 LAA12828; Tue, 15 Feb 2000 11:36:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA03489 for tcpsat-outgoing; Tue, 15 Feb 2000 10:39:18 -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 KAA03445 for ; Tue, 15 Feb 2000 10:39:13 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA22092; Tue, 15 Feb 2000 10:39:12 -0500 (EST) Received: from isnt.uscga.edu(138.29.1.252) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021960; Tue, 15 Feb 00 10:38:46 -0500 Received: by isnt.uscga.edu with Internet Mail Service (5.5.2448.0) id <1ZLLBN6R>; Tue, 15 Feb 2000 10:38:31 -0500 Message-ID: <79EFC6EC2A78D11191B400600892BC9FFD7719@isnt.uscga.edu> From: "Johnson, Gregory LCDR" To: Julien Godard , "'Testasecca, Mariano'" Cc: "'tcpsat@grc.nasa.gov'" Subject: RE: Setting the appropriate MTU Date: Tue, 15 Feb 2000 10:38:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id KAA03458 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Bigger is not better for slow networks. For a link speed of 4kbps you will need to use much smaller MTU sizes since the transmission time for a packet gets too long otherwise. It will also depend upon what the latency is in the link because the total transmission time for a packet is a function of the size and delay. For a typical GEO link, I would expect that you have anywhere up to 600ms depending upon what kind of FEC and interleaving is done on the link. I have found for Inmarsat-M/Mini-M type links (2.4 kbps) that an MTU size of 500 works well. You also need to adjust the initial RTO value larger (the default is 3 secs, try 5 secs). If you don't do this, you will suffer a lot of timeouts and retransmissions. I'm not that familiar with the protocol Citrix uses, but with only 4kbps of bandwidth, you also don't want to run multiple simultaneous connections across your link as one connection will probably saturate the link. -Greg LCDR Gregory W. Johnson Ass't Prof. Electrical Engineering USCG Academy New London CT 860-444-8683 -----Original Message----- From: Julien Godard [mailto:jgodard@nortelnetworks.com] Sent: Tuesday, February 15, 2000 4:59 AM To: 'Testasecca, Mariano' Cc: 'tcpsat@grc.nasa.gov' Subject: RE: Setting the appropiate MTU for performance, the bigger the better ! But it may depend also on your network because you may want to avoid fragmentation. You can test your MTU with some free tools such as easyMTU http://members.tripod.com/~EasyMTU/ For example if you use ethernet link, the MTU is 1500, leading to 1448 bytes of data in each segment (20 IP + 20 TCP + 12 TCP timestamp option + 1448 data). If your router support this size without fragmentation, it's fine ! -----Original Message----- From: Testasecca, Mariano [SMTP:Mariano.Testasecca@siemens.com.ar] Sent: Monday, February 14, 2000 7:49 PM To: 'tcpsat@grc.nasa.gov' Subject: Setting the appropiate MTU What MTU value would be appropiate for Windows 95/98 terminals working as a Windows NT 4.0 running Citrix MetaFrame under a satellite link of a VSAT that provides 4kbps of bandwidth? Thanks to all. Mariano Testasecca SIEMENS S.A. División Electromedicina Servicios de Salud - SHS Bolivar 177 1º Piso *+54-11-4340-8400 int. 2796 * mailto:mariano.testasecca@siemens.com.ar From owner-tcpsat@lerc.nasa.gov Tue Feb 15 11:43:55 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 LAA13123; Tue, 15 Feb 2000 11:43:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA06669 for tcpsat-outgoing; Tue, 15 Feb 2000 10:56:33 -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 KAA06642 for ; Tue, 15 Feb 2000 10:56:30 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA24742; Tue, 15 Feb 2000 10:56:28 -0500 (EST) Received: from qhars002.nortelnetworks.com(192.100.101.19) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024708; Tue, 15 Feb 00 10:56:19 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Tue, 15 Feb 2000 15:53:39 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <1956G5MY>; Tue, 15 Feb 2000 15:53:37 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050DC9@zhard000.europe.nortel.com> From: "Julien Godard" To: "'Johnson, Gregory LCDR'" , "'Testasecca, Mariano'" Cc: "'tcpsat@grc.nasa.gov'" Subject: RE: Setting the appropriate MTU Date: Tue, 15 Feb 2000 15:53:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF77CC.D0FBAB32" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF77CC.D0FBAB32 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Oups ! Yes, correct ! I completelly forgot to look at the bandwidth. I am too use to run test = with x Mbps... > -----Original Message----- > From: Johnson, Gregory LCDR [SMTP:GJohnson@EXMAIL.USCGA.EDU] > Sent: Tuesday, February 15, 2000 3:39 PM > To: Godard, Julien [HAL02:HM90:EXCH]; 'Testasecca, Mariano' > Cc: 'tcpsat@grc.nasa.gov' > Subject: RE: Setting the appropriate MTU >=20 > Bigger is not better for slow networks. For a link speed of 4kbps you = will > need to use much smaller MTU sizes since the transmission time for a > packet > gets too long otherwise. It will also depend upon what the latency is = in > the > link because the total transmission time for a packet is a function = of the > size and delay. For a typical GEO link, I would expect that you have > anywhere up to 600ms depending upon what kind of FEC and interleaving = is > done on the link. I have found for Inmarsat-M/Mini-M type links (2.4 = kbps) > that an MTU size of 500 works well. You also need to adjust the = initial > RTO > value larger (the default is 3 secs, try 5 secs). If you don't do = this, > you > will suffer a lot of timeouts and retransmissions. I'm not that = familiar > with the protocol Citrix uses, but with only 4kbps of bandwidth, you = also > don't want to run multiple simultaneous connections across your link = as > one > connection will probably saturate the link. > =20 >=20 > -Greg=20 >=20 > LCDR Gregory W. Johnson=20 > Ass't Prof. Electrical Engineering=20 >=20 > USCG Academy=20 > New London CT=20 >=20 > 860-444-8683=20 >=20 > -----Original Message----- > From: Julien Godard [mailto:jgodard@nortelnetworks.com] > Sent: Tuesday, February 15, 2000 4:59 AM > To: 'Testasecca, Mariano' > Cc: 'tcpsat@grc.nasa.gov' > Subject: RE: Setting the appropiate MTU >=20 >=20 >=20 > for performance, the bigger the better !=20 > But it may depend also on your network because you may want to avoid > fragmentation.=20 > You can test your MTU with some free tools such as easyMTU > http://members.tripod.com/~EasyMTU/ = >=20 > For example if you use ethernet link, the MTU is 1500, leading to = 1448 > bytes > of data in each segment (20 IP + 20 TCP + 12 TCP timestamp option + = 1448 > data). If your router support this size without fragmentation, it's = fine ! >=20 > -----Original Message-----=20 > From: Testasecca, Mariano [SMTP:Mariano.Testasecca@siemens.com.ar]=20 > Sent: Monday, February 14, 2000 7:49 PM=20 > To: 'tcpsat@grc.nasa.gov'=20 > Subject: Setting the appropiate MTU=20 >=20 >=20 > What MTU value would be appropiate for Windows 95/98 terminals > working as a=20 > Windows NT 4.0 running Citrix MetaFrame under=20 > a satellite link of a VSAT that provides 4kbps of bandwidth?=20 >=20 > Thanks to all.=20 >=20 > Mariano Testasecca=20 > SIEMENS S.A.=20 > Divisi=F3n Electromedicina=20 > Servicios de Salud - SHS=20 > Bolivar 177 1=BA Piso=20 > *+54-11-4340-8400 int. 2796=20 > * mailto:mariano.testasecca@siemens.com.ar > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 ------_=_NextPart_001_01BF77CC.D0FBAB32 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Setting the appropriate MTU

Oups ! Yes, correct = !
I completelly = forgot to look at the bandwidth. I am too use to run test with x = Mbps...

    -----Original Message-----
    From:   Johnson, Gregory LCDR = [SMTP:GJohnson@EXMAIL.USCGA.EDU]
    Sent:   Tuesday, February 15, 2000 3:39 PM
    To:     Godard, Julien [HAL02:HM90:EXCH]; 'Testasecca, = Mariano'
    Cc:     'tcpsat@grc.nasa.gov'
    Subject:       = RE: Setting the appropriate = MTU

    Bigger is not better for slow = networks. For a link speed of 4kbps you will
    need to use much smaller MTU sizes = since the transmission time for a packet
    gets too long otherwise. It will also = depend upon what the latency is in the
    link because the total transmission = time for a packet is a function of the
    size and delay. For a typical GEO = link, I would expect that you have
    anywhere up to 600ms depending upon = what kind of FEC and interleaving is
    done on the link. I have found for = Inmarsat-M/Mini-M type links (2.4 kbps)
    that an MTU size of 500 works well. = You also need to adjust the initial RTO
    value larger (the default is 3 secs, = try 5 secs). If you don't do this, you
    will suffer a lot of timeouts and = retransmissions. I'm not that familiar
    with the protocol Citrix uses, but = with only 4kbps of bandwidth, you also
    don't want to run multiple = simultaneous connections across your link as one
    connection will probably saturate the = link.
     

    -Greg

    LCDR Gregory W. Johnson
    Ass't Prof. Electrical Engineering =

    USCG Academy
    New London CT

    860-444-8683

    -----Original Message-----
    From: Julien Godard = [mailto:jgodard@nortelnetworks= .com]
    Sent: Tuesday, February 15, 2000 4:59 = AM
    To: 'Testasecca, Mariano'
    Cc: 'tcpsat@grc.nasa.gov'
    Subject: RE: Setting the appropiate = MTU



    for performance, the bigger the better = !
    But it may depend also on your = network because you may want to avoid
    fragmentation.
    You can test your MTU with some free = tools such as easyMTU
    http://members.tripod.com/~EasyMTU/ <    http://members.tripod.com/~EasyMTU/> 
    For example if you use ethernet link, = the MTU is 1500, leading to 1448 bytes
    of data in each segment (20 IP + 20 = TCP + 12 TCP timestamp option + 1448
    data). If your router support this = size without fragmentation, it's fine !

            -----Original Message-----
    From:   Testasecca, Mariano = [SMTP:Mariano.Testasecca@siemens.com.ar]
    Sent:   Monday, February = 14, 2000 7:49 PM
    To:     = 'tcpsat@grc.nasa.gov'
    Subject:        = Setting the appropiate MTU


            What MTU value would be appropiate for Windows 95/98 = terminals
    working as a
    Windows NT 4.0 running Citrix = MetaFrame under
    a satellite link of a VSAT that = provides 4kbps of bandwidth?

            Thanks to all.

            Mariano Testasecca
    SIEMENS S.A.
    Divisi=F3n Electromedicina
    Servicios de Salud - SHS
    Bolivar 177 1=BA Piso
    *+54-11-4340-8400 int. 2796
    * mailto:mariano.testase= cca@siemens.com.ar
    <mailto:mariano.testase= cca@siemens.com.ar> 







------_=_NextPart_001_01BF77CC.D0FBAB32-- From owner-tcpsat@lerc.nasa.gov Tue Feb 15 16:36: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 QAA23724; Tue, 15 Feb 2000 16:36:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA18212 for tcpsat-outgoing; Tue, 15 Feb 2000 15:19:09 -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 PAA18171 for ; Tue, 15 Feb 2000 15:19:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA03937; Tue, 15 Feb 2000 15:19:04 -0500 (EST) Received: from unknown-147-100.pilot.net(198.232.147.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003874; Tue, 15 Feb 00 15:18:29 -0500 Received: from unknown-24-4.pilot.net (unknown-24-4.pilot.net [206.189.24.4]) by unknown-147-100.pilot.net with ESMTP id MAA23012 for ; Tue, 15 Feb 2000 12:18:25 -0800 (PST) Received: from crdns.crd.ge.com (localhost [127.0.0.1]) by unknown-24-4.pilot.net with ESMTP id MAA24346 for ; Tue, 15 Feb 2000 12:18:23 -0800 (PST) Received: from exc01crdge.crd.ge.com (crdmsx01.crd.ge.com [3.1.116.47]) by crdns.crd.ge.com (8.9.3/8.9.3) with ESMTP id PAA09933 for ; Tue, 15 Feb 2000 15:18:49 -0500 (EST) Received: by crdmsx01.crd.ge.com with Internet Mail Service (5.5.2448.0) id <1WSCL53H>; Tue, 15 Feb 2000 15:18:20 -0500 Message-ID: From: "Davenport, David M (CRD)" To: "'tcpsat@grc.nasa.gov'" Subject: RE: Setting the appropriate MTU Date: Tue, 15 Feb 2000 15:18:22 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Now you've added mobility to the equation... With Inmarsat-M/Mini-M and other low data-rate, mobile satellite services an appropriate MTU selection is driven primarily by the Rician/Rayleigh fading channel and the trade-off: Large data frames to increase throughput efficiency - vs. - Small data frames to reduce required retransmission due to fading/shadowing For fixed site satellite with BER < 10^(-5), I'd suggest IP fragmentation along the entire route dominates MTU selection...and the bigger the better. David M. Davenport GE Corporate Research and Development One Research Circle, M/S KWC421 Niskayuna, NY 12309 Phone/Fax: (518) 387-5041/4042 ***** Opinions contained herein are my own and not necessarily those of my employer ***** -----Original Message----- From: Johnson, Gregory LCDR [mailto:GJohnson@EXMAIL.USCGA.EDU] Sent: Tuesday, February 15, 2000 10:39 AM To: Julien Godard; 'Testasecca, Mariano' Cc: 'tcpsat@grc.nasa.gov' Subject: RE: Setting the appropriate MTU Bigger is not better for slow networks. For a link speed of 4kbps you will need to use much smaller MTU sizes since the transmission time for a packet gets too long otherwise. It will also depend upon what the latency is in the link because the total transmission time for a packet is a function of the size and delay. For a typical GEO link, I would expect that you have anywhere up to 600ms depending upon what kind of FEC and interleaving is done on the link. I have found for Inmarsat-M/Mini-M type links (2.4 kbps) that an MTU size of 500 works well. You also need to adjust the initial RTO value larger (the default is 3 secs, try 5 secs). If you don't do this, you will suffer a lot of timeouts and retransmissions. I'm not that familiar with the protocol Citrix uses, but with only 4kbps of bandwidth, you also don't want to run multiple simultaneous connections across your link as one connection will probably saturate the link. -Greg LCDR Gregory W. Johnson Ass't Prof. Electrical Engineering USCG Academy New London CT 860-444-8683 -----Original Message----- From: Julien Godard [mailto:jgodard@nortelnetworks.com] Sent: Tuesday, February 15, 2000 4:59 AM To: 'Testasecca, Mariano' Cc: 'tcpsat@grc.nasa.gov' Subject: RE: Setting the appropiate MTU for performance, the bigger the better ! But it may depend also on your network because you may want to avoid fragmentation. You can test your MTU with some free tools such as easyMTU http://members.tripod.com/~EasyMTU/ For example if you use ethernet link, the MTU is 1500, leading to 1448 bytes of data in each segment (20 IP + 20 TCP + 12 TCP timestamp option + 1448 data). If your router support this size without fragmentation, it's fine ! -----Original Message----- From: Testasecca, Mariano [SMTP:Mariano.Testasecca@siemens.com.ar] Sent: Monday, February 14, 2000 7:49 PM To: 'tcpsat@grc.nasa.gov' Subject: Setting the appropiate MTU What MTU value would be appropiate for Windows 95/98 terminals working as a Windows NT 4.0 running Citrix MetaFrame under a satellite link of a VSAT that provides 4kbps of bandwidth? Thanks to all. Mariano Testasecca SIEMENS S.A. Division Electromedicina Servicios de Salud - SHS Bolivar 177 1o Piso *+54-11-4340-8400 int. 2796 * mailto:mariano.testasecca@siemens.com.ar From owner-tcpsat@lerc.nasa.gov Wed Feb 16 06:12:47 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 GAA22146; Wed, 16 Feb 2000 06:12:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA16290 for tcpsat-outgoing; Wed, 16 Feb 2000 05:15:44 -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 FAA16282 for ; Wed, 16 Feb 2000 05:15:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA23932; Wed, 16 Feb 2000 05:15:41 -0500 (EST) Received: from qhars002.nortelnetworks.com(192.100.101.19) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023922; Wed, 16 Feb 00 05:15:10 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 16 Feb 2000 10:13:39 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <1956H2T4>; Wed, 16 Feb 2000 10:13:38 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050DCC@zhard000.europe.nortel.com> From: "Julien Godard" To: "'Dave'" , "'Johnson, Gregory LCDR'" , "'Testasecca, Mariano'" Cc: "'tcpsat@grc.nasa.gov'" Subject: RE: Setting the appropriate MTU Date: Wed, 16 Feb 2000 10:13:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7866.7D6E0DA8" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7866.7D6E0DA8 Content-Type: text/plain; charset="ISO-8859-1" without joking, the correct answer is yes... In fact I run some tests for a fixed bandwidth (2 Mbps) and some over BoD (max of 384 K) with a link delay of 600ms. Due to TCP congestion avoidance behavior, in both case, the bigger MTU gives the best results. Of course, by increasing the MTU, you increase the RTT in the case of low rate (time needed to transmit the packet) or BoD (ressources required to transmit the packet). Thus you have to adapt your socket buffer size (and thus your max window) to the BDP with the "real RTT", and not only the link delay. In the case of Bod tests, my RTT was around 3-4s, which may be comparable with large MTU on a low rate link. At the beginning of the connection, the RTT is small, so you don't have problems with the RTO. When you reach a steady state, the RTT increase, but the RTO is adjusted. A good way to test the RTT during a connection without sophisticated tools is simply to run on the same link a simple ping and a TCP bulk transfer. With the ping you can get the real RTT, and then adjust your buffer size. Hope it's helpfull ! Cheers julien > -----Original Message----- > From: Dave [SMTP:dalyd@erols.com] > Sent: Wednesday, February 16, 2000 1:40 AM > To: Godard, Julien [HAL02:HM90:EXCH]; 'Johnson, Gregory LCDR'; > 'Testasecca, Mariano' > Subject: Re: Setting the appropriate MTU > > > RE: ..."x Mbps. . ." > Is that like Bandwidth-On-Demand? > ;) > > Cheers, > Dave sends > > ----- Original Message ----- > From: Julien Godard > To: 'Johnson, Gregory LCDR' ; > 'Testasecca, Mariano' > Cc: 'tcpsat@grc.nasa.gov' > Sent: Tuesday, February 15, 2000 10:53 AM > Subject: RE: Setting the appropriate MTU > > > Oups ! Yes, correct ! > I completelly forgot to look at the bandwidth. I am too use to run > test with x Mbps... > > -----Original Message----- > From: Johnson, Gregory LCDR [ SMTP:GJohnson@EXMAIL.USCGA.EDU > ] > Sent: Tuesday, February 15, 2000 3:39 PM > To: Godard, Julien [HAL02:HM90:EXCH]; 'Testasecca, Mariano' > Cc: 'tcpsat@grc.nasa.gov' > Subject: RE: Setting the appropriate MTU > > Bigger is not better for slow networks. For a link speed of > 4kbps you will > need to use much smaller MTU sizes since the transmission time for a > packet > gets too long otherwise. It will also depend upon what the latency > is in the > link because the total transmission time for a packet is a function > of the > size and delay. For a typical GEO link, I would expect that you have > > anywhere up to 600ms depending upon what kind of FEC and > interleaving is > done on the link. I have found for Inmarsat-M/Mini-M type links (2.4 > kbps) > that an MTU size of 500 works well. You also need to adjust the > initial RTO > value larger (the default is 3 secs, try 5 secs). If you don't do > this, you > will suffer a lot of timeouts and retransmissions. I'm not that > familiar > with the protocol Citrix uses, but with only 4kbps of bandwidth, you > also > don't want to run multiple simultaneous connections across your link > as one > connection will probably saturate the link. > > > -Greg > > LCDR Gregory W. Johnson > Ass't Prof. Electrical Engineering > > USCG Academy > New London CT > > 860-444-8683 > > -----Original Message----- > From: Julien Godard [ ] > Sent: Tuesday, February 15, 2000 4:59 AM > To: 'Testasecca, Mariano' > Cc: 'tcpsat@grc.nasa.gov' > Subject: RE: Setting the appropiate MTU > > > > for performance, the bigger the better ! > But it may depend also on your network because you may want to avoid > > fragmentation. > You can test your MTU with some free tools such as easyMTU > < > > > For example if you use ethernet link, the MTU is 1500, leading to > 1448 bytes > of data in each segment (20 IP + 20 TCP + 12 TCP timestamp option + > 1448 > data). If your router support this size without fragmentation, it's > fine ! > > -----Original Message----- > From: Testasecca, Mariano [SMTP:Mariano.Testasecca@siemens.com.ar] > > Sent: Monday, February 14, 2000 7:49 PM > To: 'tcpsat@grc.nasa.gov' > Subject: Setting the appropiate MTU > > > What MTU value would be appropiate for Windows 95/98 > terminals > working as a > Windows NT 4.0 running Citrix MetaFrame under > a satellite link of a VSAT that provides 4kbps of bandwidth? > > Thanks to all. > > Mariano Testasecca > SIEMENS S.A. > División Electromedicina > Servicios de Salud - SHS > Bolivar 177 1º Piso > *+54-11-4340-8400 int. 2796 > * > < > > > > > > > > ------_=_NextPart_001_01BF7866.7D6E0DA8 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Setting the appropriate MTU

without joking, the = correct answer is yes...

In fact I run some = tests for a fixed bandwidth (2 Mbps) and some over BoD (max of 384 K) = with a link delay of 600ms.
Due to TCP = congestion avoidance behavior, in both case, the bigger MTU gives the = best results.
Of course, by = increasing the MTU, you increase the RTT in the case of low rate (time = needed to transmit the packet) or BoD (ressources required to transmit = the packet). Thus you have to adapt your socket buffer size (and thus = your max window) to the BDP with the "real RTT", and not only = the link delay. In the case of Bod tests, my RTT was around 3-4s, which = may be comparable with large MTU on a low rate link. At the beginning = of the connection, the RTT is small, so you don't have problems with = the RTO. When you reach a steady state, the RTT increase, but the RTO = is adjusted.

A good way to test = the RTT during a connection without sophisticated tools is simply to = run on the same link a simple ping and a TCP bulk transfer. With the = ping you can get the real RTT, and then adjust your buffer = size.

Hope it's helpfull = !

Cheers
julien

    -----Original Message-----
    From:   Dave [SMTP:dalyd@erols.com]
    Sent:   Wednesday, February 16, 2000 1:40 AM
    To:     Godard, Julien [HAL02:HM90:EXCH]; 'Johnson, Gregory = LCDR'; 'Testasecca, Mariano'
    Subject:       = Re: Setting the appropriate = MTU

    =A0
    RE: ..."x Mbps. . ."
    Is that like = Bandwidth-On-Demand?
    ;)
    =A0
    Cheers,
    Dave sends

      ----- Original Message -----
      From: = Julien Godard = <mailto:jgodard@nortelnetworks= .com>
      To: 'Johnson, Gregory LCDR' <mailto:GJohnson@EXMAIL.USCGA.E= DU> ; 'Testasecca, Mariano' <mailto:Mariano.Testase= cca@siemens.com.ar>

      Cc: 'tcpsat@grc.nasa.gov' <mailto:'tcpsat@grc.nasa.gov'&g= t;
      Sent: = Tuesday, February 15, 2000 10:53 AM
      Subject: = RE: Setting the appropriate MTU


      Oups ! Yes, correct = !
      I completelly = forgot to look at the bandwidth. I am too use to run test with x = Mbps...

              -----Original Message-----
      From:=A0=A0 Johnson, Gregory = LCDR [ SMTP:GJohnson@EXMAIL.USCGA.EDU <mailto:SMTP:GJohnson@EXMA= IL.USCGA.EDU>]
      Sent:=A0=A0 Tuesday, February = 15, 2000 3:39 PM
      To:=A0=A0=A0=A0 Godard, Julien = [HAL02:HM90:EXCH]; 'Testasecca, Mariano'
      Cc:=A0=A0=A0=A0 'tcpsat@grc.nasa.gov' <mailto:'tcpsat@grc.nasa.gov'&g= t;
      Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Setting the = appropriate MTU

              Bigger is not better for slow networks. For a link speed = of 4kbps you will
      need to use much smaller MTU sizes = since the transmission time for a packet
      gets too long otherwise. It will = also depend upon what the latency is in the
      link because the total = transmission time for a packet is a function of the
      size and delay. For a typical GEO = link, I would expect that you have
      anywhere up to 600ms depending = upon what kind of FEC and interleaving is
      done on the link. I have found for = Inmarsat-M/Mini-M type links (2.4 kbps)
      that an MTU size of 500 works = well. You also need to adjust the initial RTO
      value larger (the default is 3 = secs, try 5 secs). If you don't do this, you
      will suffer a lot of timeouts and = retransmissions. I'm not that familiar
      with the protocol Citrix uses, but = with only 4kbps of bandwidth, you also
      don't want to run multiple = simultaneous connections across your link as one
      connection will probably saturate = the link.
      =A0 =

              -Greg=20

              LCDR Gregory W. Johnson
      Ass't Prof. Electrical Engineering =

              USCG Academy
      New London CT=20

              860-444-8683=20

              -----Original Message-----
      From: Julien Godard = [ <mailto:jgodard@nortelnetworks= .com>]
      Sent: Tuesday, February 15, 2000 = 4:59 AM
      To: 'Testasecca, = Mariano'
      Cc: = 'tcpsat@grc.nasa.gov'
      Subject: RE: Setting the = appropiate MTU



              for performance, the bigger the better !
      But it may depend also on your network = because you may want to avoid
      fragmentation.
      You can test your MTU with some free = tools such as easyMTU
      <http://members.tripod.com/~EasyMTU/>= < <http://members.tripod.com/~EasyMTU/>>=A0
      For example if you use ethernet link, the = MTU is 1500, leading to 1448 bytes
      of data in each segment (20 IP + = 20 TCP + 12 TCP timestamp option + 1448
      data). If your router support this = size without fragmentation, it's fine ! =

              =A0=A0=A0=A0=A0=A0=A0 -----Original Message-----
      From:=A0=A0 Testasecca, Mariano = [SMTP:Mariano.Testasecca@siemens.com.ar]
      Sent:=A0=A0 Monday, February 14, 2000 = 7:49 PM
      To:=A0=A0=A0=A0 = 'tcpsat@grc.nasa.gov'
      Subject:=A0=A0=A0=A0=A0=A0=A0 Setting the = appropiate MTU=20


              =A0=A0=A0=A0=A0=A0=A0 What MTU value would be appropiate for Windows 95/98 = terminals
      working as a
      Windows NT 4.0 running Citrix MetaFrame = under
      a satellite link of a VSAT that provides = 4kbps of bandwidth?=20

              =A0=A0=A0=A0=A0=A0=A0 Thanks to all.=20

              =A0=A0=A0=A0=A0=A0=A0 Mariano Testasecca
      SIEMENS S.A.
      Divisi=F3n Electromedicina
      Servicios de Salud - SHS
      Bolivar 177 1=BA Piso
      *+54-11-4340-8400 int. 2796
      * = <mailto:mariano.testase= cca@siemens.com.ar>
      < <mailto:mariano.testase= cca@siemens.com.ar>>=A0=20







------_=_NextPart_001_01BF7866.7D6E0DA8-- From owner-tcpsat@lerc.nasa.gov Wed Feb 16 10:16: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 KAA01390; Wed, 16 Feb 2000 10:16:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA09419 for tcpsat-outgoing; Wed, 16 Feb 2000 09:27:03 -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 JAA09395 for ; Wed, 16 Feb 2000 09:27:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA15379; Wed, 16 Feb 2000 09:26:59 -0500 (EST) Received: from isnt.uscga.edu(138.29.1.252) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015362; Wed, 16 Feb 00 09:26:27 -0500 Received: by isnt.uscga.edu with Internet Mail Service (5.5.2448.0) id <1ZLLBPRL>; Wed, 16 Feb 2000 09:26:05 -0500 Message-ID: <79EFC6EC2A78D11191B400600892BC9FFD77B4@isnt.uscga.edu> From: "Johnson, Gregory LCDR" To: "Davenport, David M (CRD)" , "'tcpsat@grc.nasa.gov'" Subject: RE: Setting the appropriate MTU Date: Wed, 16 Feb 2000 09:26:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I agree that mobile channels introduce other problems, but in this case it's the low data rate that's the issue not the mobility. Inmarsat Mini-M is a digital system, with FEC and interleaving and actually provides a channel that has a fairly good BER as long as the SNR is high enough. If the SNR drops too much then you are likely to drop the connection - it's a sharp cutoff, not a smooth degradation of service. And anyway, my testing has been from a fixed location... The slow channel speed is the biggest factor, since at 4 kbps it will take 3 secs to transmit 1500 bytes (if the channel is 8 bits, synchronous). If it is 10 bit asynchronous (8 bits data, 1 stop and 1 start bit) then it would take 3.75 sec. Many sources recommend an MTU size equivalent to what can be transmitted in 100-200 ms but I think that is not really appropriate for slow channel speeds 'cause the efficiency would be very poor. At 4kbps, a 200 ms MTU would be only 100 bytes (with at least 40 bytes of this being TCP/IP overhead!). -Greg LCDR Gregory W. Johnson Ass't Prof. Electrical Engineering USCG Academy New London CT 860-444-8683 -----Original Message----- From: Davenport, David M (CRD) [mailto:davenport@crd.ge.com] Sent: Tuesday, February 15, 2000 3:18 PM To: 'tcpsat@grc.nasa.gov' Subject: RE: Setting the appropriate MTU Now you've added mobility to the equation... With Inmarsat-M/Mini-M and other low data-rate, mobile satellite services an appropriate MTU selection is driven primarily by the Rician/Rayleigh fading channel and the trade-off: Large data frames to increase throughput efficiency - vs. - Small data frames to reduce required retransmission due to fading/shadowing For fixed site satellite with BER < 10^(-5), I'd suggest IP fragmentation along the entire route dominates MTU selection...and the bigger the better. David M. Davenport GE Corporate Research and Development One Research Circle, M/S KWC421 Niskayuna, NY 12309 Phone/Fax: (518) 387-5041/4042 ***** Opinions contained herein are my own and not necessarily those of my employer ***** From owner-tcpsat@lerc.nasa.gov Wed Feb 16 10:50:25 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 KAA03164; Wed, 16 Feb 2000 10:50:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA16122 for tcpsat-outgoing; Wed, 16 Feb 2000 10:10: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 KAA16101 for ; Wed, 16 Feb 2000 10:10:31 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA21307; Wed, 16 Feb 2000 10:10:30 -0500 (EST) Received: from vni62.vninet.com(209.118.74.62) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021227; Wed, 16 Feb 00 10:09:55 -0500 Received: by oscar.penguinpowered.com (Postfix, from userid 501) id 2D8A6268FC; Wed, 16 Feb 2000 06:18:16 -0500 (EST) Date: Wed, 16 Feb 2000 06:18:16 -0500 From: Graham Street To: tcpsat@grc.nasa.gov Subject: nt server vs wkstn.. tcpsat performance Message-ID: <20000216061816.A4288@oscar.penguinpowered.com> Reply-To: gstreet@vninet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I've done a whole lot of testing over the last couple of weeks, and incorporated alot of your suggestions... I've found some really strange behavior with different versions of nt. With NT 4 Workstation (sp 5 or 6) we get 207k (consistently) and very little else, despite window sizes, buffer sizes, etc. Our Link udget is 16 megabits. With NT 4 Server (sp 6) we get 2 megabits! consistently! With NT Server 3.5.1 (sp5) we get 207k again. With NT Server 3.5.1 (no service packs) we get 2 megabits again. This makes me think something is screwed up in one of the sp's. I tried taking the 3.5.1 sp5 machine back to sp3 but it didn't solve the problem. Does anyone have a clue as to what the file(s) are that are causing this? thanks, Graham Street gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Wed Feb 16 10:54:13 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 KAA03341; Wed, 16 Feb 2000 10:54:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA16293 for tcpsat-outgoing; Wed, 16 Feb 2000 10:12:37 -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 KAA16289 for ; Wed, 16 Feb 2000 10:12:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA21580; Wed, 16 Feb 2000 10:12:36 -0500 (EST) Received: from unknown(199.203.106.24) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021067; Wed, 16 Feb 00 10:10:52 -0500 Received: by mail.gvtele.com with Internet Mail Service (5.5.2448.0) id ; Wed, 16 Feb 2000 17:07:48 +0200 Message-ID: From: Noam Gonen - Israel To: "'Marcelo Reis'" , "'gstreet@vninet.com'" , tcpsat@grc.nasa.gov Subject: RE: nt to nt tcpsat problems Date: Wed, 16 Feb 2000 17:04:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id KAA16290 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Regarding DefaultReceiveWindow \ DefaultSendWindow : Note that applications can modify this value on a per-socket basis with the SO_RCVBUF socket option. so your changes might be "undone" on a per app. basis. regards, Noam G. (noamg@gilat.com) > -----Original Message----- > From: Marcelo Reis [SMTP:marcelor@vicom.com.br] > Sent: å 11 ôáøåàø 2000 14:23 > To: 'gstreet@vninet.com'; tcpsat@grc.nasa.gov > Subject: RES: nt to nt tcpsat problems > > Hi Graham, > > For winsock applications you need also to set two more variables: > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\Defaul > tR > eceiveWindow > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\Defaul > tS > endWindow > > Both of type REG_DWORD. > > I don't know if it applies to you, but NT4 SP5 has a math error in its tcp > stack that causes the retransmit timer to be incorrectly computed, leading > to unnecessary retransmissions. There is a new tcpip.sys file that fixes > that bug. If you need this file and also the MS bug report regarding this, > please let me know. > > Regards, > > Marcelo M. Reis > marcelor@vicom.com.br > > > ----- Mensagem original ----- > > De: Graham Street [SMTP:gstreet@oscar.penguinpowered.com] > > Enviada em: Quinta-feira, 10 de Fevereiro de 2000 11:04 > > Para: tcpsat@grc.nasa.gov > > Assunto: nt to nt tcpsat problems > > > > Hi all, > > > > We're trying to run windows file sharing protocols over a tcp sat link > > and getting miserable performance, even after setting TcpWindowSize to > > 65536. We can get about 100-250k max. We are trying to get at least > > one megabit out of it. Is this even possible? We can get 1-2 megabits > > ftping from a sun box over satellite... > > > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > > translating > > to udp?) > > > > Thanks, > > Graham Street > > gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Wed Feb 16 11:01: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 LAA03756; Wed, 16 Feb 2000 11:01:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA16981 for tcpsat-outgoing; Wed, 16 Feb 2000 10:17:19 -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 KAA16947 for ; Wed, 16 Feb 2000 10:17:18 -0500 (EST) From: Loay.Oweis@comsat.com Received: by seraph3.lerc.nasa.gov; id KAA22093; Wed, 16 Feb 2000 10:17:15 -0500 (EST) Received: from cqmx.corp.comsat.com(134.133.184.25) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022039; Wed, 16 Feb 00 10:16:33 -0500 Received: from cqgate5.cmc.comsat.com ([134.133.162.20]) by cqmx.corp.comsat.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Wed, 16 Feb 2000 10:15:43 -0500 Received: from ccMail by cqgate5.cmc.comsat.com (IMA Internet Exchange 3.13) id 0000F3E1; Wed, 16 Feb 2000 10:16:21 -0800 Mime-Version: 1.0 Date: Wed, 16 Feb 2000 10:13:45 -0800 Message-ID: <0000F3E1.C22277@comsat.com> Subject: Re:Fwd:RE: nt to nt tcpsat problems To: Rob.Kibler@comsat.com, tcpsat@grc.nasa.gov Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Please note that a TcpWindowSize of 65536 in decimal value is 1 0000 in Hexadecimal. Win NT 4.0 does not realize this is and sets the window size to 0. When sending a packet to a host with a TcpWindowSize of zero, the host follows the TCP spec and sends back 1 byte to respond to the zero window size. The Win NT host then proceeds to advertize a no-zero window size and the communications begin. The rest of the packet which trails the initial 1 byte originaly sent is fragmented and minimizes throughput. To provide a band-aid fix, you can set 1 back the TcpWindowSize to 65535 which is ffff in hex and does fit in the 16 bit tcp parameter. Windows advertizes correctly and communications is possible to a full theoretical 64 Kbyte * 8 bit/Byte / .250 ms(average sat delay) = 2.048 Kbit/sec Longterm fix - Use Solaris or Windows 2000 with the scaling option. Loay Oweis COMSAT Corp loay.oweis@comsat.com ____________________Reply Separator____________________ Subject: Fwd:RE: nt to nt tcpsat problems Author: Rob Kibler Date: 2/11/00 9:16 AM ____________________Forward Header_____________________ Subject: RE: nt to nt tcpsat problems Author: Date: 2/10/00 6:04 PM Gentlemen, I did a week long study on this exact problem and the simple answer is "YOU ARE OUT OF LUCK." I have a ticket open with MS on this problem as it is how the CIFS protocol works. CIFS will only negotiate a 4K transfer size when the latency and bandwidth are small (if you are very very ... lucky maybe upto 12K). Basically, in short your throughput will be about equal to 4K/RTT (excluding other various factors). Thus, window size only needs to be 4K for this. It is a higher layer problem!!! While I cannot give you a copy of my report, I do have a couple of graphs I can get to you. Greg -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Robert Schellhase Sent: Thursday, February 10, 2000 1:18 PM To: gstreet@vninet.com Cc: tcpsat@grc.nasa.gov Subject: RE: nt to nt tcpsat problems Hi Graham, I see you have found that Windows supports a registry key for TcpWindowSize. The sad news is that it has no effect, in spite of the fact that Microsoft has a white paper on its own TCP implementation that claims otherwise. You might try the NetManage OnNet kernel for Windows 95/98 at http://www.netmanage.com/products/onnetkernel4/index.asp I don't know what they charge for it, but I think it's affordable and they offer a free demo. Best regards, Robert Schellhase Senior Engineer INTELSAT -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Graham Street Sent: Thursday, February 10, 2000 9:04 AM To: tcpsat@grc.nasa.gov Subject: nt to nt tcpsat problems Hi all, We're trying to run windows file sharing protocols over a tcp sat link and getting miserable performance, even after setting TcpWindowSize to 65536. We can get about 100-250k max. We are trying to get at least one megabit out of it. Is this even possible? We can get 1-2 megabits ftping from a sun box over satellite... does anyone know of any clever (cheap) solutions (spoofing nacks?, translating to udp?) Thanks, Graham Street gstreet@vninet.com Received: from neal ([134.133.40.21]) by cqgate6.cmc.comsat.com with SMTP (IMA Internet Exchange 3.13) id 0000C4FC; Thu, 10 Feb 2000 20:34:37 -0500 Received: from [139.88.112.33] (helo=lombok-fi.lerc.nasa.gov) by neal with esmtp (Exim 2.12 #8) id 12J4w1-0002ND-00; Thu, 10 Feb 2000 20:31:49 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA03975 for tcpsat-outgoing; Thu, 10 Feb 2000 19:05:42 -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 TAA03944 for ; Thu, 10 Feb 2000 19:05:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA20274; Thu, 10 Feb 2000 19:05:40 -0500 (EST) Received: from new-frontier-consulting-745192.cust-rtr.swbell.net(151.164.200.70) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020153; Thu, 10 Feb 00 19:04:58 -0500 Received: from houpdc.newf.com (mail.newf.com [216.62.131.2]) by ns.newf.com (8.9.3/8.9.3) with ESMTP id SAA08636; Thu, 10 Feb 2000 18:04:54 -0600 Received: from heliox (216.190.71.51) by houpdc.newf.com (Worldmail 1.3.167); 10 Feb 2000 18:04:54 -0600 Reply-To: From: "Greg Otto" To: "'Robert Schellhase'" , Cc: Subject: RE: nt to nt tcpsat problems Date: Thu, 10 Feb 2000 18:04:20 -0600 Message-ID: <000001bf7423$8bee7080$3347bed8@ottovation.com> MIME-Version: 1.0 Content-Type: text/plain; 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <000001bf73fb$8f1de5b0$1615cad0@kensington> Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk From owner-tcpsat@lerc.nasa.gov Wed Feb 16 13:57:08 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 NAA10004; Wed, 16 Feb 2000 13:57:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA14377 for tcpsat-outgoing; Wed, 16 Feb 2000 13:19:49 -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 NAA14373 for ; Wed, 16 Feb 2000 13:19:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA18048; Wed, 16 Feb 2000 13:19:47 -0500 (EST) Received: from ntvicrj07.victori.com.br(200.225.23.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018034; Wed, 16 Feb 00 13:19:35 -0500 Received: by ntvicrj07.victori.com.br with Internet Mail Service (5.5.2448.0) id ; Wed, 16 Feb 2000 16:23:40 -0300 Message-ID: <3104310CE765D211A66E00104B87219F562BFC@ntvicrj07.victori.com.br> From: Marcelo Reis To: "'Loay.Oweis@comsat.com'" , Rob.Kibler@comsat.com, tcpsat@grc.nasa.gov Subject: RES: Fwd:RE: nt to nt tcpsat problems Date: Wed, 16 Feb 2000 16:23:34 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Loay, The window size in the TCP header is also 16bits long. It's not because of NT4 that you can't configure for 65536. Please note that in your formula you need to use the RTT (2*250ms), not only 250ms. Regards, Marcelo M. Reis marcelor@vicom.com.br > ----- Mensagem original ----- > De: Loay.Oweis@comsat.com [SMTP:Loay.Oweis@comsat.com] > Enviada em: Quarta-feira, 16 de Fevereiro de 2000 15:14 > Para: Rob.Kibler@comsat.com; tcpsat@grc.nasa.gov > Assunto: Re:Fwd:RE: nt to nt tcpsat problems > > > > Please note that a TcpWindowSize of 65536 in decimal value is > 1 0000 in Hexadecimal. Win NT 4.0 does not realize this is and sets > the window size to 0. When sending a packet to a host with a > TcpWindowSize of zero, the host follows the TCP spec and sends back 1 byte > to > respond to the zero window size. The Win NT host then proceeds to > advertize a > no-zero window size and the communications begin. The rest of the packet > which > trails the initial 1 byte originaly sent is fragmented and minimizes > throughput. > > To provide a band-aid fix, you can set 1 back the TcpWindowSize to 65535 > which > is ffff in hex and does fit in the 16 bit tcp parameter. > Windows advertizes correctly and communications is possible to a full > theoretical > > 64 Kbyte * 8 bit/Byte / .250 ms(average sat delay) = 2.048 Kbit/sec > > Longterm fix - Use Solaris or Windows 2000 with the scaling option. > > Loay Oweis > COMSAT Corp > loay.oweis@comsat.com > > > ____________________Reply Separator____________________ > Subject: Fwd:RE: nt to nt tcpsat problems > Author: Rob Kibler > Date: 2/11/00 9:16 AM > > > > ____________________Forward Header_____________________ > Subject: RE: nt to nt tcpsat problems > Author: > Date: 2/10/00 6:04 PM > > Gentlemen, > > I did a week long study on this exact problem and the simple answer is > "YOU > ARE OUT OF LUCK." I have a ticket open with MS on this problem as it is > how > the CIFS protocol works. CIFS will only negotiate a 4K transfer size when > the latency and bandwidth are small (if you are very very ... lucky maybe > upto 12K). Basically, in short your throughput will be about equal to > 4K/RTT (excluding other various factors). Thus, window size only needs to > be 4K for this. It is a higher layer problem!!! > > While I cannot give you a copy of my report, I do have a couple of graphs > I > can get to you. > > Greg > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Robert Schellhase > Sent: Thursday, February 10, 2000 1:18 PM > To: gstreet@vninet.com > Cc: tcpsat@grc.nasa.gov > Subject: RE: nt to nt tcpsat problems > > > Hi Graham, > I see you have found that Windows supports a registry key for > TcpWindowSize. > The sad news is that it has no effect, in spite of the fact that Microsoft > has a white paper on its own TCP implementation that claims otherwise. > > You might try the NetManage OnNet kernel for Windows 95/98 at > http://www.netmanage.com/products/onnetkernel4/index.asp > > I don't know what they charge for it, but I think it's affordable and they > offer a free demo. > > Best regards, > Robert Schellhase > Senior Engineer > INTELSAT > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Graham Street > Sent: Thursday, February 10, 2000 9:04 AM > To: tcpsat@grc.nasa.gov > Subject: nt to nt tcpsat problems > > > Hi all, > > We're trying to run windows file sharing protocols over a tcp sat link > and getting miserable performance, even after setting TcpWindowSize to > 65536. We can get about 100-250k max. We are trying to get at least > one megabit out of it. Is this even possible? We can get 1-2 megabits > ftping from a sun box over satellite... > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > translating > to udp?) > > Thanks, > Graham Street > gstreet@vninet.com > > > Received: from neal ([134.133.40.21]) by cqgate6.cmc.comsat.com with SMTP > (IMA Internet Exchange 3.13) id 0000C4FC; Thu, 10 Feb 2000 20:34:37 > -0500 > Received: from [139.88.112.33] (helo=lombok-fi.lerc.nasa.gov) > by neal with esmtp (Exim 2.12 #8) > id 12J4w1-0002ND-00; Thu, 10 Feb 2000 20:31:49 -0500 > Received: (from listserv@localhost) > by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA03975 > for tcpsat-outgoing; Thu, 10 Feb 2000 19:05:42 -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 > TAA03944 > for ; Thu, 10 Feb 2000 19:05:40 -0500 (EST) > Received: by seraph3.lerc.nasa.gov; id TAA20274; Thu, 10 Feb 2000 19:05:40 > -0500 > (EST) > Received: from > new-frontier-consulting-745192.cust-rtr.swbell.net(151.164.200.70) by > seraph3.lerc.nasa.gov via smap (V5.0) > id xma020153; Thu, 10 Feb 00 19:04:58 -0500 > Received: from houpdc.newf.com (mail.newf.com [216.62.131.2]) > by ns.newf.com (8.9.3/8.9.3) with ESMTP id SAA08636; > Thu, 10 Feb 2000 18:04:54 -0600 > Received: from heliox (216.190.71.51) by houpdc.newf.com (Worldmail > 1.3.167); 10 > Feb 2000 18:04:54 -0600 > Reply-To: > From: "Greg Otto" > To: "'Robert Schellhase'" , > > Cc: > Subject: RE: nt to nt tcpsat problems > Date: Thu, 10 Feb 2000 18:04:20 -0600 > Message-ID: <000001bf7423$8bee7080$3347bed8@ottovation.com> > MIME-Version: 1.0 > Content-Type: text/plain; > 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) > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 > Importance: Normal > In-Reply-To: <000001bf73fb$8f1de5b0$1615cad0@kensington> > Sender: owner-tcpsat@lerc.nasa.gov > Precedence: bulk From owner-tcpsat@lerc.nasa.gov Wed Feb 16 13:58: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 NAA10036; Wed, 16 Feb 2000 13:58:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA12505 for tcpsat-outgoing; Wed, 16 Feb 2000 13:07:09 -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 NAA12446 for ; Wed, 16 Feb 2000 13:07:02 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA16381; Wed, 16 Feb 2000 13:07:01 -0500 (EST) Received: from ntvicrj07.victori.com.br(200.225.23.3) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016276; Wed, 16 Feb 00 13:06:18 -0500 Received: by ntvicrj07.victori.com.br with Internet Mail Service (5.5.2448.0) id ; Wed, 16 Feb 2000 16:10:02 -0300 Message-ID: <3104310CE765D211A66E00104B87219F562BFB@ntvicrj07.victori.com.br> From: Marcelo Reis To: "'Noam Gonen - Israel'" , "'gstreet@vninet.com'" , tcpsat@grc.nasa.gov Subject: RES: nt to nt tcpsat problems Date: Wed, 16 Feb 2000 16:09:58 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-8" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id NAA12458 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit It's true. But if you use the ftp client that comes with windows it will use the default values configured. Regards, Marcelo M. Reis marcelor@vicom.com.br > ----- Mensagem original ----- > De: Noam Gonen - Israel [SMTP:NOAMG@gilat.com] > Enviada em: Quarta-feira, 16 de Fevereiro de 2000 12:04 > Para: 'Marcelo Reis'; 'gstreet@vninet.com'; tcpsat@grc.nasa.gov > Assunto: RE: nt to nt tcpsat problems > > Regarding DefaultReceiveWindow \ DefaultSendWindow : > > Note that applications can modify this value on a per-socket basis > with the SO_RCVBUF socket option. > so your changes might be "undone" on a per app. basis. > > regards, > Noam G. (noamg@gilat.com) > > > > > -----Original Message----- > > From: Marcelo Reis [SMTP:marcelor@vicom.com.br] > > Sent: å 11 ôáøåàø 2000 14:23 > > To: 'gstreet@vninet.com'; tcpsat@grc.nasa.gov > > Subject: RES: nt to nt tcpsat problems > > > > Hi Graham, > > > > For winsock applications you need also to set two more variables: > > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\Defaul > > tR > > eceiveWindow > > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters\Defaul > > tS > > endWindow > > > > Both of type REG_DWORD. > > > > I don't know if it applies to you, but NT4 SP5 has a math error in its > tcp > > stack that causes the retransmit timer to be incorrectly computed, > leading > > to unnecessary retransmissions. There is a new tcpip.sys file that fixes > > that bug. If you need this file and also the MS bug report regarding > this, > > please let me know. > > > > Regards, > > > > Marcelo M. Reis > > marcelor@vicom.com.br > > > > > ----- Mensagem original ----- > > > De: Graham Street > [SMTP:gstreet@oscar.penguinpowered.com] > > > Enviada em: Quinta-feira, 10 de Fevereiro de 2000 11:04 > > > Para: tcpsat@grc.nasa.gov > > > Assunto: nt to nt tcpsat problems > > > > > > Hi all, > > > > > > We're trying to run windows file sharing protocols over a tcp sat link > > > and getting miserable performance, even after setting TcpWindowSize to > > > 65536. We can get about 100-250k max. We are trying to get at least > > > one megabit out of it. Is this even possible? We can get 1-2 > megabits > > > ftping from a sun box over satellite... > > > > > > does anyone know of any clever (cheap) solutions (spoofing nacks?, > > > translating > > > to udp?) > > > > > > Thanks, > > > Graham Street > > > gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Wed Feb 16 15:25:32 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 PAA12487; Wed, 16 Feb 2000 15:25:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA26837 for tcpsat-outgoing; Wed, 16 Feb 2000 14:40:59 -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 OAA26795 for ; Wed, 16 Feb 2000 14:40:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA29331; Wed, 16 Feb 2000 14:40:54 -0500 (EST) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029196; Wed, 16 Feb 00 14:40:09 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24211 for ; Wed, 16 Feb 2000 11:40:06 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA17269 for ; Wed, 16 Feb 2000 11:40:04 -0800 (PST) Received: from dors (awe185-69.AWE.Sun.COM [192.29.185.69]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA01372 for ; Wed, 16 Feb 2000 11:40:03 -0800 (PST) Date: Wed, 16 Feb 2000 11:41:21 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: RE: Setting the appropriate MTU To: tcpsat@grc.nasa.gov In-Reply-To: "Your message with ID" <79EFC6EC2A78D11191B400600892BC9FFD77B4@isnt.uscga.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > The slow channel speed is the biggest factor, since at 4 kbps it will take 3 > secs to transmit 1500 bytes (if the channel is 8 bits, synchronous). If it > is 10 bit asynchronous (8 bits data, 1 stop and 1 start bit) then it would > take 3.75 sec. Many sources recommend an MTU size equivalent to what can be > transmitted in 100-200 ms but I think that is not really appropriate for > slow channel speeds 'cause the efficiency would be very poor. At 4kbps, a > 200 ms MTU would be only 100 bytes (with at least 40 bytes of this being > TCP/IP overhead!). Just a point of interests on the above. TCP has a delayed acknowledgement mechanism. An ack is sent for every two segments or when the delayed ack timer fires. The delayed ack timeout value (DATO) is usually 200ms. If it takes more than DATO for TCP to receive a segment, there are two consequences. First, TCP will ack every segments. Second, every such acks will be a delayed ack. If TCP is going to ack every segment, it may be better to just turn off delayed ack mechanism completely. And depending on the reverse channel, more acks may or may not affect performance. Something to think about when doing TCP throughput performance experiments with slow links... K. Poon. kcpoon@eng.sun.com From owner-tcpsat@lerc.nasa.gov Wed Feb 16 16:55:08 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 QAA15845; Wed, 16 Feb 2000 16:54:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA07949 for tcpsat-outgoing; Wed, 16 Feb 2000 15:56:03 -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 PAA07906 for ; Wed, 16 Feb 2000 15:55:58 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA09652; Wed, 16 Feb 2000 15:55:56 -0500 (EST) Received: from new-frontier-consulting-745192.cust-rtr.swbell.net(151.164.200.70) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009623; Wed, 16 Feb 00 15:55:45 -0500 Received: from houpdc.newf.com (mail.newf.com [216.62.131.2]) by ns.newf.com (8.9.3/8.9.3) with ESMTP id OAA25069; Wed, 16 Feb 2000 14:55:43 -0600 Received: from gdo (216.192.230.49) by houpdc.newf.com (Worldmail 1.3.167); 16 Feb 2000 14:55:43 -0600 Reply-To: From: "Greg Otto" To: , Subject: RE: nt server vs wkstn.. tcpsat performance Date: Wed, 16 Feb 2000 14:39:15 -0600 Message-ID: <000001bf78c0$1ee76b80$0501800a@gdo> 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 In-Reply-To: <20000216061816.A4288@oscar.penguinpowered.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit It most likely has to do with rather CIFS is using RAW or CORE mode for transfers and what the blocks are. This is dependent upon the SPx and NTx. Have you put a sniffer on there to see what block sizes are being requested? Greg -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Graham Street Sent: Wednesday, February 16, 2000 5:18 AM To: tcpsat@grc.nasa.gov Subject: nt server vs wkstn.. tcpsat performance I've done a whole lot of testing over the last couple of weeks, and incorporated alot of your suggestions... I've found some really strange behavior with different versions of nt. With NT 4 Workstation (sp 5 or 6) we get 207k (consistently) and very little else, despite window sizes, buffer sizes, etc. Our Link udget is 16 megabits. With NT 4 Server (sp 6) we get 2 megabits! consistently! With NT Server 3.5.1 (sp5) we get 207k again. With NT Server 3.5.1 (no service packs) we get 2 megabits again. This makes me think something is screwed up in one of the sp's. I tried taking the 3.5.1 sp5 machine back to sp3 but it didn't solve the problem. Does anyone have a clue as to what the file(s) are that are causing this? thanks, Graham Street gstreet@vninet.com From owner-tcpsat@lerc.nasa.gov Thu Feb 17 04:42:33 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 EAA08288; Thu, 17 Feb 2000 04:42:31 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA23273 for tcpsat-outgoing; Thu, 17 Feb 2000 03:56:58 -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 DAA23239 for ; Thu, 17 Feb 2000 03:56:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA14687; Thu, 17 Feb 2000 03:56:55 -0500 (EST) Received: from mayday.interpacket.net(209.198.223.250) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014678; Thu, 17 Feb 00 03:56:35 -0500 Received: (qmail 29985 invoked from network); 17 Feb 2000 08:56:33 -0000 Received: from thuk-dialup-1.interpacket.net (HELO ?209.198.248.243?) (209.198.248.230) by bond.interpacket.net with SMTP; 17 Feb 2000 08:56:33 -0000 Mime-Version: 1.0 X-Sender: jonm@bond.interpacket.net Message-Id: Date: Thu, 17 Feb 2000 08:56:15 +0000 To: tcpsat@grc.nasa.gov From: Jon Mansey Subject: Fwd: MICROSOFT INVESTS IN SATELLITE Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id DAA23242 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit >> >> Microsoft in satellite ISP deal >> By Margaret Kane, ZDNet News >> 02/16/2000 07:00 >> >> >> Microsoft Corp. has teamed up with an >> Israeli company to develop a satellite-based >> Internet service for consumers. >> >> Microsoft (Nasdaq: MSFT) will invest $50 million >> in Gilat Satellite Networks Ltd.ís (Nasdaq: >> GILTF) new company, Gilat-to-Home, and will >> own 26 percent of the joint venture. >> >> The new company will be based in McLean, Va., >> and will be run by Zur Feldman, who formerly >> served as executive vice president of operations >> at Packard Bell Electronics Inc. >> >> The new service, which is currently in trials, will >> allow consumers to access the Internet via a >> two-way satellite hookup. The service is typically >> around 10 times faster than traditional modems. >> >> MSN Internet access via satellite will be available >> directly from Microsoft and through retailers. It will >> launch first at Tandy Corp.'s Radio Shack stores, >> in the Microsoft "store-within-a-store," later this >> year. >> >> In a separate release, Gilat said it expected the >> service to grow to a base of 2.7 million >> subscribers by 2005. From owner-tcpsat@lerc.nasa.gov Mon Feb 21 10:39: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 KAA09549; Mon, 21 Feb 2000 10:39:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA29750 for tcpsat-outgoing; Mon, 21 Feb 2000 09:18:35 -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 JAA29731 for ; Mon, 21 Feb 2000 09:18:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA14638; Mon, 21 Feb 2000 09:18:32 -0500 (EST) Received: from tc057.bbn.com(128.33.238.57) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014533; Mon, 21 Feb 00 09:18:15 -0500 Received: from lawyers (IDENT:mallman@localhost [127.0.0.1]) by lawyers.lerc.nasa.gov (8.9.3/8.9.3) with ESMTP id IAA02114; Mon, 21 Feb 2000 08:58:27 -0500 Message-Id: <200002211358.IAA02114@lawyers.lerc.nasa.gov> To: "Julien Godard" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'Dave'" , "'Johnson, Gregory LCDR'" , "'Testasecca, Mariano'" , "'tcpsat@grc.nasa.gov'" Subject: Re: Setting the appropriate MTU Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Money Date: Mon, 21 Feb 2000 08:58:27 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > Of course, by increasing the MTU, you increase the RTT in the case > of low rate (time needed to transmit the packet) or BoD > (ressources required to transmit the packet). Thus you have to > adapt your socket buffer size (and thus your max window) to the > BDP with the "real RTT", and not only the link delay. I *think* I disagree, but I am not completely sure what you're saying... Your buffer sizes need to be about 1*BDP of the unloaded path. If you use a higher delay that the propagation delay then you are building a persistent queue somewhere. Basically, the BDP of the unloaded network is the number of bits that will "fit" into the network at one time. So, if your window is bigger than this you are pushing more bits than the network itself is able to handle over the path. The bits either have to go into queues or in the bit-bucket. (You might need to make a small change for the transmission time of a packet ona slow link. I'd have to think about that some more. But, in general you do not want to track the "real" RTT to determine how big your socket buffers should be.) allman --- http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@lerc.nasa.gov Tue Feb 22 12:08:03 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 MAA15501; Tue, 22 Feb 2000 12:07:52 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA07438 for tcpsat-outgoing; Tue, 22 Feb 2000 10:49: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 KAA07389 for ; Tue, 22 Feb 2000 10:49:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA29473; Tue, 22 Feb 2000 10:49:38 -0500 (EST) Received: from mailhub.fokus.gmd.de(193.174.154.14) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029455; Tue, 22 Feb 00 10:49:37 -0500 Received: from fokus.gmd.de (gonom [193.175.132.125]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA14721 for ; Tue, 22 Feb 2000 16:48:34 +0100 (MET) Message-ID: <38B2B00A.847857C6@fokus.gmd.de> Date: Tue, 22 Feb 2000 16:49:30 +0100 From: Marc Emmelmann Organization: GMD - Fokus (http://www.fokus.gmd.de) X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en-US,de,fr MIME-Version: 1.0 To: "'tcpsat@grc.nasa.gov'" Subject: Network Simulation Tools Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I need to run some experiments / simulations with TCP/IP in a LEO Satellite environment. My special interest is on how the different TCP flavors behave in the context of time-varying round trip delays. I am planing to use the NS Network Simulator (ns2) for my trials and would like to ask if any of you has a suggestion about other simulator I should considder or (even better) has a pointer to previous work by some one else. Thanks for your reply, Marc -- German National Research Research Center for Center for Information Technology Open Communication Systems Marc Emmelmann Phone: +49-30-34 63 - 7265 GMD-FOKUS Fax: +49-30-34 63 - 8265 Kaiserin-Augusta-Allee 31 e-mail: emmelmann@fokus.gmd.de D-10589 Berlin, Germany http://www.fokus.gmd.de PGP Fingerprint: 9858 95FA 0705 9D81 AB2A EE64 5D7F CEBA 2943 2BD5 From owner-tcpsat@lerc.nasa.gov Tue Feb 22 13:48: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 NAA18552; Tue, 22 Feb 2000 13:47:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA00305 for tcpsat-outgoing; Tue, 22 Feb 2000 13:02: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 NAA00273 for ; Tue, 22 Feb 2000 13:02:45 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA18831; Tue, 22 Feb 2000 13:02:44 -0500 (EST) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018811; Tue, 22 Feb 00 13:02:31 -0500 Received: from churchward.erg.abdn.ac.uk (churchward.erg.abdn.ac.uk [139.133.204.110]) by erg.abdn.ac.uk (8.10.0.Beta12/8.10.0.Beta12) with SMTP id e1MI7mf23819; Tue, 22 Feb 2000 18:07:48 GMT Received: from churchward.erg.abdn.ac.uk by churchward.erg.abdn.ac.uk (SMI-8.6/SMI-SVR4) id SAA28177; Tue, 22 Feb 2000 18:01:37 GMT Message-Id: <200002221801.SAA28177@churchward.erg.abdn.ac.uk> Date: Tue, 22 Feb 2000 18:01:37 +0000 (GMT) From: Martin Koyabe Reply-To: Martin Koyabe Subject: Re: Network Simulation Tools To: tcpsat@grc.nasa.gov, emmelmann@fokus.gmd.de MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 16kGFNJzzao+u41C9sugDg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Marc, NS might be your reasonable choice !! Check Tom's work on simulation TCP via LEO's with ns !! http://www.cs.berkeley.edu:80/~tomh/thesis/ -- Martin --------------------------------------------------------------------- Martin L.W.D Koyabe e-mail: koyabe@erg.abdn.ac.uk Electronics Research Group Fraser Noble Building King's College, AB24 3UE (Off) +44-01224-272813 Aberdeen, UK (Mob) +44-07881-610825 > Date: Tue, 22 Feb 2000 16:49:30 +0100 > From: Marc Emmelmann > X-Accept-Language: en-US,de,fr > MIME-Version: 1.0 > To: "'tcpsat@grc.nasa.gov'" > Subject: Network Simulation Tools > Content-Transfer-Encoding: 7bit > > Hello, > > I need to run some experiments / simulations with TCP/IP in a LEO > Satellite environment. My special interest is on how the different TCP > flavors behave in the context of time-varying round trip delays. > > I am planing to use the NS Network Simulator (ns2) for my trials and > would like to ask if any of you has a suggestion about other simulator I > should considder or (even better) has a pointer to previous work by some > one else. > > Thanks for your reply, > > Marc > > -- > German National Research Research Center for > Center for Information Technology Open Communication Systems > > Marc Emmelmann Phone: +49-30-34 63 - 7265 > GMD-FOKUS Fax: +49-30-34 63 - 8265 > Kaiserin-Augusta-Allee 31 e-mail: emmelmann@fokus.gmd.de > D-10589 Berlin, Germany http://www.fokus.gmd.de > > PGP Fingerprint: 9858 95FA 0705 9D81 AB2A EE64 5D7F CEBA 2943 2BD5 From owner-tcpsat@lerc.nasa.gov Tue Feb 22 14:20: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 OAA19509; Tue, 22 Feb 2000 14:20:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA06051 for tcpsat-outgoing; Tue, 22 Feb 2000 13:37: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 NAA06010 for ; Tue, 22 Feb 2000 13:37:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA23740; Tue, 22 Feb 2000 13:37:15 -0500 (EST) Received: from info.iet.unipi.it(131.114.9.184) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023587; Tue, 22 Feb 00 13:36:50 -0500 Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id TAA98971; Tue, 22 Feb 2000 19:36:18 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200002221836.TAA98971@info.iet.unipi.it> Subject: Re: Network Simulation Tools In-Reply-To: <38B2B00A.847857C6@fokus.gmd.de> from Marc Emmelmann at "Feb 22, 2000 04:49:30 pm" To: Marc Emmelmann Date: Tue, 22 Feb 2000 19:36:18 +0100 (CET) CC: "'tcpsat@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-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Hello, > > I need to run some experiments / simulations with TCP/IP in a LEO > Satellite environment. My special interest is on how the different TCP > flavors behave in the context of time-varying round trip delays. > > I am planing to use the NS Network Simulator (ns2) for my trials and > would like to ask if any of you has a suggestion about other simulator I > should considder or (even better) has a pointer to previous work by some > one else. see dummynet -- http://www.iet.unipi.it/~luigi/ip_dummynet/ I think there are already some dummynet users there at GMD-FOKUS. cheers luigi -----------------------------------+------------------------------------- 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-tcpsat@lerc.nasa.gov Tue Feb 22 15:15: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 PAA21636; Tue, 22 Feb 2000 15:15:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA15005 for tcpsat-outgoing; Tue, 22 Feb 2000 14:29: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 OAA14986 for ; Tue, 22 Feb 2000 14:29:46 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA01560; Tue, 22 Feb 2000 14:29:46 -0500 (EST) Received: from mailgw2a.lmco.com(192.91.147.7) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001545; Tue, 22 Feb 00 14:29:27 -0500 Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id OAA11931; Tue, 22 Feb 2000 14:29:22 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <0FQC00101JENXP@lmco.com>; Tue, 22 Feb 2000 14:27:59 -0500 (EST) Received: from emss09m01.ems.lmco.com ([158.183.24.5]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <0FQC00MPQJEL3N@lmco.com>; Tue, 22 Feb 2000 14:27:57 -0500 (EST) Received: by emss09m01.ems.lmco.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Feb 2000 14:29:22 -0500 Content-return: allowed Date: Tue, 22 Feb 2000 14:28:11 -0500 From: "Shvodian, Bill" Subject: RE: Network Simulation Tools To: "'Marc Emmelmann'" , "'tcpsat@grc.nasa.gov'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT Marc, OPNET supports the different flavors of TCP, and it provides some LEO models as user contributed models. I have never used the LEO models, so I can't comment on their usefulness. http://www.mil3.com Bill Shvodian > -----Original Message----- > From: Marc Emmelmann [SMTP:emmelmann@fokus.gmd.de] > Sent: Tuesday, February 22, 2000 10:50 AM > To: 'tcpsat@grc.nasa.gov' > Subject: Network Simulation Tools > > Hello, > > I need to run some experiments / simulations with TCP/IP in a LEO > Satellite environment. My special interest is on how the different TCP > flavors behave in the context of time-varying round trip delays. > > I am planing to use the NS Network Simulator (ns2) for my trials and > would like to ask if any of you has a suggestion about other simulator I > should considder or (even better) has a pointer to previous work by some > one else. > > Thanks for your reply, > > Marc > > -- > German National Research Research Center for > Center for Information Technology Open Communication Systems > > Marc Emmelmann Phone: +49-30-34 63 - 7265 > GMD-FOKUS Fax: +49-30-34 63 - 8265 > Kaiserin-Augusta-Allee 31 e-mail: emmelmann@fokus.gmd.de > D-10589 Berlin, Germany http://www.fokus.gmd.de > > PGP Fingerprint: 9858 95FA 0705 9D81 AB2A EE64 5D7F CEBA 2943 2BD5 From owner-tcpsat@lerc.nasa.gov Wed Feb 23 04:28:37 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 EAA17197; Wed, 23 Feb 2000 04:28:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA16844 for tcpsat-outgoing; Wed, 23 Feb 2000 03:45: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 DAA16837 for ; Wed, 23 Feb 2000 03:45:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA19929; Wed, 23 Feb 2000 03:45:54 -0500 (EST) Received: from qhars001.nortelnetworks.com(192.100.101.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma019916; Wed, 23 Feb 00 03:45:34 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars001.nortel.com; Wed, 23 Feb 2000 08:42:59 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Feb 2000 08:42:56 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050DF0@zhard000.europe.nortel.com> From: "Julien Godard" To: "'Marc Emmelmann'" Cc: "'tcpsat@grc.nasa.gov'" Subject: RE: Network Simulation Tools Date: Wed, 23 Feb 2000 08:42:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7DD9.FAFA87E2" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7DD9.FAFA87E2 Content-Type: text/plain for emulation (experiments) a good starting point is the RFC 2398 "TCP tools for implementators" I especially recommend the combinaison of tcpdump/tcptarce/xplot to analyse TCP behavior. I never try to use delay generators mentionned in this RFC, so I don't know if they are capable to generate changing delay. For NS, I know there is a TCP stack and some satellite tools. But I never play with them. Cheers Julien > -----Original Message----- > From: Marc Emmelmann [SMTP:emmelmann@fokus.gmd.de] > Sent: 22 February 2000 15:50 > To: 'tcpsat@grc.nasa.gov' > Subject: Network Simulation Tools > > Hello, > > I need to run some experiments / simulations with TCP/IP in a LEO > Satellite environment. My special interest is on how the different TCP > flavors behave in the context of time-varying round trip delays. > > I am planing to use the NS Network Simulator (ns2) for my trials and > would like to ask if any of you has a suggestion about other simulator I > should considder or (even better) has a pointer to previous work by some > one else. > > Thanks for your reply, > > Marc > > -- > German National Research Research Center for > Center for Information Technology Open Communication Systems > > Marc Emmelmann Phone: +49-30-34 63 - 7265 > GMD-FOKUS Fax: +49-30-34 63 - 8265 > Kaiserin-Augusta-Allee 31 e-mail: emmelmann@fokus.gmd.de > D-10589 Berlin, Germany http://www.fokus.gmd.de > > PGP Fingerprint: 9858 95FA 0705 9D81 AB2A EE64 5D7F CEBA 2943 2BD5 ------_=_NextPart_001_01BF7DD9.FAFA87E2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Network Simulation Tools

for emulation = (experiments) a good starting point is the RFC 2398 "TCP tools for = implementators"
I especially = recommend the combinaison of tcpdump/tcptarce/xplot to analyse TCP = behavior.
I never try to use = delay generators mentionned in this RFC, so I don't know if they are = capable to generate changing delay.

For NS, I know there = is a TCP stack and some satellite tools. But I never play with = them.

Cheers
Julien

    -----Original Message-----
    From:   Marc Emmelmann = [SMTP:emmelmann@fokus.gmd.de]
    Sent:   22 February 2000 15:50
    To:     'tcpsat@grc.nasa.gov'
    Subject:       = Network Simulation Tools

    Hello,

    I need to run some experiments / = simulations with TCP/IP in a LEO
    Satellite environment. My special = interest is on how the different TCP
    flavors behave in the context of = time-varying round trip delays.

    I am planing to use the NS Network = Simulator (ns2) for my trials and
    would like to ask if any of you has a = suggestion about other simulator I
    should considder or (even better) has = a pointer to previous work by some
    one else.

    Thanks for your reply,

    Marc

    --
    German National = Research          &nbs= p; Research Center for
    Center for Information = Technology   Open Communication Systems

    Marc = Emmelmann          &nb= sp;           = Phone:  +49-30-34 63 - 7265
    GMD-FOKUS        =             =        Fax:    +49-30-34 = 63 - 8265
    Kaiserin-Augusta-Allee = 31           e-mail: = emmelmann@fokus.gmd.de
    D-10589 Berlin, = Germany           = ;  http://www.fokus.gmd.de

    PGP Fingerprint: 9858 95FA 0705 9D81 = AB2A  EE64 5D7F CEBA 2943 2BD5

------_=_NextPart_001_01BF7DD9.FAFA87E2-- From owner-tcpsat@lerc.nasa.gov Wed Feb 23 05:46:00 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 FAA17823; Wed, 23 Feb 2000 05:46:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA20276 for tcpsat-outgoing; Wed, 23 Feb 2000 05:08:26 -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 FAA20269 for ; Wed, 23 Feb 2000 05:08:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA25346; Wed, 23 Feb 2000 05:08:24 -0500 (EST) Received: from verdi.radiofrance.com(62.161.232.97) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025320; Wed, 23 Feb 00 05:07:59 -0500 Received: from RF75A-Message_Server by radiofrance.com with Novell_GroupWise; Wed, 23 Feb 2000 11:07:28 +0100 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Wed, 23 Feb 2000 11:06:55 +0100 From: "Thomas Wiard" To: tcpsat@grc.nasa.gov Cc: sylvain.petit@radiofrance.com Subject: bandwidth on VSAT transfer 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 FAA20273 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi from France. we are testing the Comsat VSAT solution (linkway 2000) but we have a limitation about the bandwidth on a TFTP, FTP and RTSP transfer. for instance, on an FTP or TFTP transfer, we are up to 80 kbps on each to session. That is to say, if I open 4 FTP sessions, I am able to transfer 4 different files at each 80 kbps. The purpose is to be able for me to transfer in one session up to 2 Mbps (my bandwidth on the sattelite) I am using Windows 98 on each point of the connection. Is anybody can help me ? a++ Thomas Wiard thomas.wiard@radiofrance.com phone : +33 1 42 30 18 66 mobile : +33 6 14 98 69 63 From owner-tcpsat@lerc.nasa.gov Wed Feb 23 06:43: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 GAA18619; Wed, 23 Feb 2000 06:43:34 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA22378 for tcpsat-outgoing; Wed, 23 Feb 2000 06:03:12 -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 GAA22357 for ; Wed, 23 Feb 2000 06:03:09 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA29102; Wed, 23 Feb 2000 06:03:09 -0500 (EST) Received: from ss3000e.cselt.it(163.162.41.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029091; Wed, 23 Feb 00 06:03:03 -0500 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0FQD004GCQG5LO@ss3000e.cselt.it> for tcpsat@grc.nasa.gov; Wed, 23 Feb 2000 11:57:41 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2448.0) id <1805Z3HW>; Wed, 23 Feb 2000 12:01:51 +0100 Content-return: allowed Date: Wed, 23 Feb 2000 12:01:25 +0100 From: Lovisolo Piero Subject: RE: Network Simulation Tools To: "'Marc Emmelmann'" , "'tcpsat@grc.nasa.gov'" , "'Shvodian, Bill'" Message-id: <69A4AB2CD710D211A0AF00805FA6EAF120F165@xrr3.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I agree, we use OPNET TCP model in our research and works fine, moreover OPNET has an STK interface su you can model satellite constellation using STK and import it into OPNET. Piero Lovisolo > ---------- > From: Shvodian, Bill[SMTP:bill.shvodian@lmco.com] > Sent: Tuesday, February 22, 2000 8:28 PM > To: 'Marc Emmelmann'; 'tcpsat@grc.nasa.gov' > Subject: RE: Network Simulation Tools > > Marc, OPNET supports the different flavors of TCP, and it provides some > LEO > models as user contributed models. I have never used the LEO models, so I > can't comment on their usefulness. > > http://www.mil3.com > > Bill Shvodian > > > -----Original Message----- > > From: Marc Emmelmann [SMTP:emmelmann@fokus.gmd.de] > > Sent: Tuesday, February 22, 2000 10:50 AM > > To: 'tcpsat@grc.nasa.gov' > > Subject: Network Simulation Tools > > > > Hello, > > > > I need to run some experiments / simulations with TCP/IP in a LEO > > Satellite environment. My special interest is on how the different TCP > > flavors behave in the context of time-varying round trip delays. > > > > I am planing to use the NS Network Simulator (ns2) for my trials and > > would like to ask if any of you has a suggestion about other simulator I > > should considder or (even better) has a pointer to previous work by some > > one else. > > > > Thanks for your reply, > > > > Marc > > > > -- > > German National Research Research Center for > > Center for Information Technology Open Communication Systems > > > > Marc Emmelmann Phone: +49-30-34 63 - 7265 > > GMD-FOKUS Fax: +49-30-34 63 - 8265 > > Kaiserin-Augusta-Allee 31 e-mail: emmelmann@fokus.gmd.de > > D-10589 Berlin, Germany http://www.fokus.gmd.de > > > > PGP Fingerprint: 9858 95FA 0705 9D81 AB2A EE64 5D7F CEBA 2943 2BD5 > From owner-tcpsat@lerc.nasa.gov Wed Feb 23 12:32: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 MAA27850; Wed, 23 Feb 2000 12:32:20 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA04576 for tcpsat-outgoing; Wed, 23 Feb 2000 11:27:30 -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 LAA04537 for ; Wed, 23 Feb 2000 11:27:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA07229; Wed, 23 Feb 2000 11:27:24 -0500 (EST) Received: from kickme.cisco.com(198.92.30.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006933; Wed, 23 Feb 00 11:27:06 -0500 Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA05911; Wed, 23 Feb 2000 08:16:40 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id IAA28165; Wed, 23 Feb 2000 08:32:07 -0800 Message-Id: <4.1.20000223080519.00ade900@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 23 Feb 2000 08:07:50 -0800 To: "Thomas Wiard" From: Fred Baker Subject: Re: bandwidth on VSAT transfer Cc: tcpsat@grc.nasa.gov, sylvain.petit@radiofrance.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 11:06 AM 2/23/00 +0100, Thomas Wiard wrote: >Is anybody can help me ? bottom line is that TCP will move one window per round trip, and it starts at a pretty small amount. It sounds like your TCP is not using large windows (RFC 1323) or is not using SACK (RFC 2018). From owner-tcpsat@lerc.nasa.gov Wed Feb 23 13:32:13 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 NAA29447; Wed, 23 Feb 2000 13:32:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA17397 for tcpsat-outgoing; Wed, 23 Feb 2000 12:43:28 -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 MAA17373 for ; Wed, 23 Feb 2000 12:43:26 -0500 (EST) From: fred@iprg.nokia.com Received: by seraph3.lerc.nasa.gov; id MAA18725; Wed, 23 Feb 2000 12:43:25 -0500 (EST) Received: from mailhost.iprg.nokia.com(205.226.5.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018687; Wed, 23 Feb 00 12:43:00 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16061 for ; Wed, 23 Feb 2000 09:43:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA18182 for ; Wed, 23 Feb 2000 09:42:59 -0800 X-Virus-Scanned: Wed, 23 Feb 2000 09:42:59 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (vienna.iprg.nokia.com [205.226.11.35]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma017673; Wed, 23 Feb 00 09:42:45 -0800 Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id JAA00520 for tcpsat@lerc.nasa.gov; Wed, 23 Feb 2000 09:42:45 -0800 (PST) Date: Wed, 23 Feb 2000 09:42:45 -0800 (PST) Message-Id: <200002231742.JAA00520@vienna.iprg.nokia.com> To: tcpsat@lerc.nasa.gov Subject: INFOCOM 2000: Last week for early registration Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk >>>>> INFOCOM 2000 - LAST WEEK FOR EARLY REGISTRATION <<<<< CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT ========= Early registration cut-off date: February 28, 2000 (last week) Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-tcpsat@lerc.nasa.gov Wed Feb 23 13:52: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 NAA29861; Wed, 23 Feb 2000 13:51:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21166 for tcpsat-outgoing; Wed, 23 Feb 2000 13:06:02 -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 NAA21146 for ; Wed, 23 Feb 2000 13:06:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA21934; Wed, 23 Feb 2000 13:05:58 -0500 (EST) Received: from fb02.eng00.mindspring.net(207.69.229.20) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021828; Wed, 23 Feb 00 13:05:52 -0500 Received: from dave2 (user-2iveo76.dialup.mindspring.com [165.247.96.230]) by fb02.eng00.mindspring.net (8.9.3/8.8.5) with SMTP id NAA25740; Wed, 23 Feb 2000 13:05:45 -0500 (EST) Reply-To: From: "David R. Beering" To: "Thomas Wiard" Cc: , Subject: RE: bandwidth on VSAT transfer Date: Wed, 23 Feb 2000 12:05:50 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Thomas: As an addendum to Fred's note ... We did some testing about a year ago with the NetManage FTP Software product. It is a third-party TCP stack for Win98 that supports RFC1323. See to recall that we were getting something like 120 Mbps single-stream over a GEO delay simulator. It is my understanding that NetManage has most of the 'knobs' to tweak the TCP parameters (window size, timers, etc.) exposed to the user, so this should be relatively straightforward. Good luck. Dave Beering -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Thomas Wiard Sent: Wednesday, February 23, 2000 4:07 AM To: tcpsat@grc.nasa.gov Cc: sylvain.petit@radiofrance.com Subject: bandwidth on VSAT transfer Hi from France. we are testing the Comsat VSAT solution (linkway 2000) but we have a limitation about the bandwidth on a TFTP, FTP and RTSP transfer. for instance, on an FTP or TFTP transfer, we are up to 80 kbps on each to session. That is to say, if I open 4 FTP sessions, I am able to transfer 4 different files at each 80 kbps. The purpose is to be able for me to transfer in one session up to 2 Mbps (my bandwidth on the sattelite) I am using Windows 98 on each point of the connection. Is anybody can help me ? a++ Thomas Wiard thomas.wiard@radiofrance.com phone : +33 1 42 30 18 66 mobile : +33 6 14 98 69 63 From owner-tcpsat@lerc.nasa.gov Wed Feb 23 15:30:47 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 PAA02283; Wed, 23 Feb 2000 15:30:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA05034 for tcpsat-outgoing; Wed, 23 Feb 2000 14:30:58 -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 OAA05000 for ; Wed, 23 Feb 2000 14:30:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA04180; Wed, 23 Feb 2000 14:30:53 -0500 (EST) Received: from mailgw3a.lmco.com(192.35.35.24) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004162; Wed, 23 Feb 00 14:30:14 -0500 Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id OAA22760; Wed, 23 Feb 2000 14:30:13 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38886) id <0FQE00D01E6BKR@lmco.com>; Wed, 23 Feb 2000 11:30:12 -0800 (PST) Received: from emss01i01.ems.lmco.com ([129.197.181.68]) by lmco.com (PMDF V5.2-32 #38886) with ESMTP id <0FQE00D4FE66CE@lmco.com>; Wed, 23 Feb 2000 11:30:07 -0800 (PST) Received: by emss01i01.ems.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Feb 2000 11:29:59 -0800 Content-return: allowed Date: Wed, 23 Feb 2000 11:30:41 -0800 From: "Smith JR, Harry E" Subject: RE: bandwidth on VSAT transfer To: drbeering@sprynet.com, Thomas Wiard Cc: sylvain.petit@radiofrance.com, tcpsat@grc.nasa.gov Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT According to the TCP friendly Web site Win98 supports all of the needed items but you may need to set up these in the registry. Also I believe that I have seen indications that FTP servers default window size is 8K. This would limit you to 100Kbps per transfer. This could be the reason. As a side question, what is the reasons for establishing a single 2Mbps TCP session other than a large single large file transfer. I would think that most situations would have several TCP session operating in parallel. This should impact transfer much like interleaving. The result would be a lower total transfer time than in a single very large session. Harry Smith 408 428 6106 > -----Original Message----- > From: David R. Beering [SMTP:drbeering@sprynet.com] > Sent: Wednesday, February 23, 2000 10:06 AM > To: Thomas Wiard > Cc: sylvain.petit@radiofrance.com; tcpsat@grc.nasa.gov > Subject: RE: bandwidth on VSAT transfer > > > Thomas: > > As an addendum to Fred's note ... > > We did some testing about a year ago with the NetManage FTP Software > product. It is a third-party TCP stack for Win98 that supports RFC1323. > See > to recall that we were getting something like 120 Mbps single-stream over > a > GEO delay simulator. It is my understanding that NetManage has most of the > 'knobs' to tweak the TCP parameters (window size, timers, etc.) exposed to > the user, so this should be relatively straightforward. > > Good luck. > > Dave Beering > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Thomas Wiard > Sent: Wednesday, February 23, 2000 4:07 AM > To: tcpsat@grc.nasa.gov > Cc: sylvain.petit@radiofrance.com > Subject: bandwidth on VSAT transfer > > > Hi from France. > > we are testing the Comsat VSAT solution (linkway 2000) but we have a > limitation about the bandwidth on a TFTP, FTP and RTSP transfer. > > for instance, on an FTP or TFTP transfer, we are up to 80 kbps on each to > session. That is to say, if I open 4 FTP sessions, I am able to transfer > 4 > different files at each 80 kbps. > The purpose is to be able for me to transfer in one session up to 2 Mbps > (my > bandwidth on the sattelite) > > I am using Windows 98 on each point of the connection. > > Is anybody can help me ? > > > a++ > > Thomas Wiard > thomas.wiard@radiofrance.com > phone : +33 1 42 30 18 66 > mobile : +33 6 14 98 69 63 > From owner-tcpsat@lerc.nasa.gov Wed Feb 23 17:26:38 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 RAA03893; Wed, 23 Feb 2000 17:26:35 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA20506 for tcpsat-outgoing; Wed, 23 Feb 2000 16:08:35 -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 QAA20462 for ; Wed, 23 Feb 2000 16:08:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA18133; Wed, 23 Feb 2000 16:08:33 -0500 (EST) Received: from new-frontier-consulting-745192.cust-rtr.swbell.net(151.164.200.70) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018019; Wed, 23 Feb 00 16:07:47 -0500 Received: from houpdc.newf.com (mail.newf.com [216.62.131.2]) by ns.newf.com (8.9.3/8.9.3) with ESMTP id PAA15116; Wed, 23 Feb 2000 15:07:38 -0600 Received: from gdo (10.43.1.58) by houpdc.newf.com (Worldmail 1.3.167); 23 Feb 2000 15:07:38 -0600 Reply-To: From: "Greg Otto" To: , "'Thomas Wiard'" Cc: , Subject: RE: bandwidth on VSAT transfer Date: Wed, 23 Feb 2000 15:07:20 -0600 Message-ID: <001c01bf7e41$f9c56320$3a012b0a@newf.com> 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, Based on my experiences with the Microsoft FTP servers and clients, there are upper layer protocol limitations with respect to how it handles passing data from into the TCP layers. As a result, I concur with Dave on using non MS products to get your throughput. Also, TFTP is a single packet per RTT acknowledgement protocol. Thus, unless you want 512 byte/RTT throughput, you will NOT see anything better. Greg -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of David R. Beering Sent: Wednesday, February 23, 2000 12:06 PM To: Thomas Wiard Cc: sylvain.petit@radiofrance.com; tcpsat@grc.nasa.gov Subject: RE: bandwidth on VSAT transfer Thomas: As an addendum to Fred's note ... We did some testing about a year ago with the NetManage FTP Software product. It is a third-party TCP stack for Win98 that supports RFC1323. See to recall that we were getting something like 120 Mbps single-stream over a GEO delay simulator. It is my understanding that NetManage has most of the 'knobs' to tweak the TCP parameters (window size, timers, etc.) exposed to the user, so this should be relatively straightforward. Good luck. Dave Beering -----Original Message----- From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On Behalf Of Thomas Wiard Sent: Wednesday, February 23, 2000 4:07 AM To: tcpsat@grc.nasa.gov Cc: sylvain.petit@radiofrance.com Subject: bandwidth on VSAT transfer Hi from France. we are testing the Comsat VSAT solution (linkway 2000) but we have a limitation about the bandwidth on a TFTP, FTP and RTSP transfer. for instance, on an FTP or TFTP transfer, we are up to 80 kbps on each to session. That is to say, if I open 4 FTP sessions, I am able to transfer 4 different files at each 80 kbps. The purpose is to be able for me to transfer in one session up to 2 Mbps (my bandwidth on the sattelite) I am using Windows 98 on each point of the connection. Is anybody can help me ? a++ Thomas Wiard thomas.wiard@radiofrance.com phone : +33 1 42 30 18 66 mobile : +33 6 14 98 69 63 From owner-tcpsat@lerc.nasa.gov Wed Feb 23 18:22: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 SAA04741; Wed, 23 Feb 2000 18:22:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA28196 for tcpsat-outgoing; Wed, 23 Feb 2000 17:05: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 RAA28147 for ; Wed, 23 Feb 2000 17:05:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA26602; Wed, 23 Feb 2000 17:05:00 -0500 (EST) Received: from castor.ntd.comsat.com(134.133.80.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026578; Wed, 23 Feb 00 17:04:56 -0500 Received: from espresso.ntd.comsat.com (espresso.ntd.comsat.com [134.133.80.118]) by castor.ntd.comsat.com (8.9.1/8.9.1) with SMTP id RAA11851; Wed, 23 Feb 2000 17:04:37 -0500 (EST) Date: Wed, 23 Feb 2000 17:02:06 -0500 (EST) From: Nalin Mehta To: Greg Otto cc: drbeering@sprynet.com, "'Thomas Wiard'" , sylvain.petit@radiofrance.com, tcpsat@grc.nasa.gov Subject: RE: bandwidth on VSAT transfer In-Reply-To: <001c01bf7e41$f9c56320$3a012b0a@newf.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Thomas and Sylvain, I just chanced on a URL that might be useful to you if you are thinking of tweaking some of the TCP parameters in Windows 98 (and other OSes). I feel that if you increase the window size you will see an increase in throughput. The URL is: http://www.psc.edu/networking/perf_tune.html Regards, Nalin Mehta Comsat Labs, Clarksburg, MD 20871. Ph: 1-301-428-4582. On Wed, 23 Feb 2000, Greg Otto wrote: > Date: Wed, 23 Feb 2000 15:07:20 -0600 > From: Greg Otto > To: drbeering@sprynet.com, 'Thomas Wiard' > Cc: sylvain.petit@radiofrance.com, tcpsat@grc.nasa.gov > Subject: RE: bandwidth on VSAT transfer > > Thomas, > > Based on my experiences with the Microsoft FTP servers and clients, there > are upper layer protocol limitations with respect to how it handles passing > data from into the TCP layers. As a result, I concur with Dave on using non > MS products to get your throughput. > > Also, TFTP is a single packet per RTT acknowledgement protocol. Thus, > unless you want 512 byte/RTT throughput, you will NOT see anything better. > > Greg > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of David R. Beering > Sent: Wednesday, February 23, 2000 12:06 PM > To: Thomas Wiard > Cc: sylvain.petit@radiofrance.com; tcpsat@grc.nasa.gov > Subject: RE: bandwidth on VSAT transfer > > > > Thomas: > > As an addendum to Fred's note ... > > We did some testing about a year ago with the NetManage FTP Software > product. It is a third-party TCP stack for Win98 that supports RFC1323. See > to recall that we were getting something like 120 Mbps single-stream over a > GEO delay simulator. It is my understanding that NetManage has most of the > 'knobs' to tweak the TCP parameters (window size, timers, etc.) exposed to > the user, so this should be relatively straightforward. > > Good luck. > > Dave Beering > > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Thomas Wiard > Sent: Wednesday, February 23, 2000 4:07 AM > To: tcpsat@grc.nasa.gov > Cc: sylvain.petit@radiofrance.com > Subject: bandwidth on VSAT transfer > > > Hi from France. > > we are testing the Comsat VSAT solution (linkway 2000) but we have a > limitation about the bandwidth on a TFTP, FTP and RTSP transfer. > > for instance, on an FTP or TFTP transfer, we are up to 80 kbps on each to > session. That is to say, if I open 4 FTP sessions, I am able to transfer 4 > different files at each 80 kbps. > The purpose is to be able for me to transfer in one session up to 2 Mbps (my > bandwidth on the sattelite) > > I am using Windows 98 on each point of the connection. > > Is anybody can help me ? > > > a++ > > Thomas Wiard > thomas.wiard@radiofrance.com > phone : +33 1 42 30 18 66 > mobile : +33 6 14 98 69 63 From owner-tcpsat@lerc.nasa.gov Thu Feb 24 12:18: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 MAA06269; Thu, 24 Feb 2000 12:18:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA18175 for tcpsat-outgoing; Thu, 24 Feb 2000 11:26:57 -0500 (EST) 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 LAA18167; Thu, 24 Feb 2000 11:26:54 -0500 (EST) Message-Id: <200002241626.LAA18167@lombok-fi.lerc.nasa.gov> To: Marc Emmelmann From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'tcpsat@grc.nasa.gov'" Subject: Re: Network Simulation Tools Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: For What It's Worth Date: Thu, 24 Feb 2000 11:26:54 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > I need to run some experiments / simulations with TCP/IP in a LEO > Satellite environment. My special interest is on how the different > TCP flavors behave in the context of time-varying round trip > delays. > > I am planing to use the NS Network Simulator (ns2) for my trials > and would like to ask if any of you has a suggestion about other > simulator I should considder or (even better) has a pointer to > previous work by some one else. A flog... Picking a simulator or testing method is often a complex question. Aaron Falk and I offer up some things to think about when picking a software simulator in the following paper... Mark Allman, Aaron Falk. On the Effective Evaluation of TCP. ACM Computer Communication Review, 29(5), October 1999. http://roland.grc.nasa.gov/~mallman/papers/tcp-evaluation.ps Enjoy! allman From owner-tcpsat@lerc.nasa.gov Thu Feb 24 12:43:00 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 MAA07035; Thu, 24 Feb 2000 12:42:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA23121 for tcpsat-outgoing; Thu, 24 Feb 2000 11:58: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 LAA23091 for ; Thu, 24 Feb 2000 11:58:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA11165; Thu, 24 Feb 2000 11:58:45 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011126; Thu, 24 Feb 00 11:58:07 -0500 Received: from eta.cis.ohio-state.edu (mukul@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id LAA21847; Thu, 24 Feb 2000 11:58:06 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id LAA00745; Thu, 24 Feb 2000 11:58:06 -0500 (EST) X-Authentication-Warning: eta.cis.ohio-state.edu: mukul owned process doing -bs Date: Thu, 24 Feb 2000 11:58:05 -0500 (EST) From: mukul goyal cc: Marc Emmelmann , "'tcpsat@grc.nasa.gov'" Subject: Re: Network Simulation Tools In-Reply-To: <200002241626.LAA18167@lombok-fi.lerc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I have done some simulations on exactly the same topic. But we used ATM-UBR below TCP/IP. Please see http://www.cis.ohio-state.edu/~jain/atmf/a98-0876.htm Thanks, Mukul On Thu, 24 Feb 2000, Mark Allman wrote: > > > I need to run some experiments / simulations with TCP/IP in a LEO > > Satellite environment. My special interest is on how the different > > TCP flavors behave in the context of time-varying round trip > > delays. > > > > I am planing to use the NS Network Simulator (ns2) for my trials > > and would like to ask if any of you has a suggestion about other > > simulator I should considder or (even better) has a pointer to > > previous work by some one else. > > A flog... Picking a simulator or testing method is often a complex > question. Aaron Falk and I offer up some things to think about when > picking a software simulator in the following paper... > > Mark Allman, Aaron Falk. On the Effective Evaluation of TCP. ACM > Computer Communication Review, 29(5), October 1999. > http://roland.grc.nasa.gov/~mallman/papers/tcp-evaluation.ps > > Enjoy! > > allman > From owner-tcpsat@lerc.nasa.gov Thu Feb 24 12:44:16 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 MAA07060; Thu, 24 Feb 2000 12:44:10 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA23931 for tcpsat-outgoing; Thu, 24 Feb 2000 12:04:49 -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 MAA23905 for ; Thu, 24 Feb 2000 12:04:46 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12030; Thu, 24 Feb 2000 12:04:45 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011920; Thu, 24 Feb 00 12:04:05 -0500 Received: from eta.cis.ohio-state.edu (mukul@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA22473 for ; Thu, 24 Feb 2000 12:04:04 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA01267 for ; Thu, 24 Feb 2000 12:04:04 -0500 (EST) X-Authentication-Warning: eta.cis.ohio-state.edu: mukul owned process doing -bs Date: Thu, 24 Feb 2000 12:04:04 -0500 (EST) From: mukul goyal To: tcpsat@grc.nasa.gov Subject: Burstiness WIth increased max cwnd. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk With Window scaling in TCP, the back-to-back packets a TCP flow sends can be very high. I was wondering if there is some study evaluating the increase in burstiness of TCP traffic with larger cwnd. Or, in general, are there some papers talking about how bursty the traffic is as seen by a router? Thanks, Mukul From owner-tcpsat@lerc.nasa.gov Thu Feb 24 18:18:38 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 SAA12531; Thu, 24 Feb 2000 18:18:37 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA09990 for tcpsat-outgoing; Thu, 24 Feb 2000 17:32: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 RAA09971 for ; Thu, 24 Feb 2000 17:32:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA26430; Thu, 24 Feb 2000 17:32:48 -0500 (EST) Received: from sgi.sgi.com(192.48.153.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026414; Thu, 24 Feb 00 17:32:44 -0500 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 OAA01685; Thu, 24 Feb 2000 14:32:17 -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 OAA29988; Thu, 24 Feb 2000 14:32:08 -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 OAA69459; Thu, 24 Feb 2000 14:36:04 -0800 (PST) Message-Id: <200002242236.OAA69459@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mukul goyal Cc: tcpsat@grc.nasa.gov Subject: Re: Burstiness WIth increased max cwnd. From: Zachary Amsden In-Reply-To: Your message of "Thu, 24 Feb 2000 12:04:04 EST." Date: Thu, 24 Feb 2000 14:36:04 -0800 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Yes, there are many: M. Allman, C. Hayes, H. Krusem, and S. Ostermann TCP Performance over Satellite Links Proceedings of 5th International Conference on Telecommunication Systems M. Aron and P. Druschel Soft timers: efficient microsecond timer support for network processing Operating Systems Review 34(5), Dec. 1999 H. Balakirshnan, V.N Padmanabhan, R. H. Katz The Effects of Asymmetry on TCP Performance Proceedings of 3rd ACM Conference on Mobile Computing nand Networking W. C. Feng, D. D. Kandlur, D. Saha, and K. G. Shin. Understanding and improving TCP performance over networks with minimum rate guarantees IEEE/ACM Transactions on Networking, 7(2), Apr. 1999 V.N. Padmanabhan and R. H. Katz. TCP Fast Start: A Technique For Speeding Up Web Transfers Proceedings of the IEEE GLOBECOM '98 Conference, Nov 1998 V. Visweswaraiah and J. Heidermann. Improving restart of idle TCP connections. Technical Report 97-661, University of Southern California, Nov 1997 From owner-tcpsat@lerc.nasa.gov Thu Feb 24 19:02:25 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 TAA12951; Thu, 24 Feb 2000 19:02:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA13492 for tcpsat-outgoing; Thu, 24 Feb 2000 18:13: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 SAA13450 for ; Thu, 24 Feb 2000 18:13:21 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA01258; Thu, 24 Feb 2000 18:13:18 -0500 (EST) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma001206; Thu, 24 Feb 00 18:12:43 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13110 for ; Thu, 24 Feb 2000 15:12:42 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA18087 for ; Thu, 24 Feb 2000 15:12:43 -0800 (PST) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA09715 for ; Thu, 24 Feb 2000 15:12:41 -0800 (PST) Date: Thu, 24 Feb 2000 15:12:41 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: Burstiness WIth increased max cwnd. To: tcpsat@grc.nasa.gov In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > With Window scaling in TCP, the back-to-back packets a TCP flow sends > can be very high. I was wondering if there is some study evaluating the > increase in burstiness of TCP traffic with larger cwnd. Or, in general, > are there some papers talking about how bursty the traffic is as seen by a > router? Do you mean the bursty traffic after there is a dropped segment? If there is no dropped segment (including ACKs), TCP is as bursty as it is without window scaling, sending 3 segments for every ACK (assuming delayed ACK for every 2 segments). I believe many implementations now have some simple form of bursty control. And with SACK and various forms of NewReno, I think TCP is not as busrty as it used to be when there is no window scaling. K. Poon. kcpoon@eng.sun.com From owner-tcpsat@lerc.nasa.gov Thu Feb 24 22:05:53 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 WAA16101; Thu, 24 Feb 2000 22:05:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA25847 for tcpsat-outgoing; Thu, 24 Feb 2000 21:21:37 -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 VAA25826 for ; Thu, 24 Feb 2000 21:21:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA21162; Thu, 24 Feb 2000 21:21:33 -0500 (EST) Received: from deliverator.sgi.com(204.94.214.10) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020993; Thu, 24 Feb 00 21:20:49 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA06290; Thu, 24 Feb 2000 18:16:11 -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 SAA17329; Thu, 24 Feb 2000 18:20:41 -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 SAA70886; Thu, 24 Feb 2000 18:24:42 -0800 (PST) Message-Id: <200002250224.SAA70886@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Kacheong Poon Cc: tcpsat@grc.nasa.gov Subject: Re: Burstiness WIth increased max cwnd. From: Zachary Amsden In-Reply-To: Your message of "Thu, 24 Feb 2000 15:12:41 PST." Date: Thu, 24 Feb 2000 18:24:42 -0800 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > Do you mean the bursty traffic after there is a dropped segment? If there is > no dropped segment (including ACKs), TCP is as bursty as it is without window > scaling, sending 3 segments for every ACK (assuming delayed ACK for every 2 > segments). I believe many implementations now have some simple form of > bursty control. And with SACK and various forms of NewReno, I think TCP is > not as busrty as it used to be when there is no window scaling. > > K. Poon. > kcpoon@eng.sun.com TCP is still bursty over high bandwidth-delay product links while inflating the congestion window. Basically everything in the window is trasmitted at once, and when ACKs arrive, the process repeats with a larger window. Thus larger windows cause the burstiness to proceed for longer amounts of time. -- Zachary Amsden zamsden@engr.sgi.com (650) 933-6919 09U-510 Core Protocols From owner-tcpsat@lerc.nasa.gov Thu Feb 24 22:18: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 WAA16232; Thu, 24 Feb 2000 22:18:35 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA26755 for tcpsat-outgoing; Thu, 24 Feb 2000 21:38:52 -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 VAA26736 for ; Thu, 24 Feb 2000 21:38:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA22719; Thu, 24 Feb 2000 21:38:48 -0500 (EST) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022698; Thu, 24 Feb 00 21:38:44 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24273 for ; Thu, 24 Feb 2000 18:37:39 -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 SAA24630 for ; Thu, 24 Feb 2000 18:35:21 -0800 (PST) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA11384 for ; Thu, 24 Feb 2000 18:35:20 -0800 (PST) Date: Thu, 24 Feb 2000 18:35:15 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: Burstiness WIth increased max cwnd. To: tcpsat@grc.nasa.gov In-Reply-To: "Your message with ID" <200002250224.SAA70886@clock.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > TCP is still bursty over high bandwidth-delay product links while inflating > the congestion window. Basically everything in the window is trasmitted at > once, and when ACKs arrive, the process repeats with a larger window. Thus > larger windows cause the burstiness to proceed for longer amounts of time. What do you mean by "trasmitted at once?" TCP does not send the whole window all at once. Do you mean the case when after the link is idle for some time, TCP can send the whole window at once? I think this has been discussed before and the problem is an implementation bug. Joe Touch has a note on this. Or do you mean something else? Note that congestion window (cwnd) is inflated based on incoming ACKs. The rate of increase is determined by the rate of incoming ACKs. And for every ACKs, it can send up to 3 segments. This is the burstiness. And cwnd is reduced back to 1 (or 2 or 3 segments depending on whether the implementation uses larger slow start cwnd) after the link is idle. One exception is when there is segment dropped. But as I mentioned previously, I think it is not as bad as it used to be. There are other issues, say ACK compression, ... But I think a larger window does not make this worse than before. Please elaborate. K. Poon. kcpoon@eng.sun.com From owner-tcpsat@lerc.nasa.gov Thu Feb 24 22:19:14 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 WAA16246; Thu, 24 Feb 2000 22:19:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA27072 for tcpsat-outgoing; Thu, 24 Feb 2000 21: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 VAA27063 for ; Thu, 24 Feb 2000 21:44:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA23351; Thu, 24 Feb 2000 21:44:48 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023339; Thu, 24 Feb 00 21:44:28 -0500 Received: from eta.cis.ohio-state.edu (mukul@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id VAA26449; Thu, 24 Feb 2000 21:44:27 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id VAA17555; Thu, 24 Feb 2000 21:44:27 -0500 (EST) X-Authentication-Warning: eta.cis.ohio-state.edu: mukul owned process doing -bs Date: Thu, 24 Feb 2000 21:44:27 -0500 (EST) From: mukul goyal To: Kacheong Poon cc: tcpsat@grc.nasa.gov Subject: Re: Burstiness WIth increased max cwnd. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk No, I was not referring to burstiness after dropped segment. TCP may potentially send a large number of packets in rapid succession followed by a relatively large period of silence. This will happen if ACKs arrive in rapid succession. I am interested in studying this phenomenon and how frequent is this with both default and scaled window sizes. I was wondering if previous work exists on this topic. Also, I will be interested in knowing what are the burst control techniques currently being employed by various implementations. Thanks, Mukul On Thu, 24 Feb 2000, Kacheong Poon wrote: > > With Window scaling in TCP, the back-to-back packets a TCP flow sends > > can be very high. I was wondering if there is some study evaluating the > > increase in burstiness of TCP traffic with larger cwnd. Or, in general, > > are there some papers talking about how bursty the traffic is as seen by a > > router? > > Do you mean the bursty traffic after there is a dropped segment? If there is > no dropped segment (including ACKs), TCP is as bursty as it is without window > scaling, sending 3 segments for every ACK (assuming delayed ACK for every 2 > segments). I believe many implementations now have some simple form of > bursty control. And with SACK and various forms of NewReno, I think TCP is > not as busrty as it used to be when there is no window scaling. > > K. Poon. > kcpoon@eng.sun.com > > From owner-tcpsat@lerc.nasa.gov Fri Feb 25 01:22: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 BAA21825; Fri, 25 Feb 2000 01:22:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA06482 for tcpsat-outgoing; Fri, 25 Feb 2000 00:35:55 -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 AAA06478 for ; Fri, 25 Feb 2000 00:35:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id AAA09733; Fri, 25 Feb 2000 00:35:52 -0500 (EST) Received: from pneumatic-tube.sgi.com(204.94.214.22) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009721; Fri, 25 Feb 00 00:35:46 -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 VAA02467; Thu, 24 Feb 2000 21:38:47 -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 VAA78701; Thu, 24 Feb 2000 21:35:42 -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 VAA72361; Thu, 24 Feb 2000 21:39:43 -0800 (PST) Message-Id: <200002250539.VAA72361@clock.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Kacheong Poon Cc: tcpsat@grc.nasa.gov Subject: Re: Burstiness WIth increased max cwnd. From: Zachary Amsden In-Reply-To: Your message of "Thu, 24 Feb 2000 18:35:15 PST." Date: Thu, 24 Feb 2000 21:39:43 -0800 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > > TCP is still bursty over high bandwidth-delay product links while inflating > > the congestion window. Basically everything in the window is trasmitted at > > once, and when ACKs arrive, the process repeats with a larger window. Thus > > larger windows cause the burstiness to proceed for longer amounts of time. > > What do you mean by "trasmitted at once?" TCP does not send the whole window > all at once. Do you mean the case when after the link is idle for some time, > TCP can send the whole window at once? I think this has been discussed before > and the problem is an implementation bug. Joe Touch has a note on this. > > Or do you mean something else? Note that congestion window (cwnd) is inflated > based on incoming ACKs. The rate of increase is determined by the rate of > incoming ACKs. And for every ACKs, it can send up to 3 segments. This is > the burstiness. And cwnd is reduced back to 1 (or 2 or 3 segments depending > on whether the implementation uses larger slow start cwnd) after the link is > idle. > > One exception is when there is segment dropped. But as I mentioned > previously, I think it is not as bad as it used to be. There are other > issues, say ACK compression, ... But I think a larger window does not make > this worse than before. Please elaborate. I am talking about burstiness in slow start, while the congestion window is growing. When doing slow start, the small initial congestion window is transmitted fairly rapidly, then waits for ACKs. When the ACKs arrive, they arrive fairly rapidly as well, and the congestion window grows and again the same process occurs. If and when the window grows large enough that an ACK is received for the start of the window right after we send the last window chunk, the burstiness stops. But if the window never grows this large, then this equilibrium won't set in, and the connection remains bursty. I believe that is the type of burstiness Mukul was referring to. This is exacerbated when using high b*d links because many segments can be in the pipe, necessitating a larger window. In any case, no, TCP over high b*d links is not bursty at equilibrium, but with too small a window the connection appears very bursty unless rate-based clocking is used. Neither do large windows cause burstiness - too small windows cause burstiness. But it takes longer for the ideal window size to be reached when windows are large. -- Zachary Amsden zamsden@engr.sgi.com (650) 933-6919 09U-510 Core Protocols From owner-tcpsat@lerc.nasa.gov Fri Feb 25 04:54: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 EAA04231; Fri, 25 Feb 2000 04:54:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA18358 for tcpsat-outgoing; Fri, 25 Feb 2000 04:17:55 -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 EAA18351 for ; Fri, 25 Feb 2000 04:17:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA26694; Fri, 25 Feb 2000 04:17:53 -0500 (EST) Received: from bubble.ndsuk.com(194.216.129.248) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026689; Fri, 25 Feb 00 04:17:16 -0500 Received: from fennel.hedge.ndsuk.com (smtp.ndsuk.com [172.19.253.100]) by bubble.ndsuk.com (8.8.7/8.8.7) with ESMTP id JAA01301; Fri, 25 Feb 2000 09:16:42 GMT Received: by FENNEL with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Feb 2000 09:14:24 -0000 Message-ID: <61F1D33582A6D31183D300508B55CDAC6313@phantom.chil.ndsuk.com> From: "Samaraweera, Nihal" To: "'mukul goyal'" , tcpsat@grc.nasa.gov Subject: RE: Burstiness WIth increased max cwnd. Date: Fri, 25 Feb 2000 09:16:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is my favorite reference which explains the problem (please check the latest version from the IETF web). C. Partridge, 'ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering', IETF, draft-partridge-e2e-ackspacing-00.txt, July 1997. I also got some more explanation and simulation results: N.K.G. Samaraweera, 'Return Link Optimisation for Internet Service Provision Using DVB-S Networks', CCR, ACM SIGCOMM, volume 29, number 3, July 1999. http://www.acm.org/sigcomm/ccr/archive/1999/jul99/ccr-9907-samaraweera4.html . good luck!! nihal. -----Original Message----- From: mukul goyal [mailto:mukul@cis.ohio-state.edu] Sent: 24 February 2000 17:04 PM To: tcpsat@grc.nasa.gov Subject: Burstiness WIth increased max cwnd. With Window scaling in TCP, the back-to-back packets a TCP flow sends can be very high. I was wondering if there is some study evaluating the increase in burstiness of TCP traffic with larger cwnd. Or, in general, are there some papers talking about how bursty the traffic is as seen by a router? Thanks, Mukul From owner-tcpsat@lerc.nasa.gov Fri Feb 25 06:39: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 GAA05217; Fri, 25 Feb 2000 06:39:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA22288 for tcpsat-outgoing; Fri, 25 Feb 2000 06:04:25 -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 GAA22278 for ; Fri, 25 Feb 2000 06:04:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA04161; Fri, 25 Feb 2000 06:04:23 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004133; Fri, 25 Feb 00 06:03:59 -0500 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12OIXI-0006Kv-00; Fri, 25 Feb 2000 11:03:52 +0000 Date: Fri, 25 Feb 2000 11:03:48 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Samaraweera, Nihal" cc: "'mukul goyal'" , tcpsat@grc.nasa.gov Subject: RE: Burstiness WIth increased max cwnd. In-Reply-To: <61F1D33582A6D31183D300508B55CDAC6313@phantom.chil.ndsuk.com> 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-tcpsat@lerc.nasa.gov Precedence: bulk On Fri, 25 Feb 2000, Samaraweera, Nihal wrote: > This is my favorite reference which explains the problem (please check the > latest version from the IETF web). That's from July 1997, and internet drafts expire after six months. good luck finding a copy... L. > > C. Partridge, 'ACK Spacing for High Delay-Bandwidth Paths with Insufficient > Buffering', IETF, draft-partridge-e2e-ackspacing-00.txt, July 1997. > > I also got some more explanation and simulation results: > > N.K.G. Samaraweera, 'Return Link Optimisation for Internet Service Provision > > Using DVB-S Networks', CCR, ACM SIGCOMM, volume 29, number 3, July 1999. > http://www.acm.org/sigcomm/ccr/archive/1999/jul99/ccr-9907-samaraweera4.html > . > > good luck!! > nihal. > > -----Original Message----- > From: mukul goyal [mailto:mukul@cis.ohio-state.edu] > Sent: 24 February 2000 17:04 PM > To: tcpsat@grc.nasa.gov > Subject: Burstiness WIth increased max cwnd. > > > With Window scaling in TCP, the back-to-back packets a TCP flow sends > can be very high. I was wondering if there is some study evaluating the > increase in burstiness of TCP traffic with larger cwnd. Or, in general, > are there some papers talking about how bursty the traffic is as seen by a > router? > > Thanks, > Mukul > > PGP From owner-tcpsat@lerc.nasa.gov Fri Feb 25 07:56:59 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 HAA06407; Fri, 25 Feb 2000 07:56:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA25869 for tcpsat-outgoing; Fri, 25 Feb 2000 07:12:41 -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 HAA25855 for ; Fri, 25 Feb 2000 07:12:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA09640; Fri, 25 Feb 2000 07:12:39 -0500 (EST) Received: from smtp2.cluster.oleane.net(195.25.12.17) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009629; Fri, 25 Feb 00 07:12:30 -0500 Received: from oleane (dyn-1-1-148.Vin.dialup.oleane.fr [195.25.4.148]) by smtp2.cluster.oleane.net with SMTP id NAA65423; Fri, 25 Feb 2000 13:11:48 +0100 (CET) Message-ID: <001601bf7f89$01635f40$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: The VoDSL 2000 Conference Date: Fri, 25 Feb 2000 13:08:17 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01BF7F91.619E1A00" 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-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01BF7F91.619E1A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key = speakers, case studies: take a look at: = http://www.upperside.fr/bavodsl.htm =20 ------=_NextPart_000_0013_01BF7F91.619E1A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
The VoDSL 2000 Conference will stand = in Paris=20 next 28-31 March. Key speakers, case studies: take a look at:  http://www.upperside.fr/bavo= dsl.htm
 
 
------=_NextPart_000_0013_01BF7F91.619E1A00-- From owner-tcpsat@lerc.nasa.gov Fri Feb 25 08:36:33 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 IAA07303; Fri, 25 Feb 2000 08:36:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA27985 for tcpsat-outgoing; Fri, 25 Feb 2000 07:38:11 -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 HAA27958 for ; Fri, 25 Feb 2000 07:38:09 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA11895; Fri, 25 Feb 2000 07:38:09 -0500 (EST) Received: from qhars002.nortelnetworks.com(192.100.101.19) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011859; Fri, 25 Feb 00 07:37:58 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Fri, 25 Feb 2000 12:36:55 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Feb 2000 12:36:53 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050E10@zhard000.europe.nortel.com> From: "Julien Godard" To: "'L.Wood@eim.surrey.ac.uk'" Cc: "'tcpsat@grc.nasa.gov'" Subject: RE: Burstiness WIth increased max cwnd. Date: Fri, 25 Feb 2000 12:36:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7F8C.FCDFFD30" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7F8C.FCDFFD30 Content-Type: text/plain http://www.kashpureff.org/nic/drafts/draft-partridge-e2e-ackspacing-00.txt.h tml easy ! use eg altavista with the COMPLETE name of the file. Enjoy. > -----Original Message----- > From: Lloyd Wood [SMTP:l.wood@eim.surrey.ac.uk] > Sent: 25 February 2000 11:04 > To: Samaraweera, Nihal > Cc: 'mukul goyal'; > Subject: RE: Burstiness WIth increased max cwnd. > > On Fri, 25 Feb 2000, Samaraweera, Nihal wrote: > > > This is my favorite reference which explains the problem (please check > the > > latest version from the IETF web). > > That's from July 1997, and internet drafts expire after six months. > > good luck finding a copy... > > L. > > > > C. Partridge, 'ACK Spacing for High Delay-Bandwidth Paths with > Insufficient > > Buffering', IETF, draft-partridge-e2e-ackspacing-00.txt, July 1997. > > > > I also got some more explanation and simulation results: > > > > N.K.G. Samaraweera, 'Return Link Optimisation for Internet Service > Provision > > > > Using DVB-S Networks', CCR, ACM SIGCOMM, volume 29, number 3, July 1999. > > > > http://www.acm.org/sigcomm/ccr/archive/1999/jul99/ccr-9907-samaraweera4.ht > ml > > . > > > > good luck!! > > nihal. > > > > -----Original Message----- > > From: mukul goyal [mailto:mukul@cis.ohio-state.edu] > > Sent: 24 February 2000 17:04 PM > > To: tcpsat@grc.nasa.gov > > Subject: Burstiness WIth increased max cwnd. > > > > > > With Window scaling in TCP, the back-to-back packets a TCP flow sends > > can be very high. I was wondering if there is some study evaluating the > > increase in burstiness of TCP traffic with larger cwnd. Or, in general, > > are there some papers talking about how bursty the traffic is as seen by > a > > router? > > > > Thanks, > > Mukul > > > > > > PGP > > ------_=_NextPart_001_01BF7F8C.FCDFFD30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Burstiness WIth increased max cwnd.

http://www.kashpureff.org/nic/drafts/draft-partridge-e= 2e-ackspacing-00.txt.html
easy !
use eg altavista = with the COMPLETE name of the file. Enjoy.

    -----Original Message-----
    From:   Lloyd Wood = [SMTP:l.wood@eim.surrey.ac.uk]
    Sent:   25 February 2000 11:04
    To:     Samaraweera, Nihal
    Cc:     'mukul goyal';
    Subject:       = RE: Burstiness WIth increased max = cwnd.

    On Fri, 25 Feb 2000, Samaraweera, = Nihal wrote:

    > This is my favorite reference = which explains the problem (please check the
    > latest version from the IETF = web).

    That's from July 1997, and internet = drafts expire after six months.

    good luck finding a copy...

    L.
    >
    > C. Partridge, 'ACK Spacing for = High Delay-Bandwidth Paths with Insufficient
    > Buffering', IETF, = draft-partridge-e2e-ackspacing-00.txt, July 1997.
    >
    > I also got some more explanation = and simulation results:
    >
    > N.K.G. Samaraweera, 'Return Link = Optimisation for Internet Service Provision
    >
    > Using DVB-S Networks', CCR, ACM = SIGCOMM, volume 29, number 3, July 1999.
    > http://www.acm.org/sigcomm/ccr/archive/1999/jul99/ccr-= 9907-samaraweera4.html
    > .
    >
    > good luck!!
    > nihal.
    >
    > -----Original = Message-----
    > From: mukul goyal = [mailto:mukul@cis.ohio-state.edu= ]
    > Sent: 24 February 2000 17:04 = PM
    > To: tcpsat@grc.nasa.gov
    > Subject: Burstiness WIth = increased max cwnd.
    >
    >
    > With Window scaling in TCP, the = back-to-back packets a TCP flow sends
    > can be very high. I was = wondering if there is some study evaluating the
    > increase in burstiness of TCP = traffic with larger cwnd. Or, in general,
    > are there some papers talking = about how bursty the traffic is as seen by a
    > router?
    >
    > Thanks,
    > Mukul
    >
    >

    <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>


------_=_NextPart_001_01BF7F8C.FCDFFD30-- From owner-tcpsat@lerc.nasa.gov Fri Feb 25 09:15: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 JAA08309; Fri, 25 Feb 2000 09:15:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA03183 for tcpsat-outgoing; Fri, 25 Feb 2000 08:27:54 -0500 (EST) 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 IAA03175; Fri, 25 Feb 2000 08:27:51 -0500 (EST) Message-Id: <200002251327.IAA03175@lombok-fi.lerc.nasa.gov> To: Kacheong Poon From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tcpsat@grc.nasa.gov Subject: Re: Burstiness WIth increased max cwnd. Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Peaches Date: Fri, 25 Feb 2000 08:27:51 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > Or do you mean something else? Note that congestion window (cwnd) > is inflated based on incoming ACKs. The rate of increase is > determined by the rate of incoming ACKs. And for every ACKs, it > can send up to 3 segments. This is the burstiness. And cwnd is > reduced back to 1 (or 2 or 3 segments depending on whether the > implementation uses larger slow start cwnd) after the link is > idle. There really are two different "burstiness" definitions, I think. One is outlined above. That is, how many segments are sent in response to each ACK (a sort of "micro burstiness"). The other version would be a "macro burstiness", which is caused by ACKs arriving one right after another causing causing a large amount of data transmission (but, not at line rate). This is especially true on long-delay links. What you see during slow start is all the ACKs arriving at the beginning of the RTT, causing a macro burst of data packets, followed by a long idle period that we spend waiting for the ACKs. There is a nice paper that talks about these macro bursts.... Joanna Kulik, Robert Coulter, Dennis Rockwell, and Craig Partridge, "A Simulation Study of Paced TCP," BBN Technical Memorandum No. 1218, August 12, 1999. http://www.ir.bbn.com/documentation/techmemos/TM1218.ps http://www.ir.bbn.com/documentation/techmemos/TM1218.pdf allman --- http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@lerc.nasa.gov Fri Feb 25 15:57: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 PAA20478; Fri, 25 Feb 2000 15:57:22 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA05371 for tcpsat-outgoing; Fri, 25 Feb 2000 15:05:57 -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 PAA05337 for ; Fri, 25 Feb 2000 15:05:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA15581; Fri, 25 Feb 2000 15:05:43 -0500 (EST) Received: from castor.ntd.comsat.com(134.133.80.100) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015563; Fri, 25 Feb 00 15:05:23 -0500 Received: from espresso.ntd.comsat.com (espresso.ntd.comsat.com [134.133.80.118]) by castor.ntd.comsat.com (8.9.1/8.9.1) with SMTP id PAA03356; Fri, 25 Feb 2000 15:04:48 -0500 (EST) Date: Fri, 25 Feb 2000 15:02:20 -0500 (EST) From: Nalin Mehta Reply-To: Nalin Mehta To: "'Thomas Wiard'" , sylvain.petit@radiofrance.com cc: tcpsat@grc.nasa.gov, moorthy.hariharan@comsat.com, george.knizewski@comsat.com Subject: RE: bandwidth on VSAT transfer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Thomas and Sylvain, I did a quick test and found that with the ordinary FTP client on Windows 98 and FTP server on Solaris 2.6, the throughput for a large file (18228147 bytes) FTPed across a GEO based satellite (Intelsat) using COMSAT's Linkway 2000 IP product (that you referred to) was 741.84 kbps (on average) with Committed Allocation and 692.64 kbps (on average) with Bandwidth on Demand (with initial 64 kbps seed allocation). The reason that there is a comparatively low throughput with BoD is because of the chicken and egg problem faced with running TCP over a BoD, large delay system. The only difference between your setup and mine was that I used native IP from Linkway and you used IP over Frame Relay but this is not relevant to the case, I believe. I configured only two parameters to see such a change in throughput: the 'tcp_xmit_hiwat' param in Solaris and 'DefaultRcvWindow' in Windows 98. I believe (not sure!) that support for Large Windows is inherent to these two OSs by default. Both params were set to 64K. Compare these values with a DefaultRcvWindow size of 8K which would give a throughput of approx 80 kbps. Best regards, Nalin Mehta Linkway 2000 IP development team, Comsat Labs, Clarksburg, MD 20871. > > -----Original Message----- > > Hi from France. > > > > we are testing the Comsat VSAT solution (linkway 2000) but we have a > > limitation about the bandwidth on a TFTP, FTP and RTSP transfer. > > > > for instance, on an FTP or TFTP transfer, we are up to 80 kbps on each to > > session. That is to say, if I open 4 FTP sessions, I am able to transfer 4 > > different files at each 80 kbps. > > The purpose is to be able for me to transfer in one session up to 2 Mbps (my > > bandwidth on the sattelite) > > > > I am using Windows 98 on each point of the connection. > > > > Is anybody can help me ? > > > > Thomas Wiard > > thomas.wiard@radiofrance.com > > phone : +33 1 42 30 18 66 > > mobile : +33 6 14 98 69 63 From owner-tcpsat@lerc.nasa.gov Fri Feb 25 16:41:17 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 QAA21572; Fri, 25 Feb 2000 16:41:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12057 for tcpsat-outgoing; Fri, 25 Feb 2000 15:50:09 -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 PAA11998 for ; Fri, 25 Feb 2000 15:50:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA21830; Fri, 25 Feb 2000 15:50:04 -0500 (EST) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021739; Fri, 25 Feb 00 15:49:30 -0500 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10631 for ; Fri, 25 Feb 2000 12:49:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA01073 for ; Fri, 25 Feb 2000 12:49:27 -0800 (PST) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA00495 for ; Fri, 25 Feb 2000 12:49:26 -0800 (PST) Date: Fri, 25 Feb 2000 12:49:26 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: RE: Burstiness WIth increased max cwnd. To: tcpsat@grc.nasa.gov In-Reply-To: "Your message with ID" <61F1D33582A6D31183D300508B55CDAC6313@phantom.chil.ndsuk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > C. Partridge, 'ACK Spacing for High Delay-Bandwidth Paths with Insufficient > Buffering', IETF, draft-partridge-e2e-ackspacing-00.txt, July 1997. The latest version should be draft-rfced-exp-partridge-01.txt. > There really are two different "burstiness" definitions, I think. > One is outlined above. That is, how many segments are sent in > response to each ACK (a sort of "micro burstiness"). The other > version would be a "macro burstiness", which is caused by ACKs > arriving one right after another causing causing a large amount of > data transmission (but, not at line rate). This is especially true > on long-delay links. What you see during slow start is all the ACKs > arriving at the beginning of the RTT, causing a macro burst of data > packets, followed by a long idle period that we spend waiting for > the ACKs. There is a nice paper that talks about these macro > bursts.... I see what the "burst" is referred to here now. It is my English ): The problem is about the total number of TCP segments for a connection in the network at any time. And when TCP is in slow start, this number doubles for every RTT. So Mukul's question is how the network responds to this large number of segments. I have never considered this as a burst before... Thanks for clearing the "burst" definition. K. Poon. kcpoon@eng.sun.com From owner-tcpsat@lerc.nasa.gov Sat Feb 26 13:49: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 NAA17556; Sat, 26 Feb 2000 13:49:25 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13698 for tcpsat-outgoing; Sat, 26 Feb 2000 12:50:21 -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 MAA13684 for ; Sat, 26 Feb 2000 12:50:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA29171; Sat, 26 Feb 2000 12:50:19 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029102; Sat, 26 Feb 00 12:49:53 -0500 Received: from eta.cis.ohio-state.edu (mukul@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA20763 for ; Sat, 26 Feb 2000 12:49:52 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id MAA24723 for ; Sat, 26 Feb 2000 12:49:52 -0500 (EST) X-Authentication-Warning: eta.cis.ohio-state.edu: mukul owned process doing -bs Date: Sat, 26 Feb 2000 12:49:52 -0500 (EST) From: mukul goyal cc: tcpsat@grc.nasa.gov Subject: Lack of TCP self-clocking in practical networks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Hello All, Kindly give me your opinions about lack of self-clocking in TCP. I feel that TCP's self-clocking as illustrated in Van Jacobson's 1988 paper exists only if bottleneck link is a link of lower capacity (i.e. bandwidth) than other links. However, if bottleneck link has higher capacity than other links (i.e. the link is bottlenecked because a large number of flows are using it simulateneously), there is no self-clocking any more. I guess this is also a main reason why one needs some thing like paced TCP. (The other reason being significantly less buffer requirements with paced TCP.) Thanks, Mukul From owner-tcpsat@lerc.nasa.gov Sat Feb 26 16:58:20 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 QAA18992; Sat, 26 Feb 2000 16:58:19 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA20614 for tcpsat-outgoing; Sat, 26 Feb 2000 16:02: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 QAA20609 for ; Sat, 26 Feb 2000 16:02:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA12810; Sat, 26 Feb 2000 16:02:19 -0500 (EST) Received: from wolfe.bbn.com(128.89.2.232) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012698; Sat, 26 Feb 00 16:01:57 -0500 Received: from wolfe.bbn.com (localhost.127.in-addr.arpa [127.0.0.1]) by wolfe.bbn.com (8.8.8/8.8.6) with ESMTP id QAA02569; Sat, 26 Feb 2000 16:01:55 -0500 (EST) Message-Id: <200002262101.QAA02569@wolfe.bbn.com> To: mukul goyal cc: tcpsat@grc.nasa.gov Subject: Re: Lack of TCP self-clocking in practical networks In-reply-to: Your message of "Sat, 26 Feb 2000 12:49:52 EST." Date: Sat, 26 Feb 2000 16:01:55 -0500 From: Craig Partridge Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I feel that TCP's self-clocking as illustrated in Van Jacobson's 1988 paper exists only if bottleneck link is a link of lower capacity (i.e. bandwidth) than other links. However, if bottleneck link has higher capacity than other links (i.e. the link is bottlenecked because a large number of flows are using it simulateneously), there is no self-clocking any more. I don't think it is that simple Self clocking always occurs -- you inject a packet in response to an ack and the ack is telling you when the network has capacity for your new packet. The issue raised in your note is whether the spacing of the acks reflects the available bandwidth at the bottleneck. In most cases the answer is that it reflects bandwidth only imperfectly. Ack compression, queueing disciplines, etc., all conspire to muddy the spacing. Craig From owner-tcpsat@lerc.nasa.gov Sat Feb 26 17:09:03 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 RAA19121; Sat, 26 Feb 2000 17:09:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA20998 for tcpsat-outgoing; Sat, 26 Feb 2000 16:12: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 QAA20984 for ; Sat, 26 Feb 2000 16:12:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA13491; Sat, 26 Feb 2000 16:12:49 -0500 (EST) Received: from mail.cis.ohio-state.edu(164.107.115.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma013482; Sat, 26 Feb 00 16:12:44 -0500 Received: from eta.cis.ohio-state.edu (mukul@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id QAA27214; Sat, 26 Feb 2000 16:12:43 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.9.1/8.9.1) with ESMTP id QAA02602; Sat, 26 Feb 2000 16:12:43 -0500 (EST) X-Authentication-Warning: eta.cis.ohio-state.edu: mukul owned process doing -bs Date: Sat, 26 Feb 2000 16:12:43 -0500 (EST) From: mukul goyal To: Craig Partridge cc: tcpsat@grc.nasa.gov Subject: Re: Lack of TCP self-clocking in practical networks In-Reply-To: <200002262101.QAA02569@wolfe.bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Thanks for phrasing the problem in better terms. By "lack of self-clocking" I had meant ACK spacing not reflecting the fair share of the bandwidth at the bottleneck. But I guess this is not the correct usage of the term "self-clocking". Mukul On Sat, 26 Feb 2000, Craig Partridge wrote: > > I feel that TCP's self-clocking as illustrated in Van Jacobson's 1988 > paper exists only if bottleneck link is a link of lower capacity (i.e. > bandwidth) than other links. However, if bottleneck link has higher > capacity than other links (i.e. the link is bottlenecked because a large > number of flows are using it simulateneously), there is no self-clocking > any more. > > I don't think it is that simple > > Self clocking always occurs -- you inject a packet in response to an ack and > the ack is telling you when the network has capacity for your new packet. > > The issue raised in your note is whether the spacing of the acks reflects the > available bandwidth at the bottleneck. In most cases the answer is that > it reflects bandwidth only imperfectly. Ack compression, queueing disciplines, > etc., all conspire to muddy the spacing. > > Craig > From owner-tcpsat@lerc.nasa.gov Mon Feb 28 04:58: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 EAA02116; Mon, 28 Feb 2000 04:58:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA13641 for tcpsat-outgoing; Mon, 28 Feb 2000 03:54:18 -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 DAA13627; Mon, 28 Feb 2000 03:54:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA06603; Mon, 28 Feb 2000 03:54:16 -0500 (EST) Received: from leonis.nus.edu.sg(137.132.1.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006596; Mon, 28 Feb 00 03:54:05 -0500 Received: from engtanlk.nus.edu.sg ([137.132.204.177]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA18765; Tue, 22 Feb 2000 15:26:44 +0800 (SST) Message-ID: <005001bf7d06$a56fb320$b1cc8489@engtanlk.nus.edu.sg> From: "ICON'2000 Secretariat" To: Subject: Calling for your contribution! Date: Tue, 22 Feb 2000 15:26:39 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01BF7D49.B392F320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004D_01BF7D49.B392F320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 * Kindly ignore this email if you have received this before.=20 Thanks you for your kind attention. =20 The 8th IEEE International Conference On Networks will be held from=20 September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20 an international forum for experts to promote, share and discuss various = issues and developments in the broad field of computer and communication = networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for=20 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.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_004D_01BF7D49.B392F320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
*=20 Kindly ignore this email if you have received this before.=20
Thanks you for your kind = attention.
 

The 8th IEEE International Conference On Networks will be held from =

September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20

an international forum for experts to promote, share and discuss = various

issues and developments in the broad field of computer and = communication

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.comp.nus.edu.sg/~ic= on/

We look forward to your participation. Thank you.

Icon 2000 organizing=20 Committee

------=_NextPart_000_004D_01BF7D49.B392F320-- From owner-tcpsat@lerc.nasa.gov Tue Feb 29 05:58:13 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 FAA14438; Tue, 29 Feb 2000 05:58:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA04118 for tcpsat-outgoing; Tue, 29 Feb 2000 04:47:18 -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 EAA04114; Tue, 29 Feb 2000 04:47:17 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA07799; Tue, 29 Feb 2000 04:47:16 -0500 (EST) Received: from leonis.nus.edu.sg(137.132.1.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007791; Tue, 29 Feb 00 04:47:10 -0500 Received: from engtanlk.nus.edu.sg ([137.132.204.165]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA28647; Tue, 29 Feb 2000 15:06:20 +0800 (SST) Message-ID: <028401bf8284$44618940$a5cc8489@engtanlk.nus.edu.sg> From: "ICON'2000 Secretariat" To: Subject: 14 days to countdown! Have you submitted your papers??? Date: Tue, 29 Feb 2000 15:06:17 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0281_01BF82C7.5284C940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0281_01BF82C7.5284C940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 * Kindly ignore this email if you have received this before.=20 Thanks you for your kind attention. =20 The 8th IEEE International Conference On Networks will be held from=20 September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20 an international forum for experts to promote, share and discuss various = issues and developments in the broad field of computer and communication = networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for=20 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.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_0281_01BF82C7.5284C940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
*=20 Kindly ignore this email if you have received this before.=20
Thanks you for your kind = attention.
 

The 8th IEEE International Conference On Networks will be held from =

September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20

an international forum for experts to promote, share and discuss = various

issues and developments in the broad field of computer and = communication

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.comp.nus.edu.sg/~icon/

 

We look forward to your participation. Thank you.

Icon 2000 organizing Committee

 

= ------=_NextPart_000_0281_01BF82C7.5284C940--