From owner-tcpsat@grc.nasa.gov Wed May 2 04:54:31 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03960; Wed, 2 May 2001 04:54:30 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA06009; Wed, 2 May 2001 04:54:29 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005314; Wed, 2 May 01 04:53:05 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA08376 for tcpsat-outgoing; Wed, 2 May 2001 04:31:03 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA08363 for ; Wed, 2 May 2001 04:31:02 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA03279; Wed, 2 May 2001 04:31:00 -0400 Received: from oe5.law12.hotmail.com(64.4.18.109) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003255; Wed, 2 May 01 04:30:21 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 May 2001 01:30:21 -0700 X-Originating-IP: [4.48.136.110] From: "pr0t" To: Subject: Perl API for sat systems. Date: Wed, 2 May 2001 01:25:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0D2A6.C8BB5C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: X-OriginalArrivalTime: 02 May 2001 08:30:21.0019 (UTC) FILETIME=[202632B0:01C0D2E2] Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C0D2A6.C8BB5C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm very interested in Perl API for sat systems and was wondering if = anyone could direct me to some very usefull documents maybe in pdf = formatt, I'd really apperciate any information i can get, thank you. ------=_NextPart_000_000D_01C0D2A6.C8BB5C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm very interested in Perl API for sat = systems and=20 was wondering if anyone could direct me to some very usefull documents = maybe in=20 pdf formatt, I'd really apperciate any information i can get, thank=20 you.

------=_NextPart_000_000D_01C0D2A6.C8BB5C20-- From owner-tcpsat@grc.nasa.gov Wed May 2 06:44:36 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05040; Wed, 2 May 2001 06:44:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA22223; Wed, 2 May 2001 06:44:34 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021702; Wed, 2 May 01 06:43:30 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA14931 for tcpsat-outgoing; Wed, 2 May 2001 06:30:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA14058; Wed, 2 May 2001 06:15:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA14546; Wed, 2 May 2001 06:15:42 -0400 Received: from louie.udel.edu(128.175.2.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014527; Wed, 2 May 01 06:15:01 -0400 Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa16448; 2 May 2001 06:12 EDT Date: Wed, 2 May 2001 06:12:52 -0400 (EDT) From: Constantinos Dovrolis To: Constantinos Dovrolis Subject: CFP ICNP 2001 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk **** Reminder: The paper submission deadline is MAY 7 **** -------------------------------------------------------------------------- CALL FOR PAPERS -------------------------------------------------------------------------- 9th International Conference on Network Protocols (ICNP 2001) Mission Inn, Riverside, California November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Topics of interest include, but are not limited to: - network access - switching - routing - flow and congestion control - multimedia transport protocols - wireless and mobile networks - network security - web protocols and applications - electronic commerce - network management - interoperability, internetworking - home computing and networking - digital broadcasting - QoS and service differentiation - network measurements - protocols for distributed games - peer-to-peer communication protocols Important Dates: Paper Submission Deadline: May 7, 2001 Tutorial Submission Deadline: May 7, 2001 Notification of Acceptance: July 13, 2001 Camera Ready Due: August 8, 2001 Tutorials: November 11, 2001 Conference: November 12 - 14, 2001 Information for authors: Papers must be written in English, and they have to be in Postscript, PDF, or Word format. The complete manuscript should be no more than 12 pages of double-spaced text with 11pt fonts. If you have any questions, you can contact us at icnp@ics.uci.edu. To register and submit your paper, visit the URL: http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/ General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, ReefEdge, Inc Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia Technical Program Committee Alex Petrenko (CRIM, Computer Research Institute of Montreal) Ana Rosa CAVALLI (Institut National des Telecommunications, France) Mart, Molle (University of California, Riverside) Andrew T. Campbell (Columbia University) Bobby Bhattacharjee (University of Maryland) Christophe Diot (Sprint) Cormac J. Sreenan (University College, Cork, Ireland) David Hutchison (Lancaster University) David Su (National Institute of Standards and Technology) David, Yau (Computer Science, Purdue University) Edward Knightly (Rice University ) Ellen L. Hahne (AT&T Labs - Research) Geert Heijenk (Ericsson) Gene Tsudik (UC, Irvine) Geoffrey Xie (Naval Postgraduate School) Ernst W. Biersack (Institut EURECOM) Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden) Hartmut Koenig (BTU Cottbus, Germany Hasan Ural (University of Ottawa, Canada) Ibrahim Matta (Boston University) Jennifer Hou (Ohio State University) Jorg Lieberherr (University of Virginia) Jorge Cobb (The University of Texas at Dallas) Ken Calvert (University of Kentucky) Kevin Almeroth (UC-Santa Barbara) Kirshna Sivalingam (Washington State University / Jasmine Networks) Lars Wolf (University of Karlsruhe, Germany) Lixia Zhang (UCLA) Ljiljana Trajkovic (Simon Fraser University) Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY)) Marco Schneider (SBC Technology Resources Inc.) Martha Steenstrup (Stow Research L.L.C.) Martina Zittterbart (University of Karlsruhe, Germany) Masayuki Murata (Osaka University, Japan) Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.) Mohamed G. Gouda (University of Texas at Austin) Nalini Venkatasubramanian (University of California, Irvine) Chris Edmondson-Yurkanan (University of Texas) Ness B. Shroff (Purdue University) Nina Bhatti (Nokia) Robin Kravets (University of Illinois at Urbana-Champaign) Shigang Chen (Cisco Systems) Songwu Lu (UCLA) Stanislaw Budkowski (Institut National des Telecommunications (INT), France) Terry Todd (McMaster University, Canada) Teruo Higashino (Osaka University, Japan) Timothy Roscoe (Sprint Advanced Technology Labs) William Tezlaff (IBM T. J. Watson Research Center) Yoshiaki Kakuda (Hiroshima City University, Japan) Yow-Jian Lin (Bell Labs Research, Lucent Technologies) Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel) Sonia Fahmy (Ohio State University) ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs From owner-tcpsat@grc.nasa.gov Thu May 3 20:04:58 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15703; Thu, 3 May 2001 20:04:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA01190; Thu, 3 May 2001 20:04:57 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000622; Thu, 3 May 01 20:04:08 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA13282 for tcpsat-outgoing; Thu, 3 May 2001 19:50:09 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA13263; Thu, 3 May 2001 19:50:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA27305; Thu, 3 May 2001 19:50:06 -0400 Received: from marjan.fesb.hr(161.53.166.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027244; Thu, 3 May 01 19:49:21 -0400 Received: from localhost (softcom@localhost) by marjan.fesb.hr (8.9.3/8.9.3) with ESMTP id BAA26343; Fri, 4 May 2001 01:27:42 +0200 (MET DST) Date: Fri, 4 May 2001 01:27:42 +0200 (MET DST) From: SoftCOM To: softcom@fesb.hr Subject: SoftCOM 2001 Call for Papers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Dear Colleagues, Please accept our apologies if you receive multiple copies of this e-mail. We would appreciate your assistance in distributing this call for papers to your colleagues. All the details about the conference can be found at: http://www.fesb.hr/SoftCOM All the details about the conference related events can be found at: http://www.softcom.tel.hr *** CALL FOR PAPERS *** INTERNATIONAL CONFERENCE ON SOFTWARE, TELECOMMUNICATIONS AND COMPUTER NETWORKS Tentative date: October 09-12, 2001 Location: Split, Dubrovnik (Croatia); Ancona, Bari (Italy) SPONSORED BY: * IEEE COMSOC TC of Communications Software and TC of Communication Switching and Routing (Technical Cosponsor) * Ministry of Science and Technology of the Republic of Croatia * University of Split The 9th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2001), co-sponsored by the IEEE Communication Society (COMSOC), will be held aboard the ship "Marko Polo" traveling on the route Split (Croatia) - Ancona (Italy) - Bari (Italy) - Dubrovnik (Croatia). SoftCOM 2001 provides an open forum for communication technology researchers and engineers to discuss new and emerging systems, standards and services, and their applications in telecommunication and information systems. The Conference will feature world-known plenary speakers, tutorial presentations and several workshops. Each day of the conference the ship will be anchored in one of the ports on the route, and overnight it will sail towards the next destination. This provides participants with the opportunity to share ideas in close contact with their colleagues and to enjoy the pleasant and inspiring ambience while visiting the ports along the beautiful Adriatic coast. During the conference the car deck will serve as an exhibition arena for exhibitors of software and telecommunication products. Topics to be addressed include, but are not limited to the following: * Telecommunication Software Production, Tools, Evaluation and Languages * Object and Component Technologies in Telecommunication Software * Network Management, Control and Maintenance * Telecommunication Services Design and QoS * Internet Environments and Services * IP Based Networks and Services * High-Speed Protocols and Networks * Wireless Communications * Enterprise Networking * Multimedia Systems and Services * Computer Telephone Integration * Information Security * AI and Recognition Methods * Virtual Environments * Computer Methods in Biomedicine * Electromagnetic Compatibility Feature Topic: Bluetooth and Personal Area Networks In addition to general technical topics, this year, the prospective authors are cordially invited to submit tutorial or survey papers on present state and future developments in Bluetooth, Personal Area Networks and Wireless LANs. General Chair Juraj Buzolic, Croatian Telecom, Croatia International Program Committee Co-Chairs: Nikola Rozic, Dinko Begusic, University of Split, Croatia {rozic,begusic}@fesb.hr Horst Besier, Deutsche Telekom, Germany Branko Burmaz (Vice Chair), Croatian Telecom, Croatia Antun Caric, Ericsson - Nikola Tesla, Croatia Francis Grenez, University of Bruxelles, Belgium Gorazd Kandus, Jozef Stefan Institute, Slovenia Ignac Lovrek, University of Zagreb, Croatia Gottfried Luderer (Vice Chair), Arizona State University, USA Andrej Ljolje, AT&T, USA Ivan Mijacika, Ericsson - Nikola Tesla, Croatia Miljenko Mikuc, University of Zagreb, Croatia James F. Mollenauer, Technical Strategy Assoc., USA Stan Moyer, Telcordia, USA Algirdas Pakstas, University of North London, UK Nikola Pavesic, University of Ljubljana, Slovenia Branko Soucek, Iris, Italy Zarko Sutlar, Croatian Telecom, Croatia Rob Walters, Satin Information Services, UK Krzysztof Wesolowski, University of Poznan, Poland SoftCOM 2001 will feature general conference and the following: * Workshop on Software Engineering in Telecommunications * Workshop on Database Technologies at the Beginning of New Millennium * Workshop on Mind Brain Networks * Workshop on Component-Based Active Simulation Networks * Special Session on EMC in Communication Systems IEEE CONTACT: Gottfried Luderer, Arizona State University, USA (luderer@asu.edu) SECRETARY: Hrvoje Dujmic, University of Split, Croatia, (softcom@fesb.hr) SCHEDULE: Complete Manuscript Due: July 01, 2001 Notification of Acceptance: September 01, 2001 Camera-Ready Manuscript Due: September 15, 2001 AUTHOR KIT AND SUBMISSION INSTRUCTIONS: Please check the details at the http://www.fesb.hr/SoftCOM From owner-tcpsat@grc.nasa.gov Tue May 8 17:18:22 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@[198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07926; Tue, 8 May 2001 17:18:21 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA14385; Tue, 8 May 2001 17:18:21 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013830; Tue, 8 May 01 17:17:19 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA22422 for tcpsat-outgoing; Tue, 8 May 2001 17:01:41 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA20942; Tue, 8 May 2001 16:51:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA05310; Tue, 8 May 2001 16:51:18 -0400 Received: from louie.udel.edu(128.175.2.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005264; Tue, 8 May 01 16:50:29 -0400 Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa06531; 8 May 2001 16:48 EDT Date: Tue, 8 May 2001 16:47:08 -0400 (EDT) From: Constantinos Dovrolis To: Constantinos Dovrolis Subject: ICNP 2001 - Deadline extension Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk *** Note: The paper submission deadline has been extended to May 14, 5pm (your local time). There will be no further extensions after May 14. -------------------------------------------------------------------------- CALL FOR PAPERS -------------------------------------------------------------------------- 9th International Conference on Network Protocols (ICNP 2001) Mission Inn, Riverside, California November 11-14, 2001 http://www.cis.udel.edu/icnp2001/ In just eight years, ICNP has established itself as one of the premier conferences in the computer networking field. ICNP deals with all aspects of communication protocols, from design and specification, to verification, testing, performance analysis, and implementation. Protocol functions of interest include network access, switching, routing, flow and congestion control, multimedia transport, wireless and mobile networks, network security, web protocols and applications, electronic commerce, network management, interoperability, internetworking, home computing and networks and digital broadcasting. ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place filled with history. Riverside is located in the Sunny Southern California, 60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from Disney Land. The city is served by three nearby airports: Los Angeles, Ontario (California) and Orange County Airport. Topics of interest include, but are not limited to: - network access - switching - routing - flow and congestion control - multimedia transport protocols - wireless and mobile networks - network security - web protocols and applications - electronic commerce - network management - interoperability, internetworking - home computing and networking - digital broadcasting - QoS and service differentiation - network measurements - protocols for distributed games - peer-to-peer communication protocols Important Dates: Paper Submission Deadline: May 14, 2001 (NEW DEADLINE) Tutorial Submission Deadline: May 7, 2001 Notification of Acceptance: July 13, 2001 Camera Ready Due: August 8, 2001 Tutorials: November 11, 2001 Conference: November 12 - 14, 2001 Information for authors: Papers must be written in English, and they have to be in Postscript, PDF, or Word format. The complete manuscript should be no more than 12 pages of double-spaced text with 11pt fonts. If you have any questions, you can contact us at icnp@ics.uci.edu. To register and submit your paper, visit the URL: http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/ General Chair Satish K. Tripathi, University of California - Riverside Technical Program Co-Chairs Magda El Zarki, University of California, Irvine Klara Narhstedt, University of Illinois, Urbana-Champaign Tutorial Co-Chairs Pravin Bhagwat, ReefEdge, Inc Ed Knightly, Rice University Local Arrangement and Registration Co-Chairs Michalis Faloutsos, University of California - Riverside Srikant Krishnamurthy, University of California - Riverside Publicity Co-Chairs Constantinos Dovrolis, University of Delaware Samar Singh, La Trobe University, Australia Technical Program Committee Alex Petrenko (CRIM, Computer Research Institute of Montreal) Ana Rosa CAVALLI (Institut National des Telecommunications, France) Mart, Molle (University of California, Riverside) Andrew T. Campbell (Columbia University) Bobby Bhattacharjee (University of Maryland) Christophe Diot (Sprint) Cormac J. Sreenan (University College, Cork, Ireland) David Hutchison (Lancaster University) David Su (National Institute of Standards and Technology) David, Yau (Computer Science, Purdue University) Edward Knightly (Rice University ) Ellen L. Hahne (AT&T Labs - Research) Geert Heijenk (Ericsson) Gene Tsudik (UC, Irvine) Geoffrey Xie (Naval Postgraduate School) Ernst W. Biersack (Institut EURECOM) Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden) Hartmut Koenig (BTU Cottbus, Germany Hasan Ural (University of Ottawa, Canada) Ibrahim Matta (Boston University) Jennifer Hou (Ohio State University) Jorg Lieberherr (University of Virginia) Jorge Cobb (The University of Texas at Dallas) Ken Calvert (University of Kentucky) Kevin Almeroth (UC-Santa Barbara) Kirshna Sivalingam (Washington State University / Jasmine Networks) Lars Wolf (University of Karlsruhe, Germany) Lixia Zhang (UCLA) Ljiljana Trajkovic (Simon Fraser University) Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY)) Marco Schneider (SBC Technology Resources Inc.) Martha Steenstrup (Stow Research L.L.C.) Martina Zittterbart (University of Karlsruhe, Germany) Masayuki Murata (Osaka University, Japan) Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.) Mohamed G. Gouda (University of Texas at Austin) Nalini Venkatasubramanian (University of California, Irvine) Chris Edmondson-Yurkanan (University of Texas) Ness B. Shroff (Purdue University) Nina Bhatti (Nokia) Robin Kravets (University of Illinois at Urbana-Champaign) Shigang Chen (Cisco Systems) Songwu Lu (UCLA) Stanislaw Budkowski (Institut National des Telecommunications (INT), France) Terry Todd (McMaster University, Canada) Teruo Higashino (Osaka University, Japan) Timothy Roscoe (Sprint Advanced Technology Labs) William Tezlaff (IBM T. J. Watson Research Center) Yoshiaki Kakuda (Hiroshima City University, Japan) Yow-Jian Lin (Bell Labs Research, Lucent Technologies) Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel) Sonia Fahmy (Purdue University) ICNP Steering Committee Mostafa Ammar, Georgia Insitute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland, College Park Krishan Sabnani, Bell Labs From owner-tcpsat@grc.nasa.gov Wed May 16 11:14:41 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11149; Wed, 16 May 2001 11:14:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA20431; Wed, 16 May 2001 11:14:48 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019864; Wed, 16 May 01 11:13:37 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA29318 for tcpsat-outgoing; Wed, 16 May 2001 10:52:59 -0400 (EDT) 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 KAA24833; Wed, 16 May 2001 10:35:57 -0400 (EDT) Received: from katrinajoy (katrinajoy.lerc.nasa.gov [139.88.111.49]) by apataki-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA01441; Wed, 16 May 2001 10:35:56 -0400 (EDT) Message-Id: <4.2.1.20010516101110.00b41910@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 16 May 2001 10:42:14 -0400 To: tcpsat@grc.nasa.gov, pilc@grc.nasa.gov, end2end-interest@postel.org From: William Ivancic Subject: Network Emulator - Open Source Code is available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk The Ohio Network Emulator (ONE) application is being made available to outside researchers in a open source format. The product will be supported internally, and ideally, benefit from having the wider external distribution. For additional information and to download the code: http://irg.cs.ohiou.edu/one/ The ONE application is a network emulator that can be run on an off the shelf computer workstation. ONE provides an inexpensive way to perform the kinds of network emulation of interest in space network research. Effects that would be otherwise difficult or impossible to simulate (i.e. communication transit delays as seen by satellites and spacecraft) can be studied in the lab as new protocols are developed. Other capabilities include: variable propagation delay, Random Early Detection (RED), an active queue management strategy that attempts to improve performance and reduce the average queue length, and Bit Error Rate (BER) simulation (the injection of simulated noise into the data stream). The design is amenable to inclusion of other software controlled effects. ======================================= Will Ivancic NASA Glenn Research Center 21000 Brookpark Road MS 54-5 Cleveland, Ohio 44135 Phone +1 (216)433-3494 Fax +1 (216) 433-8705 http://ctd.lerc.nasa.gov/5610/5610.html From owner-tcpsat@grc.nasa.gov Wed May 16 18:03:26 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19950; Wed, 16 May 2001 18:03:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA19307; Wed, 16 May 2001 18:03:32 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018751; Wed, 16 May 01 18:03:02 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA25787 for tcpsat-outgoing; Wed, 16 May 2001 17:51:10 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA25770 for ; Wed, 16 May 2001 17:51:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA17129; Wed, 16 May 2001 17:51:07 -0400 Received: from s70.ucs.louisiana.edu(130.70.118.70) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017087; Wed, 16 May 01 17:50:59 -0400 Received: from s70.ucs.louisiana.edu (rxp2551@s70.ucs.louisiana.edu [130.70.118.70]) by s70.ucs.louisiana.edu (8.11.3/8.11.3/ull-ucs-client_1.5) with SMTP id f4GLowx02220; Wed, 16 May 2001 16:50:58 -0500 (CDT) Message-Id: <200105162150.f4GLowx02220@s70.ucs.louisiana.edu> Date: Wed, 16 May 2001 16:50:58 -0500 (CDT) From: Prasad Rajesh Reply-To: Prasad Rajesh Subject: information regarding use of TCP/IP in satellite communication To: tcpsat@lerc.nasa.gov Cc: vern@ee.lbl.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: u6JDerIQ+kotqgIwTb4kug== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Hello, I am a M.S(computer science) student at University of Lousiana,lafayetet.I am doing a project on TCP/IP use in long distance(satellite communication). Can you suggest from where I can get a free/cheap simulator in which i can simulate delay. Moreover can you suggest where i can get latest reserch information on this topic. My mail id is rxp2551@louisiana.edu BYE, Rajesh Prasad From owner-tcpsat@grc.nasa.gov Wed May 16 19:24:56 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21093; Wed, 16 May 2001 19:24:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA04978; Wed, 16 May 2001 19:25:03 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004475; Wed, 16 May 01 19:23:51 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA04419 for tcpsat-outgoing; Wed, 16 May 2001 19:12:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA04392 for ; Wed, 16 May 2001 19:12:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA02919; Wed, 16 May 2001 19:12:26 -0400 Received: from info.iet.unipi.it(131.114.9.184) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002905; Wed, 16 May 01 19:12:14 -0400 Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id BAA53614; Thu, 17 May 2001 01:09:17 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200105162309.BAA53614@info.iet.unipi.it> Subject: Re: information regarding use of TCP/IP in satellite communication In-Reply-To: <200105162150.f4GLowx02220@s70.ucs.louisiana.edu> from Prasad Rajesh at "May 16, 2001 04:50:58 pm" To: Prasad Rajesh Date: Thu, 17 May 2001 01:09:17 +0200 (CEST) CC: tcpsat@lerc.nasa.gov, vern@ee.lbl.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@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > > Hello, > I am a M.S(computer science) student at University of > Lousiana,lafayetet.I am doing a project on TCP/IP use in long > distance(satellite communication). > Can you suggest from where I can get a free/cheap simulator in which i > can simulate delay. one option is http://www.iet.unipi.it/~luigi/ip_dummynet/ (also part of FreeBSD) cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . ----------------------------------+----------------------------------------- From owner-tcpsat@grc.nasa.gov Thu May 17 10:55:31 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19077; Thu, 17 May 2001 10:55:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA20074; Thu, 17 May 2001 10:55:37 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019529; Thu, 17 May 01 10:54:56 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA23257 for tcpsat-outgoing; Thu, 17 May 2001 10:41:14 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA23223 for ; Thu, 17 May 2001 10:41:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA16589; Thu, 17 May 2001 10:41:07 -0400 Received: from mail.dcu.ie(136.206.1.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016513; Thu, 17 May 01 10:40:52 -0400 Received: from tolka.dcu.ie (136.206.1.9) by hawk.dcu.ie (5.5.031) id 3AF98EEA00028E16; Thu, 17 May 2001 15:40:59 +0100 Date: Thu, 17 May 2001 15:40:43 +0100 (BST) From: Colin Paul Gloster Reply-To: Colin_Paul_Gloster@acm.org To: Prasad Rajesh cc: tcpsat@lerc.nasa.gov, vern@ee.lbl.gov Subject: Re: information regarding use of TCP/IP in satellite communication In-Reply-To: <200105162309.BAA53614@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Also ONE was very recently announced on the list. If you can get your university to pay for a package then you could try one of the Radio versions of Mil3's OPNET. See HTTP://WWW.OPNET.com/services/university/home.html Also though it is not dedicated to satcoms, the free IP-oriented Network Simulator ns is capable of modelling "wireless (local and satellite) networks" and is used by for example the famous owner and helpful ns-users maillist contributor of the "Lloyd's satellite constellations" website. See HTTP://WWW.EE.Surrey.ac.UK/Personal/L.Wood/constellations/ HTTP://WWW.EE.Surrey.ac.UK/Personal/L.Wood/ns/ HTTP://WWW.ISI.edu/nsnam/archive/ns-users/webarch/current/maillist.html HTTP://WWW.ISI.edu/nsnam/ Good luck. "The Ohio Network Emulator (ONE) application is being made available to outside researchers in a open source format. The product will be supported internally, and ideally, benefit from having the wider external distribution. For additional information and to download the code: http://irg.cs.ohiou.edu/one/ The ONE application is a network emulator that can be run on an off the shelf computer workstation. ONE provides an inexpensive way to perform the kinds of network emulation of interest in space network research. Effects that would be otherwise difficult or impossible to simulate (i.e. communication transit delays as seen by satellites and spacecraft) can be studied in the lab as new protocols are developed. Other capabilities include: variable propagation delay, [..]" On Thu, 17 May 2001, Luigi Rizzo wrote: "> > Hello, > I am a M.S(computer science) student at University of > Lousiana,lafayetet.I am doing a project on TCP/IP use in long > distance(satellite communication). > Can you suggest from where I can get a free/cheap simulator in which i > can simulate delay. one option is http://www.iet.unipi.it/~luigi/ip_dummynet/ (also part of FreeBSD) cheers luigi" From owner-tcpsat@grc.nasa.gov Thu May 17 11:25:46 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19973; Thu, 17 May 2001 11:25:45 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA29245; Thu, 17 May 2001 11:25:53 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028707; Thu, 17 May 01 11:25:17 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA01129 for tcpsat-outgoing; Thu, 17 May 2001 11:15:16 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA01103 for ; Thu, 17 May 2001 11:15:15 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA26862; Thu, 17 May 2001 11:15:14 -0400 Received: from kamzik.pvt.sk(195.28.64.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026788; Thu, 17 May 01 11:14:18 -0400 Received: from maindata.sk (i00102-d32.pvt.sk [195.28.81.33]) by kamzik.pvt.sk (8.11.0/8.9.3) with ESMTP id f4HFEO353049 for ; Thu, 17 May 2001 17:14:24 +0200 (CEST) Message-ID: <3B03EA94.2CB64721@maindata.sk> Date: Thu, 17 May 2001 17:13:24 +0200 From: Dusan Statelov Reply-To: statelov@maindata.sk Organization: Main Data, s.r.o. (http://www.maindata.sk) X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: TCP performance Content-Type: multipart/mixed; boundary="------------051CF1AF2223CBBA77CA3091" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------051CF1AF2223CBBA77CA3091 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello: We are investigating reasons of poor TCP/ip performance over satellite. We expect to get single TCP/ip performance of Windows size/RTT but in a fact windows size does not influence performance at all. We are working ni Windows NT platform. In a LAN we get 180 kbyte/s the same system over sat falls to 25 kbyte/s RTT is 220 ms windows size set to 64 kbyte. I would appreciate your response and assistance. -- Best regards Dusan Statelov Managing Director Main Data,s.r.o. mailto:statelov@maindata.sk Tel: +421 7 54789 586 Fax: +421 7 54789 585 GSM: +421 905 606 027 http://www.maindata.sk --------------051CF1AF2223CBBA77CA3091 Content-Type: text/x-vcard; charset=us-ascii; name="statelov.vcf" Content-Description: Card for Dusan Statelov Content-Disposition: attachment; filename="statelov.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Statelov;Dusan x-mozilla-html:FALSE org:Main Data, s.r.o. adr:;;Senicka 23;Bratislava;;811 04;Slovakia version:2.1 email;internet:statelov@maindata.sk title:Managing Director tel;fax:+ 421 7 54789 585 tel;home:+ 421 905 606 027 tel;work:+ 421 7 54789 586 note:Hybrid-Net Intenret via Digital TV & Distance Tele Education x-mozilla-cpt:;0 fn:Dusan Statelov end:vcard --------------051CF1AF2223CBBA77CA3091-- From owner-tcpsat@grc.nasa.gov Thu May 17 11:57:03 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20806; Thu, 17 May 2001 11:57:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA11758; Thu, 17 May 2001 11:57:10 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011101; Thu, 17 May 01 11:56:27 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA08229 for tcpsat-outgoing; Thu, 17 May 2001 11:46:21 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA08218 for ; Thu, 17 May 2001 11:46:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA07117; Thu, 17 May 2001 11:46:18 -0400 Received: from isnt.uscga.edu(138.29.1.252) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006310; Thu, 17 May 01 11:45:26 -0400 Received: by isnt.uscga.edu with Internet Mail Service (5.5.2448.0) id ; Thu, 17 May 2001 11:45:11 -0400 Message-ID: From: "Johnson, Gregory LCDR" To: statelov@maindata.sk Cc: tcpsat@grc.nasa.gov Subject: RE: TCP performance Date: Thu, 17 May 2001 11:45:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk 220 ms seems pretty low - have you measured the actual RTT on the satellite link? What speed is the satellite link? What MTU size are you using? -Greg LCDR Gregory W. Johnson Ass't Prof. Electrical Engineering USCG Academy New London CT 860-444-8683 -----Original Message----- From: Dusan Statelov [mailto:statelov@maindata.sk] Sent: Thursday, May 17, 2001 11:13 AM To: tcpsat@grc.nasa.gov Subject: TCP performance Hello: We are investigating reasons of poor TCP/ip performance over satellite. We expect to get single TCP/ip performance of Windows size/RTT but in a fact windows size does not influence performance at all. We are working ni Windows NT platform. In a LAN we get 180 kbyte/s the same system over sat falls to 25 kbyte/s RTT is 220 ms windows size set to 64 kbyte. I would appreciate your response and assistance. -- Best regards Dusan Statelov Managing Director Main Data,s.r.o. mailto:statelov@maindata.sk Tel: +421 7 54789 586 Fax: +421 7 54789 585 GSM: +421 905 606 027 http://www.maindata.sk From owner-tcpsat@grc.nasa.gov Thu May 17 16:51:37 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26809; Thu, 17 May 2001 16:51:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA14163; Thu, 17 May 2001 16:51:41 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013546; Thu, 17 May 01 16:50:26 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA04535 for tcpsat-outgoing; Thu, 17 May 2001 16:37:01 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA04510 for ; Thu, 17 May 2001 16:37:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA11004; Thu, 17 May 2001 16:36:59 -0400 Received: from cc1011837-a.hwrd1.md.home.com(24.23.55.246) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010942; Thu, 17 May 01 16:36:45 -0400 Received: from lmco.com (cc887157-a.hwrd1.md.home.com [24.180.225.160]) by CC1011837-A.hwrd1.md.home.com (8.11.0/8.8.7) with ESMTP id f4HLHLs30052; Thu, 17 May 2001 17:17:21 -0400 Message-ID: <3B043740.CB46EE17@lmco.com> Date: Thu, 17 May 2001 16:40:32 -0400 From: Loay Oweis X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: statelov@maindata.sk CC: tcpsat@grc.nasa.gov Subject: Re: TCP performance References: <3B03EA94.2CB64721@maindata.sk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Please note that if your RTT is 220 ms, then your satellite link is not duplex. Should you have a hybrid network where your return channel is terrestrial and maybe dialup, then the window size may not be ideal for your forward channel. There are products which include tcp acceleration. One is upcoming from LMGT, LinkStar which will include tcp acceleration for upto a 10 Mbps rate. Loay Oweis Dusan Statelov wrote: > Hello: > > We are investigating reasons of poor TCP/ip performance over satellite. > > We expect to get single TCP/ip performance of Windows size/RTT but in a > fact windows size does not influence performance at all. > We are working ni Windows NT platform. > In a LAN we get 180 kbyte/s the same system over sat falls to 25 kbyte/s > > RTT is 220 ms windows size set to 64 kbyte. > > I would appreciate your response and assistance. > > -- > Best regards > > Dusan Statelov > Managing Director > Main Data,s.r.o. > mailto:statelov@maindata.sk > > Tel: +421 7 54789 586 > Fax: +421 7 54789 585 > GSM: +421 905 606 027 > http://www.maindata.sk -- --------------------------------------------------------------------- Loay Oweis Technical Director/CO Oweitech - Independent Consultants 4705 Hallowed Stream Ellicott City, MD 21042 301-332-3930 Voice 410-772-9573 Fax loay.oweis@oweitech.com From owner-tcpsat@grc.nasa.gov Fri May 18 09:02:19 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25657; Fri, 18 May 2001 09:02:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA28720; Fri, 18 May 2001 09:02:27 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028145; Fri, 18 May 01 09:01:17 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA16563 for tcpsat-outgoing; Fri, 18 May 2001 08:48:36 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA16554 for ; Fri, 18 May 2001 08:48:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA24796; Fri, 18 May 2001 08:48:34 -0400 Received: from ns.ems-t.ca(209.167.130.34) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024712; Fri, 18 May 01 08:48:07 -0400 Received: from ems-t.ca ([141.186.252.65]) by gateway.ems-t.ca with SMTP id <119051>; Fri, 18 May 2001 08:44:17 -0400 Received: from MONTREAL-Message_Server by ems-t.ca with Novell_GroupWise; Fri, 18 May 2001 08:47:20 -0400 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Fri, 18 May 2001 08:47:11 -0400 From: "Andrew-Mark Pether" To: statelov@maindata.sk Cc: tcpsat@grc.nasa.gov Subject: Re: TCP performance 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 IAA16559 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hello Maybe it would be useful to confirm we are talking GEO here and if that is true, the following from RFC 2488 maybe useful: "The propagation time for a radio signal to travel twice that distance (corresponding to a ground station directly below the satellite) is 239.6 milliseconds (ms) [Mar78]. For ground stations at the edge of the view area of the satellite, the distance traveled is 2 x 41,756 km for a total propagation delay of 279.0 ms [Mar78]. These delays are for one ground station-to-satellite-to-ground station route (or "hop"). Therefore, the propagation delay for a message and the corresponding reply (one round-trip time or RTT) could be at least 558 ms. The RTT is not based solely on satellite propagation time. The RTT will be increased by other factors in the network, such as the transmission time and propagation time of other links in the network path and queueing delay in gateways." So if the RTT (or even 1 hop) is 220ms this is not a GEO satellite link, nevermind full duplex or not. Andrew Pether, M.Eng. (pether.a@ems-t.ca) EMS Technologies, Space & Technology Group 21025 TRANS CANADA HIGHWAY STE-ANNE-DE-BELLEVUE, QUEBEC CANADA, H9X 3R2 >>> Dusan Statelov 05/17 11:13 am >>> Hello: We are investigating reasons of poor TCP/ip performance over satellite. We expect to get single TCP/ip performance of Windows size/RTT but in a fact windows size does not influence performance at all. We are working ni Windows NT platform. In a LAN we get 180 kbyte/s the same system over sat falls to 25 kbyte/s RTT is 220 ms windows size set to 64 kbyte. I would appreciate your response and assistance. -- Best regards Dusan Statelov Managing Director Main Data,s.r.o. mailto:statelov@maindata.sk Tel: +421 7 54789 586 Fax: +421 7 54789 585 GSM: +421 905 606 027 http://www.maindata.sk From owner-tcpsat@grc.nasa.gov Fri May 18 12:31:55 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00500; Fri, 18 May 2001 12:31:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA24660; Fri, 18 May 2001 12:32:04 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024066; Fri, 18 May 01 12:31:29 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA09322 for tcpsat-outgoing; Fri, 18 May 2001 12:16:54 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA09300 for ; Fri, 18 May 2001 12:16:52 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA20793; Fri, 18 May 2001 12:16:52 -0400 Received: from cliff.extant.net(12.17.197.35) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020578; Fri, 18 May 01 12:16:15 -0400 Received: from Pambos (dhcp-118-den.extant.net [12.17.197.118]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K4D0TD6B; Fri, 18 May 2001 10:16:14 -0600 Message-ID: <002901c0dfb5$dc640170$76c5110c@Pambos> From: "pambosc" To: , References: <3B03EA94.2CB64721@maindata.sk> Subject: Re: TCP performance Date: Fri, 18 May 2001 10:15:49 -0600 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.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Take a look at my reasearch and papers at www.ittc.ukans.edu/~ccharala/research.html Pambos ----- Original Message ----- From: "Dusan Statelov" To: Sent: Thursday, May 17, 2001 9:13 AM Subject: TCP performance > Hello: > > We are investigating reasons of poor TCP/ip performance over satellite. > > We expect to get single TCP/ip performance of Windows size/RTT but in a > fact windows size does not influence performance at all. > We are working ni Windows NT platform. > In a LAN we get 180 kbyte/s the same system over sat falls to 25 kbyte/s > > RTT is 220 ms windows size set to 64 kbyte. > > I would appreciate your response and assistance. > > > > -- > Best regards > > Dusan Statelov > Managing Director > Main Data,s.r.o. > mailto:statelov@maindata.sk > > Tel: +421 7 54789 586 > Fax: +421 7 54789 585 > GSM: +421 905 606 027 > http://www.maindata.sk > > From owner-tcpsat@grc.nasa.gov Fri May 18 18:08:25 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17439; Fri, 18 May 2001 18:08:24 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA28006; Fri, 18 May 2001 18:08:35 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027405; Fri, 18 May 01 18:07:43 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA05984 for tcpsat-outgoing; Fri, 18 May 2001 17:57:08 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA05957 for ; Fri, 18 May 2001 17:57:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA26090; Fri, 18 May 2001 17:57:05 -0400 Received: from mailout04.sul.t-online.com(194.25.134.18) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026050; Fri, 18 May 01 17:56:48 -0400 Received: from fwd05.sul.t-online.de by mailout04.sul.t-online.com with smtp id 150sF5-0005hQ-02; Fri, 18 May 2001 23:57:03 +0200 Received: from darkstar (333200001232-0042@[62.227.86.234]) by fwd05.sul.t-online.com with smtp id 150sFB-1kAoqmC; Fri, 18 May 2001 23:57:09 +0200 From: Rainer.Ruecker@t-online.de (=?US-ASCII?Q?Rainer_Rucker?=) To: Cc: Subject: RE: TCP performance Date: Sat, 19 May 2001 23:50:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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) In-Reply-To: <3B03EA94.2CB64721@maindata.sk> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Sender: 333200001232-0042@t-dialin.net Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit For Windows NT 4.0 you can make a hand tuning of the registry by modifying the following keys: You find the keys under HKLM\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters\ The Entries you can make are: - TcpRecvSegmentSize (DWORD value) - TcpWindowSize (DWORD value) - PathMTUDiscovery (DWORD value) Some time ago I speed up an 1 Mbps point to point link over satellite with this global settings. It should also be possible to set this values by Interface. Take a look at http://search.support.microsoft.com and www.microsoft.com/technet/winnt (see Q158474 / Q199946) where you find detailed information. If you are installing a network monitor and make a trace you should be able to see that these modifications are working or not. I use an application called IPPERF. With this application you can make a measurement of your throughput. There's also a hardware solution possible. I've tried the SkyX XR10 Gateway of www.mentat.com and it works good. But at least NT 4.0 is not the best OS for Satellite networking. At the moment I use W2k that support more options but my experience is that a hardware solution works better. Rainer Rucker -----Original Message----- From: owner-tcpsat@grc.nasa.gov [mailto:owner-tcpsat@grc.nasa.gov]On Behalf Of Dusan Statelov Sent: Donnerstag, 17. Mai 2001 17:13 To: tcpsat@grc.nasa.gov Subject: TCP performance Hello: We are investigating reasons of poor TCP/ip performance over satellite. We expect to get single TCP/ip performance of Windows size/RTT but in a fact windows size does not influence performance at all. We are working ni Windows NT platform. In a LAN we get 180 kbyte/s the same system over sat falls to 25 kbyte/s RTT is 220 ms windows size set to 64 kbyte. I would appreciate your response and assistance. -- Best regards Dusan Statelov Managing Director Main Data,s.r.o. mailto:statelov@maindata.sk Tel: +421 7 54789 586 Fax: +421 7 54789 585 GSM: +421 905 606 027 http://www.maindata.sk From owner-tcpsat@grc.nasa.gov Sat May 19 06:02:59 2001 Received: from seraph3.lerc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [198.118.142.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10679; Sat, 19 May 2001 06:02:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA23901; Sat, 19 May 2001 06:03:12 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023321; Sat, 19 May 01 06:02:27 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA10039 for tcpsat-outgoing; Sat, 19 May 2001 05:47:52 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA10027 for ; Sat, 19 May 2001 05:47:47 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA22293; Sat, 19 May 2001 05:47:47 -0400 Message-Id: <200105190947.FAA22293@seraph3.lerc.nasa.gov> Received: from qmail1.vsto.net(209.185.20.131) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022272; Sat, 19 May 01 05:46:52 -0400 Received: (qmail 23429 invoked by alias); Received: from unknown (HELO mps2) (206.79.140.180) by 0 with SMTP; 19 May 2001 02:46:50 -0700 Reply-To: joesat@visto.com From: "joe black" Subject: Re: TCP performance Date: Sat, 19 May 2001 02:47:16 -0700 X-Mailer: Visto To: statelov@maindata.sk, tcpsat@grc.nasa.gov, pambosc@earthlink.net MIME-Version: 1.0 X-Mailer: Visto Server Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id FAA10036 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit You make look into the issues of the satellite (uplink) bandwidth. There is always a maximum threshold of average queue size in the egress router which will limit the performace of incremental window size. -----Original Message----- From: pambosc pambosc@earthlink.net Sent: Fri, 18 May 2001 10:15:49 -0600 To: statelov@maindata.sk, tcpsat@grc.nasa.gov Subject: Re: TCP performance Take a look at my reasearch and papers at www.ittc.ukans.edu/~ccharala/research.html Pambos ----- Original Message ----- From: "Dusan Statelov" To: Sent: Thursday, May 17, 2001 9:13 AM Subject: TCP performance > Hello: > > We are investigating reasons of poor TCP/ip performance over satellite. > > We expect to get single TCP/ip performance of Windows size/RTT but in a > fact windows size does not influence performance at all. > We are working ni Windows NT platform. > In a LAN we get 180 kbyte/s the same system over sat falls to 25 kbyte/s > > RTT is 220 ms windows size set to 64 kbyte. > > I would appreciate your response and assistance. > > > > -- > Best regards > > Dusan Statelov > Managing Director > Main Data,s.r.o. > mailto:statelov@maindata.sk > > Tel: +421 7 54789 586 > Fax: +421 7 54789 585 > GSM: +421 905 606 027 > http://www.maindata.sk > > ___________________________________________________________________________ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot. From owner-tcpsat@grc.nasa.gov Mon May 28 10:09:21 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04778; Mon, 28 May 2001 10:09:20 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id KAA25041; Mon, 28 May 2001 10:09:35 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma024625; Mon, 28 May 01 10:08:33 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA03104 for tcpsat-outgoing; Mon, 28 May 2001 09:47:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA03097 for ; Mon, 28 May 2001 09:47:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA24729; Mon, 28 May 2001 09:47:22 -0400 Received: from kamzik.pvt.sk(195.28.64.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024711; Mon, 28 May 01 09:46:26 -0400 Received: from maindata.sk (i00102-d98.pvt.sk [195.28.81.99]) by kamzik.pvt.sk (8.11.0/8.9.3) with ESMTP id f4SDlQs74721 for ; Mon, 28 May 2001 15:47:26 +0200 (CEST) Message-ID: <3B12565E.CA5EBADD@maindata.sk> Date: Mon, 28 May 2001 15:45:02 +0200 From: Dusan Statelov Reply-To: statelov@maindata.sk Organization: Main Data, s.r.o. (http://www.maindata.sk) X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: Can you advice some TCP analyser - monitor SW for Linux or Windows ? Content-Type: multipart/alternative; boundary="------------61ED6E0EF62F1A300E7D41D7" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk --------------61ED6E0EF62F1A300E7D41D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear colleagues: Can you please advice URL to some TCP analyser - monitor SW for Linux or Windows ? We have installed Linux PC for TCP monitoring purposes and installed some TCP monitor to watch traffic from http://www.ethereal.com/ but SW does not provide us information about real "congestion window" influencing the TCP performance. We can see some values of window ranging between 63-64-65 kbyte, what is meaningless. I expect (due to TCP slow start alghorithm) to see congestion window growing from bottom almost from 0 to TCP window size so from 0-64 kbyte for any old TCP and this should correlate to real TCP performance. Thanks in advance. Best regards Dusan Statelov Managing Director Main Data,s.r.o. mailto:statelov@maindata.sk Tel: +421 7 54789 586 Fax: +421 7 54789 585 GSM: +421 905 606 027 http://www.maindata.sk --------------61ED6E0EF62F1A300E7D41D7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear colleagues:

Can you please advice URL to some TCP analyser - monitor SW for Linux or Windows ?

We have installed Linux PC for TCP monitoring purposes and installed some TCP monitor to watch traffic from http://www.ethereal.com/ but SW does not provide us information about real "congestion window" influencing the TCP performance.

We can see some values of window ranging between 63-64-65 kbyte, what is meaningless.
I expect (due to TCP slow start alghorithm) to see congestion window growing from bottom almost from 0 to TCP window size so from 0-64 kbyte for any old TCP and this should correlate to real TCP performance.

Thanks in advance.

Best regards

Dusan Statelov
Managing Director
Main Data,s.r.o.
mailto:statelov@maindata.sk

Tel:     +421 7 54789 586
Fax:     +421 7 54789 585
GSM:     +421 905 606 027
http://www.maindata.sk
--------------61ED6E0EF62F1A300E7D41D7-- From owner-tcpsat@grc.nasa.gov Mon May 28 11:18:19 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05304; Mon, 28 May 2001 11:18:17 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id LAA01027; Mon, 28 May 2001 11:18:35 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma000444; Mon, 28 May 01 11:17:40 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA06811 for tcpsat-outgoing; Mon, 28 May 2001 11:02:40 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA06802 for ; Mon, 28 May 2001 11:02:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA00469; Mon, 28 May 2001 11:02:37 -0400 Received: from kamzik.pvt.sk(195.28.64.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000436; Mon, 28 May 01 11:01:50 -0400 Received: from maindata.sk (i00102-d5.pvt.sk [195.28.81.6]) by kamzik.pvt.sk (8.11.0/8.9.3) with ESMTP id f4SF2os83075; Mon, 28 May 2001 17:02:51 +0200 (CEST) Message-ID: <3B126809.387590C8@maindata.sk> Date: Mon, 28 May 2001 17:00:26 +0200 From: Dusan Statelov Reply-To: statelov@maindata.sk Organization: Main Data, s.r.o. (http://www.maindata.sk) X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: How to reach Large TCP window in Win (2000) or Linux Content-Type: multipart/mixed; boundary="------------1AB5BC9169315246A79F6AED" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------1AB5BC9169315246A79F6AED Content-Type: multipart/alternative; boundary="------------64D8BCC7621030B956AAAFF2" --------------64D8BCC7621030B956AAAFF2 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Hello: As we are now in time pressure I would like ask you for advices how to properly configure Win2000 or Linux Http data server in order to achieve bigger TCP window and improve Single TCP connection from poor 20-30 kbyte/s (for RTT 240 ms) to according to us achievable 1 mbps. We have changed "Default Receive Window", but TCP is running at only 20-30 kbyte/s what would corresponde to 8 kbyte Window rather then to 64 kbyte. I assume there are other TCP registry entities which influence Sender Window. Here is a configuration emulating satellite internet: Http Data Server [Linux or Win2000] -> DVB/ip -> DVB-S Modulator -> L band output -> PC DVB board [SkyMedia - Telemann, TT DVB Technotrend] -> client PC [Win98] o---------------o connected to DVB/ip GW in return via LAN LAN RTT 20 ms Artefficial delay in DVB/ip GW 220 ms (in order to simulate long RTT for satellite) Windows98 Default Receive Window to max.values 65535 Data Sever Win2000 Default Receive Window to max.values 65535 (we tried even 0,5 Mbyte with no effect) RTT 240 ms Single TCP connection 20 - 30 kbyte/s Thanks in advance. Dusan Statelov Managing Director Main Data,s.r.o. mailto:statelov@maindata.sk Tel: +421 7 54789 586 Fax: +421 7 54789 585 GSM: +421 905 606 027 http://www.maindata.sk --------------64D8BCC7621030B956AAAFF2 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Hello:

As we are now in time pressure I would like ask you for advices how to properly configure Win2000 or Linux Http data server in order to achieve bigger TCP window and improve Single TCP connection from poor 20-30 kbyte/s (for RTT 240 ms) to according to us achievable 1 mbps.
We have changed "Default Receive Window", but TCP is running at only 20-30 kbyte/s what would corresponde to 8 kbyte Window rather then to 64 kbyte.
I assume there are other TCP registry entities which influence Sender Window.

Here is a configuration emulating satellite internet:

Http Data Server [Linux or Win2000] -> DVB/ip -> DVB-S Modulator -> L band output -> PC DVB board [SkyMedia - Telemann, TT DVB Technotrend] ->
client PC [Win98] o---------------o connected to DVB/ip GW in return via LAN
LAN RTT 20 ms
Artefficial delay in DVB/ip GW 220 ms (in order to simulate long RTT for satellite)

Windows98
Default Receive Window to max.values 65535
Data Sever Win2000
Default Receive Window to max.values 65535 (we tried even 0,5 Mbyte with no effect)
RTT 240 ms
Single TCP connection 20 - 30 kbyte/s

Thanks in advance.

Dusan Statelov
Managing Director
Main Data,s.r.o.
mailto:statelov@maindata.sk

Tel:     +421 7 54789 586
Fax:     +421 7 54789 585
GSM:     +421 905 606 027
http://www.maindata.sk
--------------64D8BCC7621030B956AAAFF2-- --------------1AB5BC9169315246A79F6AED Content-Type: text/x-vcard; charset=iso-8859-2; name="statelov.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dusan Statelov Content-Disposition: attachment; filename="statelov.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Statelov;Dusan x-mozilla-html:FALSE org:Main Data, s.r.o. adr:;;Senicka 23;Bratislava;;811 04;Slovakia version:2.1 email;internet:statelov@maindata.sk title:Managing Director tel;fax:+ 421 7 54789 585 tel;home:+ 421 905 606 027 tel;work:+ 421 7 54789 586 note:Hybrid-Net Intenret via Digital TV & Distance Tele Education x-mozilla-cpt:;0 fn:Dusan Statelov end:vcard --------------1AB5BC9169315246A79F6AED-- From owner-tcpsat@grc.nasa.gov Mon May 28 11:35:22 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05417; Mon, 28 May 2001 11:35:21 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id LAA04902; Mon, 28 May 2001 11:35:37 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma004561; Mon, 28 May 01 11:34:49 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA07945 for tcpsat-outgoing; Mon, 28 May 2001 11:22:51 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA07929 for ; Mon, 28 May 2001 11:22:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA02454; Mon, 28 May 2001 11:22:48 -0400 Received: from us-la-gate.interpacket.net(209.198.223.250) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002433; Mon, 28 May 01 11:22:37 -0400 Received: (qmail 14375 invoked from network); 28 May 2001 15:22:13 -0000 Received: from mrbig.la.interpacket.net (192.168.6.5) by bond.la.interpacket.net with SMTP; 28 May 2001 15:22:13 -0000 Received: from [192.168.4.223] (host-192-168-2-114.la.interpacket.net [192.168.2.114]) by mrbig.la.interpacket.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LC58WYCL; Mon, 28 May 2001 08:25:33 -0700 Mime-Version: 1.0 X-Sender: jonm@mrbig.la.interpacket.net Message-Id: In-Reply-To: <3B126809.387590C8@maindata.sk> References: <3B126809.387590C8@maindata.sk> Date: Mon, 28 May 2001 08:21:41 -0700 To: statelov@maindata.sk, tcpsat@grc.nasa.gov From: Jon Mansey Subject: Re: How to reach Large TCP window in Win (2000) or Linux Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk You need to increase the client's RECEIVE window, the server normally can scale up to quite large send windows by default. Make sure you enable SACK and RFC1323. Use TCPTune for this http://moat.nlanr.net/Software/TCPtune/ jm At 5:00 PM +0200 5/28/01, Dusan Statelov wrote: >Hello: > >As we are now in time pressure I would like ask you for advices how >to properly configure Win2000 or Linux Http data server in order to >achieve bigger TCP window and improve Single TCP connection from >poor 20-30 kbyte/s (for RTT 240 ms) to according to us achievable 1 >mbps. >We have changed "Default Receive Window", but TCP is running at only >20-30 kbyte/s what would corresponde to 8 kbyte Window rather then >to 64 kbyte. >I assume there are other TCP registry entities which influence Sender Window. > >Here is a configuration emulating satellite internet: > >Http Data Server [Linux or Win2000] -> DVB/ip -> DVB-S Modulator -> >L band output -> PC DVB board [SkyMedia - Telemann, TT DVB >Technotrend] -> >client PC [Win98] o---------------o connected to DVB/ip GW in return via LAN >LAN RTT 20 ms >Artefficial delay in DVB/ip GW 220 ms (in order to simulate long RTT >for satellite) > >Windows98 >Default Receive Window to max.values 65535 >Data Sever Win2000 >Default Receive Window to max.values 65535 (we tried even 0,5 Mbyte >with no effect) >RTT 240 ms >Single TCP connection 20 - 30 kbyte/s > >Thanks in advance. > >Dusan Statelov >Managing Director >Main Data,s.r.o. >mailto:statelov@maindata.sk > >Tel: +421 7 54789 586 >Fax: +421 7 54789 585 >GSM: +421 905 606 027 >http://www.maindata.sk > > >Content-Type: text/x-vcard; charset=iso-8859-2; > name="statelov.vcf" >Content-Transfer-Encoding: 7bit >Content-Description: Card for Dusan Statelov >Content-Disposition: attachment; > filename="statelov.vcf" > >Attachment converted: Macintosh HD:statelov.vcf 1 (TEXT/ttxt) (000CAF94) From owner-tcpsat@grc.nasa.gov Mon May 28 16:46:56 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07097; Mon, 28 May 2001 16:46:55 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id QAA22890; Mon, 28 May 2001 16:47:11 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma022342; Mon, 28 May 01 16:46:01 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA21911 for tcpsat-outgoing; Mon, 28 May 2001 16:35:40 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA21899 for ; Mon, 28 May 2001 16:35:39 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA26341; Mon, 28 May 2001 16:35:38 -0400 Received: from dfw-smtpout2.email.verio.net(129.250.36.42) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026327; Mon, 28 May 01 16:35:01 -0400 Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 154TjA-0006Bt-00; Mon, 28 May 2001 20:35:00 +0000 Received: from [161.58.1.88] (helo=shell2) by dfw-mmp2.email.verio.net with esmtp id 154Tiy-0002lo-00; Mon, 28 May 2001 20:34:48 +0000 Date: Mon, 28 May 2001 16:34:47 -0400 (EDT) From: Eric Travis To: Dusan Statelov cc: Subject: Re: How to reach Large TCP window in Win (2000) or Linux In-Reply-To: <3B126809.387590C8@maindata.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk I normally wouldn't ask these questions (and I do apologize), but since your data source is labeled as being an http server: Are you convinced that you are passing enough data during the life of the measured TCP connections to allow your congestion window to fully open? If yes, are you passing enough *additional* data to make the time spent in slow-start negligible when calculating the average throughput of the connection? How large are your test data flows? Tuning the TCP connection parameters is important, but that can only remove artificial bounds on performance. You still need to allow for TCP to probe for the capacity of the path; It could be that you simply aren't transferring enough data... Eric Eric Travis travis@gst.com On Mon, 28 May 2001, Dusan Statelov wrote: > Hello: > > As we are now in time pressure I would like ask you for advices how to > properly configure Win2000 or Linux Http data server in order to achieve > bigger TCP window and improve Single TCP connection from poor 20-30 > kbyte/s (for RTT 240 ms) to according to us achievable 1 mbps. > We have changed "Default Receive Window", but TCP is running at only > 20-30 kbyte/s what would corresponde to 8 kbyte Window rather then to 64 > kbyte. > I assume there are other TCP registry entities which influence Sender > Window. > > Here is a configuration emulating satellite internet: > > Http Data Server [Linux or Win2000] -> DVB/ip -> DVB-S Modulator -> L > band output -> PC DVB board [SkyMedia - Telemann, TT DVB Technotrend] -> > > client PC [Win98] o---------------o connected to DVB/ip GW in return > via LAN > LAN RTT 20 ms > Artefficial delay in DVB/ip GW 220 ms (in order to simulate long RTT for > satellite) > > Windows98 > Default Receive Window to max.values 65535 > Data Sever Win2000 > Default Receive Window to max.values 65535 (we tried even 0,5 Mbyte with > no effect) > RTT 240 ms > Single TCP connection 20 - 30 kbyte/s > > Thanks in advance. > > Dusan Statelov > Managing Director > Main Data,s.r.o. > mailto:statelov@maindata.sk > > Tel: +421 7 54789 586 > Fax: +421 7 54789 585 > GSM: +421 905 606 027 > http://www.maindata.sk > > From owner-tcpsat@grc.nasa.gov Tue May 29 04:26:50 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27381; Tue, 29 May 2001 04:26:49 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id EAA01524; Tue, 29 May 2001 04:27:06 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma000947; Tue, 29 May 01 04:25:47 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA24742 for tcpsat-outgoing; Tue, 29 May 2001 04:13:48 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA24716; Tue, 29 May 2001 04:13:46 -0400 (EDT) From: Robert_Smith@ses-astra.com Received: by seraph3.lerc.nasa.gov; id EAA17143; Tue, 29 May 2001 04:13:46 -0400 Received: from bonnie.ses-astra.com(194.154.219.59) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017115; Tue, 29 May 01 04:12:57 -0400 Received: from margebck.gen.btz.aia.lu (margebck.gen.btz.aia.lu [193.168.96.12]) by bonnie.aia.lu (8.9.0/8.9.0) with ESMTP id KAA00978; Tue, 29 May 2001 10:17:06 +0200 (MET DST) Subject: Re: How to reach Large TCP window in Win (2000) or Linux To: statelov@maindata.sk Cc: owner-tcpsat@grc.nasa.gov, tcpsat@grc.nasa.gov X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 29 May 2001 10:09:41 +0200 X-MIMETrack: Serialize by Router on margebck/BTZ(Release 5.0.6 |December 14, 2000) at 05/29/2001 10:12:38 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256A5B002C3B2A8f9e8a93df938690918cC1256A5B002C3B2A" Content-Disposition: inline Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk --0__=C1256A5B002C3B2A8f9e8a93df938690918cC1256A5B002C3B2A Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, To enable large window size in Win2000: create a reg key (DWORD): HKEY_LOCALMACHINE\system\currentcontrolset\services\tcpip\parameters\tc= pwindowsize and set it to something larger than 65535 (I use 200000 for a RTT of ap= prox 500ms). On Linux: (2.2) for send window echo 200000 > /proc/sys/net/core/wmem_default echo 200000 > /proc/sys/net/core/wmem_max for receive window echo 200000 > /proc/sys/net/core/rmem_default echo 200000 > /proc/sys/net/core/rmem_max Sack and timestamping are enabled by default on Linux. note that you have to change this on both http server and client. The TT card will download with reasonable stability up to 3 Mbit/s. Robert = =20 Dusan Statelov = =20 cc: = =20 Sent by: Subject: How to reach La= rge TCP window in Win (2000) or =20 owner-tcpsat@gr Linux = =20 c.nasa.gov = =20 = =20 = =20 05/28/01 05:00 = =20 PM = =20 Please respond = =20 to statelov = =20 = =20 = =20 Hello: As we are now in time pressure I would like ask you for advices how to properly configure Win2000 or Linux Http data server in order to achiev= e bigger TCP window and improve Single TCP connection from poor 20-30 kby= te/s (for RTT 240 ms) to according to us achievable 1 mbps. We have changed "Default Receive Window", but TCP is running at only 20= -30 kbyte/s what would corresponde to 8 kbyte Window rather then to 64 kbyt= e. I assume there are other TCP registry entities which influence Sender Window. Here is a configuration emulating satellite internet: Http Data Server [Linux or Win2000]=A0 -> DVB/ip -> DVB-S Modulator -> = L band output -> PC DVB board [SkyMedia - Telemann, TT DVB Technotrend] -> client PC [Win98] o---------------o=A0 connected to DVB/ip GW in return= via LAN LAN RTT 20 ms Artefficial delay in DVB/ip GW 220 ms (in order to simulate long RTT fo= r satellite) Windows98 Default Receive Window to max.values 65535 Data Sever Win2000 Default Receive Window to max.values 65535 (we tried even 0,5 Mbyte wit= h no effect) RTT 240 ms Single TCP connection 20 - 30 kbyte/s Thanks in advance. Dusan Statelov Managing Director Main Data,s.r.o. mailto:statelov@maindata.sk Tel:=A0=A0=A0=A0 +421 7 54789 586 Fax:=A0=A0=A0=A0 +421 7 54789 585 GSM:=A0=A0=A0=A0 +421 905 606 027 http://www.maindata.sk (See attached file: statelov.vcf) -- DISCLAIMER: This e-mail contains proprietary information some or all of which may b= e legally privileged. It is for the intended recipient only. If an addres= sing or transmission error has misdirected this e-mail, please notify the au= thor by replying to this e-mail. If you are not the intended recipient you m= ust not use, disclose, distribute, copy, print, or rely on this e-mail.= --0__=C1256A5B002C3B2A8f9e8a93df938690918cC1256A5B002C3B2A Content-type: application/octet-stream; name="=?iso-8859-1?Q?statelov.vcf?=" Content-Disposition: attachment; filename="=?iso-8859-1?Q?statelov.vcf?=" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOlN0YXRlbG92O0R1c2FuIA0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCm9y ZzpNYWluIERhdGEsIHMuci5vLg0KYWRyOjs7U2VuaWNrYSAyMztCcmF0aXNsYXZhOzs4MTEgMDQ7 U2xvdmFraWENCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpzdGF0ZWxvdkBtYWluZGF0YS5z aw0KdGl0bGU6TWFuYWdpbmcgRGlyZWN0b3INCnRlbDtmYXg6KyA0MjEgNyA1NDc4OSA1ODUNCnRl bDtob21lOisgNDIxIDkwNSA2MDYgMDI3DQp0ZWw7d29yazorIDQyMSA3IDU0Nzg5IDU4Ng0Kbm90 ZTpIeWJyaWQtTmV0IEludGVucmV0IHZpYSBEaWdpdGFsIFRWICYgRGlzdGFuY2UgVGVsZSBFZHVj YXRpb24NCngtbW96aWxsYS1jcHQ6OzANCmZuOkR1c2FuICBTdGF0ZWxvdg0KZW5kOnZjYXJkDQo= --0__=C1256A5B002C3B2A8f9e8a93df938690918cC1256A5B002C3B2A-- From owner-tcpsat@grc.nasa.gov Wed May 30 06:58:59 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05144; Wed, 30 May 2001 06:58:58 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id GAA00253; Wed, 30 May 2001 06:59:16 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma029917; Wed, 30 May 01 06:58:26 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA25016 for tcpsat-outgoing; Wed, 30 May 2001 06:41:48 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA25010 for ; Wed, 30 May 2001 06:41:47 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA10502; Wed, 30 May 2001 06:41:46 -0400 Received: from web14404.mail.yahoo.com(216.136.174.61) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010346; Wed, 30 May 01 06:41:02 -0400 Message-ID: <20010530104101.52243.qmail@web14404.mail.yahoo.com> Received: from [151.97.6.247] by web14404.mail.yahoo.com; Wed, 30 May 2001 03:41:01 PDT Date: Wed, 30 May 2001 03:41:01 -0700 (PDT) From: Renato Narcisi Subject: Questions about TCP in linux system To: tcpsat@grc.nasa.gov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Good morning to everyone, I'm introducing some modifications to the implementation of the TCP (Linux kernel 2.2.17) in order to optimize performance in satellite networks. I have some problems and I hope you can help me: 1. I need the RTT value immediately after the sync phase between the two TCP entities. Is the RTT evaluated during the sync phase? If so, can you suggest me in which variable is it stored (infact the RTT values should be stored in "tp->srtt", which is zero after the sync phase) 2. I read in a book ("TCP/IP Illustrated" which surely referes to an older version of linux kernel) that the tcp_time_stamp is practically an integer number which counts "ticks" of 500msec and, as a consequence, it is updated every 500 msec... is it possible? how could i have a good evaluation of RTT if i can estimate only ticks of such a big interval? I hope someone of You can kindly help me... thank You in advance Renato Narcisi __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-tcpsat@grc.nasa.gov Wed May 30 10:58:41 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13854; Wed, 30 May 2001 10:58:40 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id KAA26664; Wed, 30 May 2001 10:58:54 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma025920; Wed, 30 May 01 10:57:54 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA04911 for tcpsat-outgoing; Wed, 30 May 2001 10:43:22 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA04907; Wed, 30 May 2001 10:43:20 -0400 (EDT) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA18135; Wed, 30 May 2001 10:43:19 -0400 (EDT) Message-Id: <200105301443.KAA18135@guns.lerc.nasa.gov> To: Renato Narcisi From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tcpsat@grc.nasa.gov Subject: Re: Questions about TCP in linux system Organization: BBN Technologies/NASA GRC Song-of-the-Day: Blues Before and After Date: Wed, 30 May 2001 10:43:19 -0400 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk > 2. I read in a book ("TCP/IP Illustrated" which surely referes to > an older version of linux kernel) Actually, the above book covers BSD networking code. A very different animal than the linux code, I am sure. > that the tcp_time_stamp is practically an integer number which > counts "ticks" of 500msec and, as a consequence, it is updated > every 500 msec... is it possible? Under BSD that is true. I think linux has a finer-grained clock. > how could i have a good evaluation of RTT if i can estimate only > ticks of such a big interval? TCP does not try to obtain a "good evaluation of RTT". TCP attempts to determine an appropriate **retransmission timeout** (RTO), which is a much different problem. See the following paper for an evaluation of the impact of clock granularity (among other things) on the standard RTO algorithm: Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. ACM SIGCOMM, September 1999, Cambridge, MA. http://roland.grc.nasa.gov/~mallman/papers/estimation.ps (The conclusion from the paper is that finer-grained timers provide better RTO performance when used in conjunction with a fairly healthy lower bound on the RTO.) RFC 2988 outlines the standard RTO algorithm. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@grc.nasa.gov Thu May 31 00:23:33 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02607; Thu, 31 May 2001 00:23:32 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id AAA19400; Thu, 31 May 2001 00:23:49 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma018981; Thu, 31 May 01 00:22:58 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA29689 for tcpsat-outgoing; Thu, 31 May 2001 00:00:33 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA29637 for ; Thu, 31 May 2001 00:00:30 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA25648; Thu, 31 May 2001 00:00:30 -0400 Received: from eda1000.ee.cityu.edu.hk(144.214.130.198) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025620; Thu, 31 May 01 00:00:03 -0400 Received: from ee.cityu.edu.hk (dcpc05.ee.cityu.edu.hk [144.214.130.120]) by eda1000.ee.cityu.edu.hk (8.9.3/8.9.3) with ESMTP id LAA23025; Thu, 31 May 2001 11:53:43 +0800 (HKT) Message-ID: <3B15C1C6.5EC7897F@ee.cityu.edu.hk> Date: Thu, 31 May 2001 12:00:06 +0800 From: KY Wong Reply-To: kywong@ee.cityu.edu.hk Organization: ttp://www.cityu.edu.hk X-Mailer: Mozilla 4.76 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: Why can download manager can help? Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Some download managers such as NetAnts claim to be designed to maximize throughput by making multiple HTTP connections, each of which downloads a separate part of a single big file. I wonder why doing this is helpful. Suppose a user connects to the Internet via a 56kbps line. His first HTTP connection should consume all the bandwidth of his line, how can the multiple simultanous connections help? Assume the Web server haven't limited the transfer rate for the requests to it. If the user had a 1.5Mbps line now, then his first HTTP connection could still transfer the file at 1.5Mbps (assume the network is not the bottleneck), how can the multiple connections help? Now suppose the network is the performance bottleneck (maybe network congestion), then no matter how many simultanous connections are used, the overall transfer speed is limited by the network. How can the multiple connections help? However, by real experience, this kind of download manager is helpful and reduce the overall respond time. Why? Is it related to the HTTP 1.1? Thank you for your attention. Angus Wong From owner-tcpsat@grc.nasa.gov Thu May 31 12:56:48 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01926; Thu, 31 May 2001 12:56:46 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id MAA15173; Thu, 31 May 2001 12:57:04 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma014709; Thu, 31 May 01 12:56:27 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA21454 for tcpsat-outgoing; Thu, 31 May 2001 12:22:58 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA21431 for ; Thu, 31 May 2001 12:22:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA12645; Thu, 31 May 2001 12:22:57 -0400 Received: from us-la-gate.interpacket.net(209.198.223.250) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012633; Thu, 31 May 01 12:22:34 -0400 Received: (qmail 29488 invoked from network); 31 May 2001 16:22:07 -0000 Received: from mrbig.la.interpacket.net (192.168.6.5) by bond.la.interpacket.net with SMTP; 31 May 2001 16:22:07 -0000 Received: from [192.168.4.223] (host-192-168-4-223.la.interpacket.net [192.168.4.223]) by mrbig.la.interpacket.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LC58XK3F; Thu, 31 May 2001 09:25:33 -0700 Mime-Version: 1.0 X-Sender: jonm@mrbig.la.interpacket.net Message-Id: In-Reply-To: <3B15C1C6.5EC7897F@ee.cityu.edu.hk> References: <3B15C1C6.5EC7897F@ee.cityu.edu.hk> Date: Thu, 31 May 2001 09:21:34 -0700 To: kywong@ee.cityu.edu.hk, tcpsat@grc.nasa.gov From: Jon Mansey Subject: Re: Why can download manager can help? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk This is especially relevant to satellite IP networks where the latency affects each TCP connection by limiting the maximum throughput to an un-modified TCP stack on a client. Opening multiple parallel TCP connections is a way "pull" more bandwidth on "one session". You're right though, it probably wouldnt improve things over low latency 56k or T1 lines. jm >?Some download managers such as NetAnts claim to be designed to maximize >throughput by making multiple HTTP connections, each of which downloads >a separate part of a single big file. > >I wonder why doing this is helpful. > >Suppose a user connects to the Internet via a 56kbps line. His first >HTTP connection should consume all the bandwidth of his line, how can >the multiple simultanous connections help? > >Assume the Web server haven't limited the transfer rate for the requests >to it. If the user had a 1.5Mbps line now, then his first HTTP >connection could still transfer the file at 1.5Mbps (assume the network >is not the bottleneck), how can the multiple connections help? > >Now suppose the network is the performance bottleneck (maybe network >congestion), then no matter how many simultanous connections are used, >the overall transfer speed is limited by the network. How can the >multiple connections help? > >However, by real experience, this kind of download manager is helpful >and reduce the overall respond time. Why? Is it related to the HTTP 1.1? > >Thank you for your attention. > >Angus Wong From owner-tcpsat@grc.nasa.gov Thu May 31 18:36:52 2001 Received: from seraph2.lerc.nasa.gov (firewall-user@[198.118.142.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09570; Thu, 31 May 2001 18:36:51 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id SAA19543; Thu, 31 May 2001 18:37:12 -0400 Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.lerc.nasa.gov via smap (V5.5) id xma019307; Thu, 31 May 01 18:36:21 -0400 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA25431 for tcpsat-outgoing; Thu, 31 May 2001 18:07:43 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA25418 for ; Thu, 31 May 2001 18:07:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA03684; Thu, 31 May 2001 18:07:40 -0400 Received: from cordelia.mail.kokuacom.net(212.116.96.13) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003669; Thu, 31 May 01 18:07:30 -0400 Received: from mike (purplet.demon.co.uk [158.152.8.178]) by cordelia.mail.kokuacom.net (Postfix) with SMTP id 97D8BAE497 for ; Thu, 31 May 2001 22:57:48 +0100 (BST) From: "Mike Jagdis" To: Subject: Re: Why can download manager can help? Date: Thu, 31 May 2001 23:04:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Some download managers such as NetAnts claim to be designed to maximize > throughput by making multiple HTTP connections, each of which downloads > a separate part of a single big file. > > I wonder why doing this is helpful. By violating the slow start principle. With one TCP connection you send one packet, get an ACK, send two packets, get two ACKs etc. With short lived connections, such as HTTP/1.0, you may never actually get out of slow start and thus use significantly less then bandwidth than is actually available. HTTP/1.1 addresses this at the application level by by reusing the same TCP connection. With a longer lived connection you have the chance to ramp up further and get out of slow start. The multiple connections brigade reduces the slow start effect by using multiple connections. With four connections rather than one you send four packets, get four ACKs, send eight packets, get eight ACKs etc. Sounds good? Well, kind of, yeah... > Now suppose the network is the performance bottleneck (maybe network > congestion), then no matter how many simultanous connections are used, > the overall transfer speed is limited by the network. How can the > multiple connections help? That's where things go wrong. If you are using four connections to do the work of one then under congestion you will get four times your fair share of bandwidth. This is good for you. It's bad for everyone else who happens to be using the same link. Unless they happen to be using one of these multiple connection atrocities as well in which case you are heading for an arms race with people increasing the number of connections they use to try and grab more of the bandwidth for themselves. Once you are in to an arms race things go from bad to worse. Use of multiple connections like that creates bursts of SYN, SYN-ACK and data packets that disturb TCPs attempts to adapt to the available bandwidth. This tends to result in active connections staying backed off so there is always free capacity to absorb these bursts. i.e. the link owner doesn't get to make efficient use of the bandwidth they are paying for. > However, by real experience, this kind of download manager is helpful > and reduce the overall respond time. Why? Is it related to the HTTP 1.1? Yes. It *appears* helpful to the end user. But it's snake oil. It helps the end user by screwing over every one else trying to use any of the links between you and the remote system you are accessing. I seem to remember early versions of Netscape used multiple connections. I believe you'll find it mentioned in the tcpsat archives if you search for netscape and marco. Incidentally there is ongoing TCP research to avoid slow start limitations without being so massively anti-social. Things like large initial windows, shared state, congestion managers etc. Mike -- Chief Network Architect Mobile: +44 7780 608 368 Kokua Communications Ltd Office: +44 20 7292 1680 52-53 Conduit Street Fax: +44 20 7292 1681 London W1S 2YX