From owner-tcpsat@grc.nasa.gov Sun Jun 2 14:20:42 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17869 for ; Sun, 2 Jun 2002 14:20:42 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A7C0464122 for ; Sun, 2 Jun 2002 14:20:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g52I04g5003183 for tcpsat-outgoing; Sun, 2 Jun 2002 14:00:04 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g52I03e6003174 for ; Sun, 2 Jun 2002 14:00:03 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g52I02Sl012516 for ; Sun, 2 Jun 2002 14:00:02 -0400 (EDT) Received: from terra (217-126-87-19.uc.nombres.ttd.es [217.126.87.19]) by seraph2.grc.nasa.gov (Postfix) with SMTP id E3A9BC6932 for ; Sun, 2 Jun 2002 14:00:00 -0400 (EDT) From: "London Language Institute" <1FORMACION@eresmas.com> To: Subject: APRENDA O MEJORE SUS IDIOMAS EN VERANO Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 2 Jun 2002 19:56:24 Message-Id: <20020602180000.E3A9BC6932@seraph2.grc.nasa.gov> Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk LONDON LANGUAGE INSTITUTE Información y reservas Tel.902180066 Fax 934319444 londonlanguages CLASES CON PROFESOR PRESENCIAL. ESTE VERANO APROVECHE LA OPORTUNIDAD MODULO DE MANTENIMIENTO O AMPLIACION DE CONOCIMIENTOS para aprender IDIOMAS, nuestros profesores se desplazan a su oficina o domicilio particular. Los cursos se diseñan con Ud. para cubrir sus necesidades en las áreas profesionales y sociales que le interesan. Clases exclusivamente personalizadas, eligiendo nuestro participante, particular o empresa, lugar, hora y duración de las mismas. Pueden ser tanto en la oficina como en su domicilio. PROGRAMA DE MANTENIMIENTO Para los que dominan el idioma y necesitan un mantenimiento y correcciones DIRIGIDO A empresas y particulares, a aquellas personas que disponen de poco tiempo y desean una enseñanza personalizada,de alto rendimiento y Calidad. OBJETIVOS Adquirir desde el primer momento los hábitos y conocimientos que pueda necesitar en su relación empresarial o social,todo ello en un entorno de máxima motivación, haciendo que disfrute de los progresos o mejoras alcanzados Algunos idiomas disponibles: Alemán, Francés, Inglés Británico y Americano, Italiano, Ruso, Castellano, Catalán, Euskera y Gallego. Otros a consultar. GARANTIA No cobramos matricula ni pagos a cuenta, a fin de mes le presentamos factura por las clases impartidas. Con nuestro sistema esta demostrado que el ratio de aprendizaje es de 1/10 en comparación con otros medios. Información y reservas Tel. 902180066 Si no desea recibir publicidad, haga un reply a la dirección indicada Mail:londonlanguages3@eresmas.com al tel o al Fax indicando baja de ficheros From owner-tcpsat@grc.nasa.gov Tue Jun 4 06:41:16 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22712 for ; Tue, 4 Jun 2002 06:41:16 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 1CF7064109 for ; Tue, 4 Jun 2002 06:41:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g54AMlPt019494 for tcpsat-outgoing; Tue, 4 Jun 2002 06:22:47 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g54AMje6019480 for ; Tue, 4 Jun 2002 06:22:45 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g54AMiSl001393 for ; Tue, 4 Jun 2002 06:22:44 -0400 (EDT) Received: from demokritos.cytanet.com.cy (demokritos.cytanet.com.cy [195.14.133.252]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E9584640EB for ; Tue, 4 Jun 2002 06:22:40 -0400 (EDT) Received: from andreasp (adsl-169-144.cytanet.com.cy [213.149.169.144]) by demokritos.cytanet.com.cy (8.11.4/8.11.4) with SMTP id g54AMWu15279; Tue, 4 Jun 2002 13:22:32 +0300 (EET DST) Message-ID: <001001c20bb1$bee60de0$09350b0a@andreasp> From: "Andreas Pitsillides" To: , , , , , , , , , Cc: "Andreas Pitsillides" References: <030901c1fd9d$f137bfe0$09350b0a@andreasp> Subject: 2nd Call for Participation INFOCOM 2002 + HOTEL RATE REDUCTION Date: Tue, 4 Jun 2002 13:04:58 +0300 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES ----- CALL FOR PARTICIPATION - INFOCOM 2002 --------------- Note: 1. The deadline for low rate hotel reservation cut-off is extended to Friday 14 2. Hotel rates have been reduced to $239 for single and $259 for double occupancy 3. All earlier bookings made at the earlier higher rate, will be reimbursed the difference The 21st Annual Joint Conference of the IEEE Computer and Communications Societies June 23-27, 2002, Hilton New York, New York, USA http://www.ieee-infocom.org/2002 From owner-tcpsat@grc.nasa.gov Tue Jun 4 13:37:33 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07163 for ; Tue, 4 Jun 2002 13:37:33 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 887EA64130 for ; Tue, 4 Jun 2002 13:37:32 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g54HFwVY024755 for tcpsat-outgoing; Tue, 4 Jun 2002 13:15:58 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g54HFue6024744 for ; Tue, 4 Jun 2002 13:15:56 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g54HFtSl006912 for ; Tue, 4 Jun 2002 13:15:56 -0400 (EDT) Received: from marjan.fesb.hr (marjan.fesb.hr [161.53.166.3]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 20C8964090 for ; Tue, 4 Jun 2002 13:15:55 -0400 (EDT) Received: (from root@localhost) by marjan.fesb.hr (8.12.1/8.12.1/Debian -5) id g54HFrhI030196 for tcpsat@lerc.nasa.gov; Tue, 4 Jun 2002 19:15:53 +0200 Received: from marjan.fesb.hr (hrvoje.fesb.hr [161.53.166.75]) by marjan.fesb.hr (8.12.1/8.12.1/Debian -5) with SMTP id g54HFoAR030160 for ; Tue, 4 Jun 2002 19:15:50 +0200 Message-Id: <1023211741.280@fesb.hr> Date: Tue, 04 Jun 2002 19:29:01 0200 To: tcpsat@lerc.nasa.gov From: "SoftCOM" Subject: IEEE SoftCOM 2002 - new deadline 21.06.2002 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk SoftCOM 2002 10th IEEE Conference on Software, Telecommunications and Computer Networks Split, Dubrovnik (Croatia), Ancona, Venice (Italy) October 08-11, 2002 (aboard the ship "Dalmacija") Dear member of the SoftCOM mailing list, We have received a number of requirements for deadline extension. The new deadline is June 21, 2002. Call for papers and Author kit can be found at www.fesb.hr/SoftCOM. Sincerely yours Conference secretary Hrvoje Dujmic ****************************************************************** TO BE REMOVED FROM THIS LIST You will receive at most three mails per year from this mailing list. If you would like to be removed from this email contact list, please reply to this message, including the text of the entire message above in the body of your email message, and the words 'REMOVE ME' in the subject line. This email should be addressed to: softcom@fesb.hr ****************************************************************** From owner-tcpsat@grc.nasa.gov Fri Jun 7 16:19:34 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11516 for ; Fri, 7 Jun 2002 16:19:34 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B6BE86411D for ; Fri, 7 Jun 2002 16:19:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g57JtkF1029492 for tcpsat-outgoing; Fri, 7 Jun 2002 15:55:46 -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 GRC 8.12.3/8.12.3) with ESMTP id g57Jtira029483; Fri, 7 Jun 2002 15:55:44 -0400 (EDT) Received: from katrinajoy (tb2-78.lerc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id PAA16709; Fri, 7 Jun 2002 15:55:44 -0400 (EDT) Message-Id: <4.2.1.20020607035034.00b3cad0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 07 Jun 2002 03:54:35 -0400 To: "Jackson, Gary" , "Tcpsat (E-mail)" From: William Ivancic Subject: Re: Satellite Emulators In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk ONE may fit your needs. http://irg.cs.ohiou.edu/one/ One can do variable delay. We use the Adtech SX/14 routinely. It is very nice. I also have an HP ATM Broadband Series Test Set (BSTS) with an impairment module that does ATM payload and header error and packet loss as well as jutter. Good Luck, Will At 10:35 AM 5/15/02 -0700, Jackson, Gary wrote: >I am part of a group building a proof-of-concept lab for some new >services. We are soliciting opinions about satellite emulators, >specifically with variable bandwidth, latency, jitter, and packet loss. >We have looked at the Shunra offering, and are also considering "rolling >our own". Are there any other suggestions or comments? > >Thanks! > >Gary Jackson >Senior Network Engineer >Tectura Corporation >14205 S.E. 36th Street >Suite 200 >Bellevue, WA 98006 >(425) 957-4270 > From owner-tcpsat@grc.nasa.gov Thu Jun 13 11:47:30 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18194 for ; Thu, 13 Jun 2002 11:47:30 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 79C19C698B for ; Thu, 13 Jun 2002 11:47:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5DFbK3d010425 for tcpsat-outgoing; Thu, 13 Jun 2002 11:37:20 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5DFbJra010413 for ; Thu, 13 Jun 2002 11:37:19 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5DFbISl012614 for ; Thu, 13 Jun 2002 11:37:18 -0400 (EDT) Received: from demokritos.cytanet.com.cy (demokritos.cytanet.com.cy [195.14.133.252]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 587E264091 for ; Thu, 13 Jun 2002 11:37:17 -0400 (EDT) Received: from andreasp (adsl-169-66.cytanet.com.cy [213.149.169.66]) by demokritos.cytanet.com.cy (8.11.4/8.11.4) with SMTP id g5DFbC226283; Thu, 13 Jun 2002 18:37:12 +0300 (EET DST) Message-ID: <03bf01c212f0$31b917a0$09350b0a@andreasp> From: "Andreas Pitsillides" To: , , , , , , , , , Cc: "Andreas Pitsillides" References: <030901c1fd9d$f137bfe0$09350b0a@andreasp> <001001c20bb1$bee60de0$09350b0a@andreasp> <020b01c212ed$ef9d0770$09350b0a@andreasp> Subject: Wireless Internet Workshop - NYC 28 June Date: Thu, 13 Jun 2002 18:37:08 +0300 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues: For those of you planning to attend INFOCOM in NYC this year, we are holding the Wireless Internet Workshop at the Brooklyn campus of Polytechnic University on Friday, June 28. The workshop is sponsored by the New York State Wireless Internet Center for Advanced Technology (WICAT), which draws researchers from Polytechnic and Columbia Universities. Registration is free, but please send an email to claudia@catt.poly.edu if you intend to come. This will help us in our planning process. A tentative program follows. Shiv Panwar ****************************************************************** Friday, June 28, 2002 Free Registration (Please email claudia@catt.poly.edu if you plan to attend) Venue: Auditorium Library/CATT Building Five Metro Tech Center, Brooklyn, NY Tentative Schedule 9 am Welcome: Phyllis Frankl, Director, Wireless Internet Center for Advanced Technology 9:10 am Keynote Speaker- Joseph Katz, Symbol Technologies 10 am Invited Speaker 1 - Adam Wolisz, Technical University of Berlin 10:45 am Coffee Break 11 am Panel Discussion: Wireless Research after 9/11, Chair: Andrew Campbell, WICAT/Columbia University Taieb Znati, National Science Foundation George Hough, Fire Dept. NY Aurel Lazar, Columbia University David Johnson, Rice University 12 pm noon Lunch and Poster Session outside auditorium entrance, Tour of Brooklyn Promenade 1:30 pm Invited Speaker 2 - TBA 2:15 pm Invited Speaker 3 - David Goodman, Polytechnic University 3 -3:15 pm Coffee break 3:15 pm Panel Discussion: Killer Apps for the Wireless Internet Chair: Mel Horwich, Polytechnic University Panelists: TBA 4:15 pm: Reception For directions and information on WICAT, please visit our website: http://wicat.poly.edu From owner-tcpsat@grc.nasa.gov Thu Jun 13 15:17:21 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26922 for ; Thu, 13 Jun 2002 15:17:19 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 31F4464106 for ; Thu, 13 Jun 2002 15:17:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5DIuHpB029659 for tcpsat-outgoing; Thu, 13 Jun 2002 14:56:17 -0400 (EDT) Received: from opus.lerc.nasa.gov (opus.lerc.nasa.gov [139.88.102.98]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5DIuGra029650 for ; Thu, 13 Jun 2002 14:56:16 -0400 (EDT) Received: from grc.nasa.gov (dcarek.grc.nasa.gov [139.88.102.74]) by opus.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id OAA11931; Thu, 13 Jun 2002 14:56:16 -0400 Message-ID: <3D08EADE.7000006@grc.nasa.gov> Date: Thu, 13 Jun 2002 14:56:30 -0400 From: David Carek User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020513 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: Satellites running IP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I'm looking for existing satellites that use IP or other Internet protocols on board or in their air to ground communications. If you know of any currently flying satellites with such capabilities I'd appreciate the references. We use TCP/IP onboard the shuttle for some systems, but we have a custom unreliable protocol for the air to ground segment. I'd like to identify processors, operating systems, and tcp/ip stacks that have already been used in space. From owner-tcpsat@grc.nasa.gov Thu Jun 13 18:30:59 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02614 for ; Thu, 13 Jun 2002 18:30:59 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 366ADC6935 for ; Thu, 13 Jun 2002 18:31:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5DFLFB2005393 for tcpsat-outgoing; Thu, 13 Jun 2002 11:21:15 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5DFL9ra005372 for ; Thu, 13 Jun 2002 11:21:09 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5DFL8Sl009156 for ; Thu, 13 Jun 2002 11:21:08 -0400 (EDT) Received: from demokritos.cytanet.com.cy (demokritos.cytanet.com.cy [195.14.133.252]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id A0AF4C6911 for ; Thu, 13 Jun 2002 11:21:07 -0400 (EDT) Received: from andreasp (adsl-169-66.cytanet.com.cy [213.149.169.66]) by demokritos.cytanet.com.cy (8.11.4/8.11.4) with SMTP id g5DFKx224680; Thu, 13 Jun 2002 18:21:00 +0300 (EET DST) Message-ID: <020b01c212ed$ef9d0770$09350b0a@andreasp> From: "Andreas Pitsillides" To: , , , , , , , , , Cc: "Andreas Pitsillides" References: <030901c1fd9d$f137bfe0$09350b0a@andreasp> <001001c20bb1$bee60de0$09350b0a@andreasp> Subject: FINAL Call for Participation INFOCOM 2002 - HOTEL RATE REDUCTIONS DEADLINE FRIDAY 14th Date: Thu, 13 Jun 2002 18:20:55 +0300 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES ----- CALL FOR PARTICIPATION - INFOCOM 2002 --------------- The 21st Annual Joint Conference of the IEEE Computer and Communications Societies June 23-27, 2002, Hilton New York, New York, USA http://www.ieee-infocom.org/2002 Note: 1. The deadline for low rate hotel reservation cut-off is extended to Friday 14 2. Hotel rates have been reduced to $239 for single and $259 for double occupancy 3. All earlier bookings made at the earlier higher rate, will be reimbursed the difference From owner-tcpsat@grc.nasa.gov Fri Jun 14 09:09:35 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28139 for ; Fri, 14 Jun 2002 09:09:35 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id D3225C6935 for ; Fri, 14 Jun 2002 09:09:41 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5ECqs3d020295 for tcpsat-outgoing; Fri, 14 Jun 2002 08:52:54 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ECqqra020262; Fri, 14 Jun 2002 08:52:52 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ECqpSl012271; Fri, 14 Jun 2002 08:52:52 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 45116640A0; Fri, 14 Jun 2002 08:52:51 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17IqZH-0005J3-00; Fri, 14 Jun 2002 13:52:43 +0100 Date: Fri, 14 Jun 2002 13:52:42 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: David Carek Cc: tcpsat@grc.nasa.gov Subject: Re: Satellites running IP In-Reply-To: <3D08EADE.7000006@grc.nasa.gov> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17IqZH-0005J3-00*gFtRjD27xVk* (SECM, UniS) Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk On Thu, 13 Jun 2002, David Carek wrote: > I'm looking for existing satellites that use IP or other Internet > protocols on board or in their air to ground communications. If you > know of any currently flying satellites with such capabilities I'd > appreciate the references. > > We use TCP/IP onboard the shuttle for some systems, but we have a custom > unreliable protocol for the air to ground segment. I'd like to identify > processors, operating systems, and tcp/ip stacks that have already > been used in space. Chris Jackson presented a paper on SSTL's use of Internet Protocols on the upcoming disaster monitoring constellation missions at the Second Space Internet Workshop at Goddard Space Flight Centre, 21-22 May. This is based on previous work; UoSAT-12 has demonstrated an onboard TCP/IP stack, although the satellite's not really relying on it for TT&C: http://siw.gsfc.nasa.gov/abstracts.html Really, isn't this what NASA et al. have been developing SCPS for? L. From owner-tcpsat@grc.nasa.gov Fri Jun 14 12:13:45 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04803 for ; Fri, 14 Jun 2002 12:13:45 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 605276412C for ; Fri, 14 Jun 2002 12:13:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EFqQPs005958 for tcpsat-outgoing; Fri, 14 Jun 2002 11:52:26 -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 GRC 8.12.3/8.12.3) with ESMTP id g5EFqOra005943; Fri, 14 Jun 2002 11:52:24 -0400 (EDT) Received: from katrinajoy (tb2-78.lerc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id LAA29546; Fri, 14 Jun 2002 11:52:22 -0400 (EDT) Message-Id: <4.2.1.20020614113450.00bcec60@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 14 Jun 2002 11:51:53 -0400 To: Lloyd Wood , David Carek From: William Ivancic Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: References: <3D08EADE.7000006@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4754627==_.ALT" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk --=====================_4754627==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote: >On Thu, 13 Jun 2002, David Carek wrote: > > > I'm looking for existing satellites that use IP or other Internet > > protocols on board or in their air to ground communications. ..... > > >Really, isn't this what NASA et al. have been developing SCPS for? > >L. Does anyone know of someone "flying" an onboard SCPS stack? Does anyone know of any commercial applications that call the SCPS-TP options. SCPS-FP is the only application one I know of. Does anyone know of a commercial vendor implementing a SCPS-NP router? To take full advantage of some options in SCPS-TP, one needs as SCPS-NP router. We performed high-speed testing those SCPS options we could test and found no significant performance improvements. The report is being written, but not yet available. The results were presented as the 2nd Space Internet Workshop in June and will be presented at SpaceOps 2002. http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html Under PRESENTATIONS "SCPS-TP, TCP and Rate-Based Protocol Evaluation," (Includes multi-flow data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file size 951,808 bytes By the way, SCPS-TP advertises TCP's protocol number for reliable transport protocol selections. It does this even if the pure rate-based transmission is used. IMO, this is terrible as it make QoS and queue management very difficult. I may be putting a rate-based protocol into a WRED queue. Guess who loses. Will --=====================_4754627==_.ALT Content-Type: text/html; charset="us-ascii" At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote:
On Thu, 13 Jun 2002, David Carek wrote:

> I'm looking for existing satellites that use IP or other Internet
> protocols on board or in their air to ground communications.  .....


Really, isn't this what NASA et al. have been developing SCPS for?

L.

Does anyone know of someone "flying" an onboard SCPS stack? 

Does anyone know of any commercial applications that call the SCPS-TP options.  SCPS-FP is the only application one I know of.

Does anyone know of a commercial vendor implementing a SCPS-NP router?  To take full advantage of some options in SCPS-TP, one needs as SCPS-NP router.

We performed high-speed testing those SCPS options we could test and found no significant performance improvements.
The report is being written, but not yet available.  The results were presented as the 2nd Space Internet Workshop in June and will be 
presented at SpaceOps 2002.

http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html

Under PRESENTATIONS

"SCPS-TP, TCP and Rate-Based Protocol Evaluation," (Includes multi-flow data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file size 951,808 bytes


By the way, SCPS-TP advertises TCP's protocol number for reliable transport protocol selections.  It does this even if the pure rate-based transmission is used.  IMO, this is terrible as it  make QoS and queue management very difficult.  I may be putting a rate-based protocol into a WRED queue.  Guess who loses.

Will --=====================_4754627==_.ALT-- From owner-tcpsat@grc.nasa.gov Fri Jun 14 12:51:17 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06091 for ; Fri, 14 Jun 2002 12:51:16 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 56F9064156 for ; Fri, 14 Jun 2002 12:51:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EGbF95017198 for tcpsat-outgoing; Fri, 14 Jun 2002 12:37:15 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EGbCra017182; Fri, 14 Jun 2002 12:37:12 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EGbBSl019989; Fri, 14 Jun 2002 12:37:11 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 4D79E640DF; Fri, 14 Jun 2002 12:37:11 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17Iu4O-0001mR-00; Fri, 14 Jun 2002 17:37:04 +0100 Date: Fri, 14 Jun 2002 17:37:03 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: William Ivancic Cc: David Carek , Subject: Re: Satellites running IP In-Reply-To: <4.2.1.20020614113450.00bcec60@popserve.grc.nasa.gov> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17Iu4O-0001mR-00*wUVY1Ig74xU* (SECM, UniS) Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk On Fri, 14 Jun 2002, William Ivancic wrote: > At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote: > >On Thu, 13 Jun 2002, David Carek wrote: > > > > > I'm looking for existing satellites that use IP or other Internet > > > protocols on board or in their air to ground communications. ..... > > > > Really, isn't this what NASA et al. have been developing SCPS for? > > Does anyone know of someone "flying" an onboard SCPS stack? > > Does anyone know of any commercial applications that call the SCPS-TP > options. SCPS-FP is the only application one I know of. > > Does anyone know of a commercial vendor implementing a SCPS-NP router? To > take full advantage of some options in SCPS-TP, one needs as SCPS-NP router. > > We performed high-speed testing those SCPS options we could test and found > no significant performance improvements. > The report is being written, but not yet available. The results were > presented as the 2nd Space Internet Workshop in June and will be > presented at SpaceOps 2002. > > http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html > > Under PRESENTATIONS > > "SCPS-TP, TCP and Rate-Based Protocol Evaluation," (Includes multi-flow > data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file > size 951,808 bytes the rest of the presentations are at http://siw.gsfc.nasa.gov/agenda.html (SIW1 has html conversions of all slides online; SIW2 is wholly powerpoint. Really, I'd like to see pdfs of the lot - all the read-anywhere-platform-independent convenience of one, all the download-a-single-file convenience of the other.) > By the way, SCPS-TP advertises TCP's protocol number for reliable transport > protocol selections. It does this even if the pure rate-based transmission > is used. IMO, this is terrible as it make QoS and queue management very > difficult. QoS and queue management shouldn't depend on what traffic is, but on what traffic does imo - otherwise there's a semantic gap. When rate-based, SCPS-TP is still sending TCP-style packets, so the protocol identifier is valid. L. > I may be putting a rate-based protocol into a WRED > queue. Guess who loses. > > Will From owner-tcpsat@grc.nasa.gov Fri Jun 14 14:57:51 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10530 for ; Fri, 14 Jun 2002 14:57:50 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id DF84264154 for ; Fri, 14 Jun 2002 14:57:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EIjxn6015563 for tcpsat-outgoing; Fri, 14 Jun 2002 14:45:59 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EIjvra015552; Fri, 14 Jun 2002 14:45:57 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EIjuSl009498; Fri, 14 Jun 2002 14:45:56 -0400 (EDT) Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.160.40]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 58850640F0; Fri, 14 Jun 2002 14:45:55 -0400 (EDT) Received: from ahooke-2k.jpl.nasa.gov (hookepc2.jpl.nasa.gov [137.79.10.230]) by eis-msg-012.jpl.nasa.gov (8.12.1/8.12.1) with ESMTP id g5EIjrol017988; Fri, 14 Jun 2002 11:45:53 -0700 (PDT) Message-Id: <5.1.0.14.2.20020614070458.020fca48@pop.jpl.nasa.gov> X-Sender: ahooke@pop.jpl.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Jun 2002 11:45:28 -0700 To: tcpsat@grc.nasa.gov From: "Adrian J. Hooke" Subject: Re: Satellites running IP Cc: David Carek In-Reply-To: References: <3D08EADE.7000006@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk At 01:52 PM 6/14/2002 +0100, Lloyd Wood wrote: >Really, isn't this what NASA et al. have been developing SCPS for? Hi Lloyd: Possibly the first commanding of an in-flight spacecraft operating as a node on the Internet (with its own IP address) was done over six years ago (January 1996) from Eric Travis's bedroom in Rockville, MD., to STRV-1b in geostationary transfer orbit, using SCPS: http://www.sdl.usu.edu/conferences/smallsat/proceedings/10/sess1/strv.pdf Since then the SCPS protocol suite http://www.scps.org has been finished and is being commercially deployed, e.g.: http://xiphos.ca/xiplink/index.html http://www.skipware.com/index.html http://www.snapgear.com/datasheets/SnapGearSE_Datasheet.pdf Best regards Adrian Adrian J. Hooke Chairman, CCSDS Subpanel-1F (Advanced Orbiting Systems) NASA Jet Propulsion Laboratory, Interplanetary Network Directorate M/S 303-400, 4800 Oak Grove Drive Pasadena, California 91109-8099, USA +1.818.354.3063 OFFICE +1.818.653.9553 MOBILE +1 818.354.6290 FAX http://www.ccsds.org http://www.ipnrg.org From owner-tcpsat@grc.nasa.gov Fri Jun 14 15:20:10 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11862 for ; Fri, 14 Jun 2002 15:20:09 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 128176416D for ; Fri, 14 Jun 2002 15:20:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EJ8Lqb021805 for tcpsat-outgoing; Fri, 14 Jun 2002 15:08:21 -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 GRC 8.12.3/8.12.3) with ESMTP id g5EJ8Jra021778; Fri, 14 Jun 2002 15:08:19 -0400 (EDT) Received: from katrinajoy (tb2-78.lerc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id PAA25671; Fri, 14 Jun 2002 15:08:18 -0400 (EDT) Message-Id: <4.2.1.20020614145705.00bcc470@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 14 Jun 2002 15:07:18 -0400 To: Lloyd Wood From: William Ivancic Subject: Re: Satellites running IP Cc: David Carek , In-Reply-To: References: <4.2.1.20020614113450.00bcec60@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk > > >(SIW1 has html conversions of all slides online; SIW2 is wholly >powerpoint. Really, I'd like to see pdfs of the lot - all the >read-anywhere-platform-independent convenience of one, all the >download-a-single-file convenience of the other.) I'll get around to making PDFs sometime for the appropriate presentations. I've been using animation in some presentations which doesn't translate well to PDF. But, for some things, animation is very effective to make the point. I don't think the HTML conversion works for animations. > > By the way, SCPS-TP advertises TCP's protocol number for reliable transport > > protocol selections. It does this even if the pure rate-based transmission > > is used. IMO, this is terrible as it make QoS and queue management very > > difficult. > >QoS and queue management shouldn't depend on what traffic is, but on >what traffic does imo - otherwise there's a semantic gap. I agree, but, it takes far more energy to look at per flow information and determine the traffic pattern and then put it in a queue. Assuming that certain protocols react in certain ways is much easier and manageable - albeit somewhat dangerous. > When rate-based, SCPS-TP is still sending TCP-style packets, so the >protocol identifier is valid. I disagree. IMHO, one should not knowingly advertise a protocol number if one is not conforming to those protocol characteristics. Just because the header is the same style does not mean that it is the same protocol. IMHO, SCPS should advertise it's own protocol number when running rate-based, no congestion control. Will ======================================= 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 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic From owner-tcpsat@grc.nasa.gov Fri Jun 14 15:37:17 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12659 for ; Fri, 14 Jun 2002 15:37:16 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 9278DC69D3 for ; Fri, 14 Jun 2002 15:37:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EJREVX027064 for tcpsat-outgoing; Fri, 14 Jun 2002 15:27:14 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EJRCra027053; Fri, 14 Jun 2002 15:27:12 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EJRCSl017489; Fri, 14 Jun 2002 15:27:12 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id DBA36C69AF; Fri, 14 Jun 2002 15:27:11 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17Iwiu-0003tt-00; Fri, 14 Jun 2002 20:27:04 +0100 Date: Fri, 14 Jun 2002 20:26:58 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: William Ivancic Cc: David Carek , Subject: Re: Satellites running IP In-Reply-To: <4.2.1.20020614145705.00bcc470@popserve.grc.nasa.gov> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17Iwiu-0003tt-00*oXLdzqg2OPc* (SECM, UniS) Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk On Fri, 14 Jun 2002, William Ivancic wrote: > > When rate-based, SCPS-TP is still sending TCP-style packets, so the > >protocol identifier is valid. > > I disagree. IMHO, one should not knowingly advertise a protocol number if > one is not conforming to those protocol characteristics. well, that would be enough to kill pwe3 work entirely if anyone there agreed with that. And that doesn't lead to robust implementations; Savage attacks could bot be carried out because Savage would be compelled to use a different protocol number... > Just because the header is the same style does not mean that it is > the same protocol. So I should change the protocol number if I e.g. turn off the Nagle algorithm? I don't think so; there's a lot of timing slack in the evolving TCP specifications and a lot of variation in their implementations. > Assuming that certain protocols react in certain ways is much > easier and manageable - albeit somewhat dangerous. and does not lead to robust implementations. > IMHO, SCPS should advertise it's own protocol number when > running rate-based, no congestion control. just so that any assumptions made by intermediate systems hold true? not very e2e of you. And I don't see http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.ps http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.txt advocating a new protocol number either, even though it modifies the congestion control mechanisms. L. From owner-tcpsat@grc.nasa.gov Fri Jun 14 17:11:45 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15375 for ; Fri, 14 Jun 2002 17:11:44 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 6F65EC6A57 for ; Fri, 14 Jun 2002 17:11:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EKxtjY020691 for tcpsat-outgoing; Fri, 14 Jun 2002 16:59:55 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EKxsra020683; Fri, 14 Jun 2002 16:59:54 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EKxrSl004311; Fri, 14 Jun 2002 16:59:53 -0400 (EDT) Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [192.80.55.70]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 9B717C69E5; Fri, 14 Jun 2002 16:59:52 -0400 (EDT) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g5EKxql03441; Fri, 14 Jun 2002 16:59:52 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g5EKxoO13946; Fri, 14 Jun 2002 16:59:50 -0400 (EDT) Received: from mailhubf.mitre.org (129.83.25.49) by mailhub2.mitre.org with SMTP id 10550063; Fri, 14 Jun 2002 16:59:44 -0400 Received: from m26959-pc.mitre.org (128.29.105.162) by mailhubf.mitre.org with SMTP id 543743; Fri, 14 Jun 2002 16:59:39 -0400 Message-Id: <5.1.0.14.2.20020614165200.01e0f7a0@mailsrv2.mitre.org> X-Sender: kscott@mailsrv2.mitre.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Jun 2002 16:59:38 -0400 To: wivancic@grc.nasa.gov (William Ivancic), L.Wood@eim.surrey.ac.uk (Lloyd Wood), David.A.Carek@grc.nasa.gov (David Carek) From: kscott@mitre.org (Keith Scott) Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: <4.2.1.20020614113450.00bcec60@popserve.grc.nasa.gov> References: <3D08EADE.7000006@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_16209227==_.ALT" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk --=====================_16209227==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 11:51 AM 6/14/2002 -0400, William Ivancic wrote: >At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote: >>On Thu, 13 Jun 2002, David Carek wrote: >> >>> I'm looking for existing satellites that use IP or other Internet >>> protocols on board or in their air to ground communications. ..... >> >> >>Really, isn't this what NASA et al. have been developing SCPS for? >> >>L. > >Does anyone know of someone "flying" an onboard SCPS stack? =20 > >Does anyone know of any commercial applications that call the SCPS-TP= options. SCPS-FP is the only application one I know of. Xiphos (http://www.xiphos.com) is developing an in-kernel SCPS-TP= implementation. Presumably they'll have some sysadmin-settable 'default'= settings (I'd set SNACK and Vegas both on by default, e.g.) and then= individual applications can use setsockopt calls if they want to fine-tune= things. The point is, using xiphos' stack, all applications will have= access to the SCPS enhancements. Other companies have also had great success with FreeBSD-based systems,= using them to provide high-speed Internet connectivity to remote regions. = A number of remote schools using SCPS gateways to access the internet have= provided excellent load testing for us, both in terms of number of= simultaneous connections and sheer volume. >Does anyone know of a commercial vendor implementing a SCPS-NP router? To= take full advantage of some options in SCPS-TP, one needs as SCPS-NP= router. To which TP option are you referring? If you use NP in conjunction with TP= you can do better with respect to compression, as NP specifies things like= 1-byte connection identifiers (useful mostly in highly-managed situations= where bandwidth is limited, like communicating with spacecraft). For TP to= make use of link outage notifications, it needs some mechanism to generate= and relay the notifications (not unlike cumulative ETEN, though the= specification is somewhat older). >We performed high-speed testing those SCPS options we could test and found= no significant performance improvements. >The report is being written, but not yet available. The results were= presented as the 2nd Space Internet Workshop in June and will be =20 >presented at SpaceOps 2002. > >http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html > >Under PRESENTATIONS > >"SCPS-TP, TCP and Rate-Based Protocol Evaluation," (Includes multi-flow= data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file= size 951,808 bytes=20 Interesting. Slide 14 shows the rate-based theory for a 10Mbyte (80 Mbit)= file transfer across a 500msec delay link. Accounting for just clocking= the data (0.8 sec) and one round-trip for some sort of end-of-file= acknowledgement (0.5sec) brings the maximum throughput to ~61Mbps. Perhaps= the theoretical maximum was for a longer transfer and only accounted for= header (and retransmission) overhead. What's more curious is why all the rate-based protocols are down around= 30Mbps, especially since it's trivial to run SCPS to 60 or 80Mbps, even on= 266 to 300MHz-class machines. You say that the rate-based protocols need= more work, but question anyone will immediately ask is: why? Were there= losses at the network interface like you were seeing for NetBSD, or is= Solaris just really slow? What do the tcpdumps show? Do the various= protocols simply pause transmitting periodically, and if so, why? Are you= able to push the average throughput closer to the theoretical value as file= size increases? If not, why not? Obviously you've done a lot of work= understanding and comparing the various protocols; maybe you could let that= section of the paper leak out a bit early? All slide 17 shows is that TCPs that assume congestion back off a lot in the= face of loss. I'm curious as to why you didn't show TCP Vegas with the= default source of loss assumed to be corruption. This is still= 'congestion-friendly' as it will slow down when it detects queueing, but= performs quite well when confronted with a lightly loaded network with= moderate error rates. As for the warning on the last slide, it should be considered in conjunction= with your observation that non-congestion-controlled flows should be used= only when they will not overly interfere with congestion-controlled ones. = Unless one specifically chooses to disable all congestion control in SCPS,= it uses rate control in conjunction with a congestion control algorithm (VJ= or Vegas). This allows us to ensure that the congestion control algorithm= doesn't overrun the bottleneck link rate and auto-congest the network. = When using congestion control, SCPS-TP behaves like, and interoperates= with, other TCP implementations, and it is appropriate for it to use= IPPROTO 6. For the case when SCPS-TP is running without congestion= control, it should only be used on networks where it will not interfere= with congestion controlled traffic. Note that the CBQ mechanisms of Linux= kernels since 2.2 (and the traffic engineering mechanisms of common= commercial routers) can appropriately segregate flows. >By the way, SCPS-TP advertises TCP's protocol number for reliable transport= protocol selections. It does this even if the pure rate-based transmission= is used. IMO, this is terrible as it make QoS and queue management very= difficult. I may be putting a rate-based protocol into a WRED queue. = Guess who loses. > >Will=20 --=====================_16209227==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 11:51 AM 6/14/2002 -0400, William Ivancic wrote:
At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote:
On Thu, 13 Jun 2002, David Carek wrote:

> I'm looking for existing satellites that use IP or other Internet
> protocols on board or in their air to ground communications.  .....


Really, isn't this what NASA et al. have been developing SCPS for?

L.

Does anyone know of someone "flying" an onboard SCPS stack? 

Does anyone know of any commercial applications that call the SCPS-TP options.  SCPS-FP is the only application one I know of.

Xiphos (http://www.xiphos.com= ) is developing an in-kernel SCPS-TP implementation.  Presumably they'll have some sysadmin-settable 'default' settings (I'd set SNACK and Vegas both on by default, e.g.) and then individual applications can use setsockopt calls if they want to fine-tune things.  The point is, using xiphos' stack, all applications will have access to the SCPS enhancements.

Other companies have also had great success with FreeBSD-based systems, using them to provide high-speed Internet connectivity to remote regions.  A number of remote schools using SCPS gateways to access the internet have provided excellent load testing for us, both in terms of number of simultaneous connections and sheer volume.

Does anyone know of a commercial vendor implementing a SCPS-NP router?  To take full advantage of some options in SCPS-TP, one needs as SCPS-NP router.

To which TP option are you referring?  If you use NP in conjunction with TP you can do better with respect to compression, as NP specifies things like 1-byte connection identifiers (useful mostly in highly-managed situations where bandwidth is limited, like communicating with spacecraft).  For TP to make use of link outage notifications, it needs some mechanism to generate and relay the notifications (not unlike cumulative ETEN, though the specification is somewhat older).

We performed high-speed testing those SCPS options we could test and found no significant performance improvements.
The report is being written, but not yet available.  The results were presented as the 2nd Space Internet Workshop in June and will be 
presented at SpaceOps 2002.

http://roland.grc.nasa.gov/~ivancic/papers_presentations= /papers.html

Under PRESENTATIONS

"SCPS-TP, TCP and Rate-Based Protocol Evaluation," (Includes multi-flow data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file size 951,808 bytes

Interesting.  Slide 14 shows the rate-based theory for a 10Mbyte (80 Mbit) file transfer across a 500msec delay link.  Accounting for just clocking the data (0.8 sec) and one round-trip for some sort of end-of-file acknowledgement (0.5sec) brings the maximum throughput to ~61Mbps.  Perhaps the theoretical maximum was for a longer transfer and only accounted for header (and retransmission) overhead.

What's more curious is why all the rate-based protocols are down around 30Mbps, especially since it's trivial to run SCPS to 60 or 80Mbps, even on 266 to 300MHz-class machines.  You say that the rate-based protocols need more work, but question anyone will immediately ask is: why?  Were there losses at the network interface like you were seeing for NetBSD, or is Solaris just really slow?  What do the tcpdumps show?  Do the various protocols simply pause transmitting periodically, and if so, why?  Are you able to push the average throughput closer to the theoretical value as file size increases?  If not, why not?  Obviously you've done a lot of work understanding and comparing the various protocols; maybe you could let that section of the paper leak out a bit early?

All slide 17 shows is that TCPs that assume congestion back off a lot in the face of loss.  I'm curious as to why you didn't show TCP Vegas with the default source of loss assumed to be corruption.  This is still 'congestion-friendly' as it will slow down when it detects queueing, but performs quite well when confronted with a lightly loaded network with moderate error rates.

As for the warning on the last slide, it should be considered in conjunction with your observation that non-congestion-controlled flows should be used only when they will not overly interfere with congestion-controlled ones.  Unless one specifically chooses to disable all congestion control in SCPS, it uses rate control in conjunction with a congestion control algorithm (VJ or Vegas).  This allows us to ensure that the congestion control algorithm doesn't overrun the bottleneck link rate and auto-congest the network.  When using congestion control, SCPS-TP behaves like, and interoperates with, other TCP implementations, and it is appropriate for it to use IPPROTO 6.  For the case when SCPS-TP is running without congestion control, it should only be used on networks where it will not interfere with congestion controlled traffic.  Note that the CBQ mechanisms of Linux kernels since 2.2 (and the traffic engineering mechanisms of common commercial routers) can appropriately segregate flows.

By the way, SCPS-TP advertises TCP's protocol number for reliable transport protocol selections.  It does this even if the pure rate-based transmission is used.  IMO, this is terrible as it  make QoS and queue management very difficult.  I may be putting a rate-based protocol into a WRED queue.  Guess who loses.

Will

--=====================_16209227==_.ALT-- From owner-tcpsat@grc.nasa.gov Fri Jun 14 17:11:56 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15404 for ; Fri, 14 Jun 2002 17:11:56 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 490C8641B8 for ; Fri, 14 Jun 2002 17:12:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EL0LZ4020806 for tcpsat-outgoing; Fri, 14 Jun 2002 17:00:21 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EL0Jra020792; Fri, 14 Jun 2002 17:00:19 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EL0ISl004354; Fri, 14 Jun 2002 17:00:18 -0400 (EDT) Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.160.40]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 35521C69B9; Fri, 14 Jun 2002 17:00:18 -0400 (EDT) Received: from ahooke-2k.jpl.nasa.gov (hookepc2.jpl.nasa.gov [137.79.10.230]) by eis-msg-012.jpl.nasa.gov (8.12.1/8.12.1) with ESMTP id g5EL0Eol000672; Fri, 14 Jun 2002 14:00:15 -0700 (PDT) Message-Id: <5.1.0.14.2.20020614134822.021dfe48@pop.jpl.nasa.gov> X-Sender: ahooke@pop.jpl.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Jun 2002 13:55:45 -0700 To: tcpsat@grc.nasa.gov, David Carek From: "Adrian J. Hooke" Subject: Re: Satellites running IP In-Reply-To: <3D08EADE.7000006@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1379059142==_.ALT" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk --=====================_1379059142==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:56 PM 6/13/2002 -0400, David Carek wrote: >I'm looking for existing satellites that use IP or other Internet >protocols on board or in their air to ground communications. If you know >of any currently flying satellites with such capabilities I'd appreciate >the references. David: what problems are you trying to solve, and why? At 04:02 PM 6/14/2002 -0400, William Ivancic wrote: >??? I don't understand the comment. I'm taking SCPS-TP end-to-end, not >SCPS-TP as a gateway. And in what operational configurations are you trying to solve them? ///adrian --=====================_1379059142==_.ALT Content-Type: text/html; charset="us-ascii" At 02:56 PM 6/13/2002 -0400, David Carek wrote:
I'm looking for existing satellites that use IP or other Internet protocols on board or in their air to ground communications.  If you know of any currently flying satellites with such capabilities I'd appreciate the references.

David: what problems are you trying to solve, and why?

At 04:02 PM 6/14/2002 -0400, William Ivancic wrote:
??? I don't understand the comment.  I'm taking SCPS-TP end-to-end, not SCPS-TP as a gateway.

And in what operational configurations are you trying to solve them?

///adrian
--=====================_1379059142==_.ALT-- From owner-tcpsat@grc.nasa.gov Fri Jun 14 17:17:15 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15577 for ; Fri, 14 Jun 2002 17:17:15 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 3B66564187 for ; Fri, 14 Jun 2002 17:17:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EL8W5a022827 for tcpsat-outgoing; Fri, 14 Jun 2002 17:08:32 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EL8Ura022808 for ; Fri, 14 Jun 2002 17:08:30 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EL8SSl005801 for ; Fri, 14 Jun 2002 17:08:28 -0400 (EDT) Received: from gst.gst.com (gst.gst.com [208.219.159.150]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 35276C69ED for ; Fri, 14 Jun 2002 17:08:27 -0400 (EDT) Received: from gst.com (travis@mako.gst.com [208.219.159.163] (may be forged)) by gst.gst.com (8.11.6/8.11.6) with ESMTP id g5EL1OA29933; Fri, 14 Jun 2002 17:01:24 -0400 Message-ID: <3D0A5B4A.485E0B9E@gst.com> Date: Fri, 14 Jun 2002 17:08:26 -0400 From: Eric Travis X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: Re: Satellites running IP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Will, >On Thur, 13 June 2002, William Ivancic wrote: > > At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote: > > > >> On Thu, 13 Jun 2002, David Carek wrote: > >> > >> > I'm looking for existing satellites that use IP or other Internet > >> > protocols on board or in their air to ground communications. ..... > >> > >> Really, isn't this what NASA et al. have been developing SCPS for? Ah - there is just so much of your old baggage here... You responded: > Does anyone know of someone "flying" an onboard SCPS stack? Outside of shuttle/station, the number of platforms that have flown a SCPS stack for onboard use is the same as those that have flown a native Internet protocol stack. Actually, the number of "SCPS compliant missions" is double that because the native Internet protocol stacks are SCPS compliant (This is no accident, as we were the *original* proponents of IP deployment on space vehicles - when it made sense to do so) If your intent was to argue to be that this makes "SCPS" (again, which includes TCP, UDP, ICMP, etc. and IP) impractical for space deployment, please do proceed down this path. The rope is approximately the right length... But none of this is not what Lloyd asked is it? The answer to Lloyd's question is : Yes CCSDS's did the pioneering work into onboard IP based networking (a free clue - this was the SCPS effort), a stack was flown over 6 years ago and it did splendidly. Despite these now ancient accomplishments, no missions care then, and even now missions just don't need IP and wouldn't benefit from it. Maybe someday... Since spacecraft, link and ground infrastructure are certainly capable of supporting IP (as I said, we did it 6 years ago without disturbing a thing)... just maybe there are reasons for the dearth IP deployment on spacecraft to date? Therefore for everyone's benefit, would you please: Name one mission that failed because of the lack of an IP protocol stack across the spacelink? Name one mission that returned less science because it wasn't "IP enabled"? IP on the ground distribution network seems to be satisfying all the needs so far - when it makes sense to extend it over the spacelink, it'll happen. Spacecraft designers are notoriously conservation folks, and I don't believe it is difficult to understand why. I would actually love to see an large IP-based science mission flown as we'd learn some interesting things about the communications problems. I've been waiting about a decade for this. You new-age "IP zealots" are latecomers :o) Please just get over it and let's advocate the spending of NASA's funds on actual scientific pursuits rather than 'kewl things to do with Internet stuff'. > Does anyone know of any commercial applications that call the > SCPS-TP options. SCPS-FP is the only application one I know of. Ummm... Why would you think that an application *needs* to call socket options just because they exist? I think you would lots of commercial applications that don't call TCP options. This proves what? I'd be surprised if most "commercial applications" need to call the SCPS specific TCP options. If it would be beneficial to the hosted applications, chances are the system would be configured to use them by default. Just to set you straight, every "commercial" TCP application that you would ever want to use works just fine over "SCPS-TP" (read: TCP), I do it all the time - but I don't expect it really matters or that anybody really cares. > Does anyone know of a commercial vendor implementing a SCPS-NP router? To > take full advantage of some options in SCPS-TP, one needs as SCPS-NP router. This is certainly new information to me. Exactly which TCP behavior enhancements *require* SCPS-NP and this can not be provided over IP? > We performed high-speed testing those SCPS options we could test > and found no significant performance improvements. Depending on the conditions under which you tested, that probably wouldn't surprise me at all. Of course, you aren't claiming that your (yet undocumented) tests are conclusive - are you? Do you have any non-Powerpoint versions of your results? I'd love to see your results - but more so I'd love to read the technical paper that generated them. Often when running my traffic over the Internet, I also see no performance increase when I'm running a TCP with the SCPS defined enhancements - I see no performance degradation either. However, when I run across more challenged paths (say those that include satellite hops), then I certainly do see improvements. > The report is being written, but not yet available. The results were > presented as the 2nd Space Internet Workshop in June and will be > presented at SpaceOps 2002. > > http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html Hmmm... hopefully the paper will be finished before you present the results again. I'm looking forward to reading, commenting on the actual report. > By the way, SCPS-TP advertises TCP's protocol number for reliable transport > protocol selections. It does this even if the pure rate-based transmission > is used. IMO, this is terrible as it make QoS and queue management very > difficult. I may be putting a rate-based protocol into a WRED queue. Guess > who loses. Well, if someone is foolish enough to stick metal pots into a microwave oven, guess who loses? Obviously this makes metal cookware terrible for deployment in any kitchen environment. IMO, you are a bit confused here. Exactly what are you expressing a concern about here - that it is possible for people to make stupid configuration choices? There are certain configuration options that only make sense if you *know* the characteristics of your entire end-to-end path. Isn't it obvious to you that choosing pure rate-based transmission obviously fits into this category? The rule is darned simple: If you do not have an end-to-end bandwidth reservation, you are foolish (if not just evil) to configuring flows to run with only rate-pacing. The reason that an intelligent person would even consider running in a purely paced manner is when they have arranged to have reserved capacity for the flow *over the entire end-to-end path*. If it is unreasonable for you to have this guarantee, then it is unreasonable to be running without any other congestion mechansims active. Given that you have to actually do work to force this configuration one would guess that a clueful network administrator and end-user would make sure that this makes sense with whatever else was going on in the end-to-end path. If you are upset that you can't make queuing decisions based on a simple check of a protocol ID rather than observed flow behavior, then be happy to have learned something useful outside the parameters of the satellite universe. Not all TCP flavors/implementations have the exact same mechanisms - and the evolution and divergence in behavior is likely to grow over time. Even subtle differences in behavior might want to influence your queuing decisions. Further, there is nothing preventing anybody from hacking a TCP implementation to exhibit antisocial/greedy behavior. Making decisions on *assumed* behavior is ultimately going to be the wrong choice and not going to yield the desired results. Police flows on actual - not assumed - behavior. A robust network can't "trust" its users to be nice, honest and never attempt to consume more resources than they are due. Making such decisions based on a label generated by the end-user entity (even a protocol ID) is just a bad idea. Having managed capacity down to the granularity of individual flows is quite reasonable in a space mission environment. This is the intended use of purely rate limited TCP streams. If someone chooses to misuse this capability, hopefully the flow will be suitably punished for it's non-TCP friendly behavior over shared paths (just as should any purely rate-paced UDP traffic). If you are trying to express a desire to be able to transparently multiplex returned mission science data with traffic like e-mail over a common IP backbone... You would run the very real risk having to retransmit the science data over the spacelink because of terrestrial congestion... that would be an excellent example of a silly configuration decision. Eric From owner-tcpsat@grc.nasa.gov Fri Jun 14 17:49:53 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16550 for ; Fri, 14 Jun 2002 17:49:53 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 405AD641B9 for ; Fri, 14 Jun 2002 17:50:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5ELdrS9000977 for tcpsat-outgoing; Fri, 14 Jun 2002 17:39:53 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ELdqra000968; Fri, 14 Jun 2002 17:39:52 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ELdpSl012095; Fri, 14 Jun 2002 17:39:51 -0400 (EDT) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B93D86418F; Fri, 14 Jun 2002 17:39:50 -0400 (EDT) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw2a.lmco.com (8.11.6/8.11.6) with ESMTP id g5ELdnm20410; Fri, 14 Jun 2002 17:39:50 -0400 (EDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GXP00901TID5D@lmco.com>; Fri, 14 Jun 2002 14:39:49 -0700 (PDT) Received: from emss01i00.ems.lmco.com ([129.197.181.70]) by lmco.com (PMDF V5.2-33 #38886) with ESMTP id <0GXP00HUNTIAFM@lmco.com>; Fri, 14 Jun 2002 14:39:46 -0700 (PDT) Received: by emss01i00.ems.lmco.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 14:39:45 -0700 Content-return: allowed Date: Fri, 14 Jun 2002 14:39:43 -0700 From: "Ahmed, Masuma" Subject: RE: Satellites running IP To: "'Adrian J. Hooke'" , tcpsat@grc.nasa.gov, David Carek Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT At the present time, to my knowledge there is no existing satellite systems in orbit that supports on-board IP processing and routing. Teledesic has design concepts for IP routing on-board and Astrolink has ATM switching capability on-board. However, none of these systems is flying today. Existing commercial systems like Inmarsat and Cyberstar use IP interface at the ground to support Internet applications but the space itself is transparent to IP. NASA ACTS may be the only one today that supports on-board digital processing (e.g., SONET frames) and not bent pipe transponder systems. regards. masuma ---------------------------------------------------------------------------- - Dr. Masuma Ahmed Business & Technology Strategy Leader Lockheed Martin, Management and Data Systems, WR 3200 Zanker Road, San Jose, CA 95134 Tel: 408-473-4140 Fax: 408-473-4961 Email: masuma.ahmed@lmco.com > -----Original Message----- > From: Adrian J. Hooke [SMTP:adrian.j.hooke@jpl.nasa.gov] > Sent: Friday, June 14, 2002 1:56 PM > To: tcpsat@grc.nasa.gov; David Carek > Subject: Re: Satellites running IP > > At 02:56 PM 6/13/2002 -0400, David Carek wrote: > > > I'm looking for existing satellites that use IP or other Internet > protocols on board or in their air to ground communications. If you know > of any currently flying satellites with such capabilities I'd appreciate > the references. > > > David: what problems are you trying to solve, and why? > > At 04:02 PM 6/14/2002 -0400, William Ivancic wrote: > > > ??? I don't understand the comment. I'm taking SCPS-TP end-to-end, > not SCPS-TP as a gateway. > > > And in what operational configurations are you trying to solve them? > > ///adrian > From owner-tcpsat@grc.nasa.gov Fri Jun 14 18:24:24 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17976 for ; Fri, 14 Jun 2002 18:24:24 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id ABF0C641C4 for ; Fri, 14 Jun 2002 18:24:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EMC68Z006524 for tcpsat-outgoing; Fri, 14 Jun 2002 18:12:06 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EMC5ra006517 for ; Fri, 14 Jun 2002 18:12:05 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EMC4Sl016864 for ; Fri, 14 Jun 2002 18:12:04 -0400 (EDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 677AA640E4 for ; Fri, 14 Jun 2002 18:12:04 -0400 (EDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5EMC1U19870 for ; Fri, 14 Jun 2002 18:12:02 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5EMBxk48212 for ; Fri, 14 Jun 2002 18:12:00 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id SAA27926 for tcpsat@lerc.nasa.gov; Fri, 14 Jun 2002 18:11:57 -0400 Date: Fri, 14 Jun 2002 18:11:57 -0400 From: Alaa Youssef Message-Id: <200206142211.SAA27926@scarpia.watson.ibm.com> To: tcpsat@lerc.nasa.gov Subject: Infocom 2003 - CFP Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk [Please accept our appologies if you receive duplicates of this announcement] ************************************************* ******* CALL FOR PAPERS ********* ************************************************* * IEEE INFOCOM 2003 * * The Conference on Computer Communications * * * * March 30 - April 3, 2003, San Francisco * * * * The 22nd Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2003 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 22nd anniversary in San Francisco, California, during the week of March 30 - April 3, 2003. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Ad hoc & sensor networks * Addressing & location management * Admission control * Cellular networks * Content distribution & web caching * Flow & congestion control * Multicast * Network applications & services * Network architectures * Network control by pricing * Network design & planning * Network management & control * Optical networks * Power control * Pricing & billing mechanisms * Quality of service * Queueing/performance evaluation * Resource allocation * Routing algorithms * Scheduling & buffer management * Security & denial of service * Switches & switching * Topology inference * Traffic & performance measurement * Traffic engineering * Web performance * Wireless LANs SCHEDULE (STRICTLY ENFORCED) Full paper due July 10, 2002 Notification of acceptance October 25, 2002 Final version due December 19, 2002 CONFERENCE SCHEDULE Tutorials March 30-31, 2003 Conference April 1-3, 2003 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2003 For general information please contact the Genaral Chair, Fred Bauer (fredbauer@ieee.org) PROGRAM COMMITTEE CO-CHAIRS =========================== Jim Roberts, France Telecom R&D, France (james.roberts@francetelecom.com) Ness Shroff, Purdue University, USA (shroff@ecn.purdue.edu) From owner-tcpsat@grc.nasa.gov Fri Jun 14 21:54:24 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21510 for ; Fri, 14 Jun 2002 21:54:24 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 7333A6416F for ; Fri, 14 Jun 2002 21:54:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EK3FpY006625 for tcpsat-outgoing; Fri, 14 Jun 2002 16:03:15 -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 GRC 8.12.3/8.12.3) with ESMTP id g5EK3Era006619; Fri, 14 Jun 2002 16:03:14 -0400 (EDT) Received: from katrinajoy (tb2-78.lerc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id QAA19215; Fri, 14 Jun 2002 16:03:13 -0400 (EDT) Message-Id: <4.2.1.20020614155641.00bcf770@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 14 Jun 2002 16:02:43 -0400 To: Lloyd Wood From: William Ivancic Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: References: <4.2.1.20020614145705.00bcc470@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk At 08:26 PM 6/14/02 +0100, you wrote: >On Fri, 14 Jun 2002, William Ivancic wrote: > > > > When rate-based, SCPS-TP is still sending TCP-style packets, so the > > >protocol identifier is valid. > > > > I disagree. IMHO, one should not knowingly advertise a protocol number if > > one is not conforming to those protocol characteristics. > >well, that would be enough to kill pwe3 work entirely if anyone there >agreed with that. If I read the workings of this group correctly, it is more like gateway implementations were one knows the network between the gateways and is controlling things appropriately. > > IMHO, SCPS should advertise it's own protocol number when > > running rate-based, no congestion control. > >just so that any assumptions made by intermediate systems hold true? >not very e2e of you. ??? I don't understand the comment. I'm taking SCPS-TP end-to-end, not SCPS-TP as a gateway. >And I don't see >http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.ps >http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.txt >advocating a new protocol number either, even though it modifies the >congestion control mechanisms. If I interpreted the draft correctly, congestion control is still used here, just modified. Will ======================================= 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 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic From owner-tcpsat@grc.nasa.gov Fri Jun 14 22:41:37 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22704 for ; Fri, 14 Jun 2002 22:41:37 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 556D2C69AF for ; Fri, 14 Jun 2002 22:41:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5EKgtCr016206 for tcpsat-outgoing; Fri, 14 Jun 2002 16:42:55 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EKgrra016198; Fri, 14 Jun 2002 16:42:53 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5EKgqSl001297; Fri, 14 Jun 2002 16:42:52 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 3324264092; Fri, 14 Jun 2002 16:42:52 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17IxuA-0004dV-00; Fri, 14 Jun 2002 21:42:46 +0100 Date: Fri, 14 Jun 2002 21:42:45 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: William Ivancic Cc: tcpsat@grc.nasa.gov Subject: Re: Satellites running IP In-Reply-To: <4.2.1.20020614155641.00bcf770@popserve.grc.nasa.gov> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17IxuA-0004dV-00*S9vlz4d9yq6* (SECM, UniS) Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk On Fri, 14 Jun 2002, William Ivancic wrote: > At 08:26 PM 6/14/02 +0100, you wrote: > >On Fri, 14 Jun 2002, William Ivancic wrote: > > > > > > When rate-based, SCPS-TP is still sending TCP-style packets, so the > > > >protocol identifier is valid. > > > > > > I disagree. IMHO, one should not knowingly advertise a protocol number if > > > one is not conforming to those protocol characteristics. > > > >well, that would be enough to kill pwe3 work entirely if anyone there > >agreed with that. > > If I read the workings of this group correctly, it is more like gateway > implementations were one knows the network between the gateways and is > controlling things appropriately. the network between those gateways is an IP cloud, with all the possibility for reordering, jitter, loss etc. that that implies. In particular, the timing expectations for the tunnelled protocol traffic may be imperfectly met and outside the specification of the emulated network and its applications - and those changes in timing form the analogy with changes in TCP timing here. Timing changes, but things are still made to work. > > > IMHO, SCPS should advertise it's own protocol number when > > > running rate-based, no congestion control. > > > >just so that any assumptions made by intermediate systems hold true? > >not very e2e of you. > > ??? I don't understand the comment. I'm taking SCPS-TP end-to-end, not > SCPS-TP as a gateway. likewise. You stressed the importance of preserving e2e behaviour, and gave the example of something in the middle was inspecting protocol type and using assumptions about expected e2e bahviour for queuing behaviour at that point. Dangerous, as you said. (and a similar argument doesn't work for UDP, or indeed other protocols whose behavior is not specified as TCP's is.) > >And I don't see > >http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.ps > >http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.txt > >advocating a new protocol number either, even though it modifies the > >congestion control mechanisms. > > If I interpreted the draft correctly, congestion control is still used > here, just modified. So how much modification do you demand before you define it as 'no longer congestion control' and demand a new protocol type? I've given a number of examples of modified timing where the protocol type/identity/bits on the wire remain the same, and given the general slackness of TCP system timers and their specification in general I think it's a moot point. Especially in an Internet where uncontrolled UDP traffic can run amok, and where the same intermediate fairness/limiting/queuing mechanisms to control such traffic can also be applied to TCP traffic. Every UDP application behaves differently with the UDP packets it sends; every UDP application should get its own protocol type! L. From owner-tcpsat@grc.nasa.gov Sun Jun 16 16:23:05 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07594 for ; Sun, 16 Jun 2002 16:23:05 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id F359E641CC for ; Sun, 16 Jun 2002 16:23:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5GK6GlE027388 for tcpsat-outgoing; Sun, 16 Jun 2002 16:06:16 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5GK6Fra027384 for ; Sun, 16 Jun 2002 16:06:15 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5GK6ESl019847 for ; Sun, 16 Jun 2002 16:06:14 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 079D6640D6 for ; Sun, 16 Jun 2002 16:06:14 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17JgHl-00021q-00; Sun, 16 Jun 2002 21:06:05 +0100 Date: Sun, 16 Jun 2002 21:05:55 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Ahmed, Masuma" Cc: tcpsat@grc.nasa.gov Subject: RE: Satellites running IP In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17JgHl-00021q-00*My/F9i0rEns* (SECM, UniS) Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk On Fri, 14 Jun 2002, Ahmed, Masuma wrote: > Teledesic has design concepts for IP routing on-board Teledesic's published material has discussed their own proprietary protocol. Do you know of any public references supporting this? (Actually, I'd quite like to know what Teledesic's current constellation design concept is...) > and Astrolink has ATM switching capability on-board. However, none > of these systems is flying today. or fully designed? > Existing commercial systems like > Inmarsat and Cyberstar use IP interface at the ground to support > Internet applications but the space itself is transparent to IP. > NASA ACTS may be the only one today that supports on-board digital > processing (e.g., SONET frames) and not bent pipe transponder > systems. a 'bent pipe' (okay, really regenerative rather than traditional analogue-components freq-shifting) system can encompass dsp, of course - Globalstar? Going digital makes switching between spotbeams much easier... As for on-board digital processing of frames, what does Iridium do? (Okay, the frames aren't your usual network frames, but...) thanks, L. putting 'bent-pipe' in the 'what goes up must come straight down' category. > Dr. Masuma Ahmed > Business & Technology Strategy Leader > Lockheed Martin, Management and Data Systems, WR > 3200 Zanker Road, San Jose, CA 95134 > Tel: 408-473-4140 > Fax: 408-473-4961 > Email: masuma.ahmed@lmco.com From owner-tcpsat@grc.nasa.gov Mon Jun 17 11:19:05 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07320 for ; Mon, 17 Jun 2002 11:19:05 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 70599641CA for ; Mon, 17 Jun 2002 11:19:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5HF46oZ018150 for tcpsat-outgoing; Mon, 17 Jun 2002 11:04:06 -0400 (EDT) Received: from opus.lerc.nasa.gov (opus.lerc.nasa.gov [139.88.102.98]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5HF44ra018136; Mon, 17 Jun 2002 11:04:04 -0400 (EDT) Received: from grc.nasa.gov (ras136.lerc.nasa.gov [139.88.123.136]) by opus.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA21027; Mon, 17 Jun 2002 11:04:03 -0400 Message-ID: <3D0DFA74.7000504@grc.nasa.gov> Date: Mon, 17 Jun 2002 11:04:20 -0400 From: David Carek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Adrian J. Hooke" Cc: tcpsat@grc.nasa.gov Subject: Re: Satellites running IP References: <5.1.0.14.2.20020614134822.021dfe48@pop.jpl.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Adrian J. Hooke wrote: > At 02:56 PM 6/13/2002 -0400, David Carek wrote: > >> I'm looking for existing satellites that use IP or other Internet >> protocols on board or in their air to ground communications. If you >> know of any currently flying satellites with such capabilities I'd >> appreciate the references. > > > David: what problems are you trying to solve, and why? ... > And in what operational configurations are you trying to solve them? I'm trying to identify available options for an IP compliant LEO science satellite, including susbsystem communications on-board as well as command, control, and telemetry to/from ground. Two communications paths would exist: One direct LEO to ground; and one to ground via TDRSS(GEO). A collegue and I have been tasked to write a communications architecute paper for such a system, that uses only Internet protocols end to end. Obviously, mission requirements and budget would ultimately define what is used on a real mission, but this is just a cut at a generic mission. The problem is, that I keep coming up with more reasons not to use Internet protols, than reasons to use them. Having worked on flight software I know the value in minimizing the SLOC count and complexity of flight code. I supposed if a "flight qualified" stack were available, it would be much more readily accepted. I personally like the SCPS specifications, but I've been asked to try to identify options using only current Internet standards. This creates a problem, in that some application level protocol will be necessary ... so I'm kind of back in the non-standards realm. That's why I wanted to see if anybody has already done this, and to what extent. From owner-tcpsat@grc.nasa.gov Mon Jun 17 11:57:56 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08646 for ; Mon, 17 Jun 2002 11:57:56 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D4C8B64190 for ; Mon, 17 Jun 2002 11:58:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5HFlSpV000773 for tcpsat-outgoing; Mon, 17 Jun 2002 11:47:28 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5HFlQra000767 for ; Mon, 17 Jun 2002 11:47:26 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5HFlPSl021393 for ; Mon, 17 Jun 2002 11:47:26 -0400 (EDT) Received: from hawk.dcu.ie (mail.dcu.ie [136.206.1.5]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 7ED8964178 for ; Mon, 17 Jun 2002 11:47:25 -0400 (EDT) Received: from camac.dcu.ie (136.206.2.1) by hawk.dcu.ie (6.0.040) id 3CC55D7900180EE6 for tcpsat@grc.NASA.gov; Mon, 17 Jun 2002 16:47:22 +0100 Received: by camac.dcu.ie (Postfix, from userid 15185) id 9B2C610287; Mon, 17 Jun 2002 16:47:22 +0100 (IST) Received: from localhost (localhost [127.0.0.1]) by camac.dcu.ie (Postfix) with ESMTP id 8DF473C80C for ; Mon, 17 Jun 2002 16:47:22 +0100 (IST) Date: Mon, 17 Jun 2002 16:47:22 +0100 (IST) From: Colin Paul Gloster X-Sender: glostec2@camac.dcu.ie Reply-To: Colin_Paul_Gloster@acm.org, tcpsat@grc.nasa.gov To: tcpsat@grc.nasa.gov Subject: Re: Satellites running IP In-Reply-To: <3D0DFA74.7000504@grc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk On Mon, 17 Jun 2002, David Carek wrote: "[..] The problem is, that I keep coming up with more reasons not to use Internet protols, than reasons to use them. [..]" David, Could you please indicate what some of these reasons would be? Regards, Colin Paul Gloster From owner-tcpsat@grc.nasa.gov Mon Jun 17 13:48:13 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13714 for ; Mon, 17 Jun 2002 13:48:12 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A653C641E1 for ; Mon, 17 Jun 2002 13:48:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5HHZl18028993 for tcpsat-outgoing; Mon, 17 Jun 2002 13:35:47 -0400 (EDT) Received: from opus.lerc.nasa.gov (opus.lerc.nasa.gov [139.88.102.98]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5HHZkra028978; Mon, 17 Jun 2002 13:35:46 -0400 (EDT) Received: from grc.nasa.gov (ras136.lerc.nasa.gov [139.88.123.136]) by opus.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA21125; Mon, 17 Jun 2002 13:35:44 -0400 Message-ID: <3D0E1E01.5080606@grc.nasa.gov> Date: Mon, 17 Jun 2002 13:36:01 -0400 From: David Carek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin_Paul_Gloster@acm.org, tcpsat@grc.nasa.gov Subject: Re: Satellites running IP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Colin Paul Gloster wrote: > On Mon, 17 Jun 2002, David Carek wrote: > "[..] > > The problem is, that I keep coming up with more reasons not to use > Internet protols, than reasons to use them. [..]" > > David, > Could you please indicate what some of these reasons would > be? > Regards, > Colin Paul Gloster Sure False Perception of Standards - There is a perception that using Internet standards is actually a single standard, when in fact it is a collage interpretations and implementations of RFC's. I doubt any two TCP/IP stacks implement the standards the same way. The standard is actually the least common demoninator of the various implemtations. Flight Qualification (Increased Potential for Software Faults) - Adding 15000 lines of code that someone else wrote to your satellite creates a black box of software that is extremely difficult if not impossible to thouroghly test. I have had a bad experience with one stack we used on a shuttle experiment that would hang the system when it recieved any non-tcp packets. This was a older real-time embedded system (that shall remain nameless). It should have been impossible for the TCP/IP module to completely hang the system ... but it did. Increased software = increased complexity = increased chance for errors Other potential problems include: Technology Lag/Obsolescence (satellite technology generally 5-10 years behind terestrial) RTOS support Deterministic Timing Requirements (onboard systems) Performance Limitations of Rad Hard processors Reliability (TCP reliability might not be good enough) I've got others ... but that's a start. This isn't to say these issues can't be overcome. They are just engineering problems and entirely workable. And certianly a system that is compatible with Internet systems is definitely beneficial to the overall communications architecture ... especially when integrating into the ground systems. From owner-tcpsat@grc.nasa.gov Tue Jun 18 08:49:04 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15209 for ; Tue, 18 Jun 2002 08:49:04 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1D6ADC6A54 for ; Tue, 18 Jun 2002 08:49:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5ICTuNB009025 for tcpsat-outgoing; Tue, 18 Jun 2002 08:29:56 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ICTtra009015 for ; Tue, 18 Jun 2002 08:29:55 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ICTsSl018151 for ; Tue, 18 Jun 2002 08:29:54 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 90A066412F for ; Tue, 18 Jun 2002 08:29:53 -0400 (EDT) Received: from DSHELL-W2K.cisco.com (rtp-dial-1-139.cisco.com [10.83.97.139]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA03190; Tue, 18 Jun 2002 05:29:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20020618082508.0170da30@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jun 2002 08:25:34 -0400 To: Eric Travis From: Daniel Shell Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: <3D0A5B4A.485E0B9E@gst.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Is SCPS an IETF RFC on a standards track yet? At 05:08 PM 6/14/2002, Eric Travis wrote: >Will, > > >On Thur, 13 June 2002, William Ivancic wrote: > > > > At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote: > > > > > >> On Thu, 13 Jun 2002, David Carek wrote: > > >> > > >> > I'm looking for existing satellites that use IP or other Internet > > >> > protocols on board or in their air to ground communications. ..... > > >> > > >> Really, isn't this what NASA et al. have been developing SCPS for? > >Ah - there is just so much of your old baggage here... > >You responded: > > > Does anyone know of someone "flying" an onboard SCPS stack? > >Outside of shuttle/station, the number of platforms that have >flown a SCPS stack for onboard use is the same as those that >have flown a native Internet protocol stack. Actually, the >number of "SCPS compliant missions" is double that because >the native Internet protocol stacks are SCPS compliant >(This is no accident, as we were the *original* proponents of >IP deployment on space vehicles - when it made sense to do so) > >If your intent was to argue to be that this makes "SCPS" >(again, which includes TCP, UDP, ICMP, etc. and IP) impractical >for space deployment, please do proceed down this path. The rope >is approximately the right length... > >But none of this is not what Lloyd asked is it? > >The answer to Lloyd's question is : > > Yes > >CCSDS's did the pioneering work into onboard IP based networking >(a free clue - this was the SCPS effort), a stack was flown over >6 years ago and it did splendidly. Despite these now ancient >accomplishments, no missions care then, and even now missions just >don't need IP and wouldn't benefit from it. Maybe someday... > >Since spacecraft, link and ground infrastructure are certainly >capable of supporting IP (as I said, we did it 6 years ago without >disturbing a thing)... just maybe there are reasons for the dearth >IP deployment on spacecraft to date? > >Therefore for everyone's benefit, would you please: > > Name one mission that failed because of the lack of an > IP protocol stack across the spacelink? > > Name one mission that returned less science because > it wasn't "IP enabled"? > >IP on the ground distribution network seems to be satisfying >all the needs so far - when it makes sense to extend it over >the spacelink, it'll happen. > >Spacecraft designers are notoriously conservation folks, >and I don't believe it is difficult to understand why. > >I would actually love to see an large IP-based science mission >flown as we'd learn some interesting things about the communications >problems. I've been waiting about a decade for this. You new-age >"IP zealots" are latecomers :o) > >Please just get over it and let's advocate the spending >of NASA's funds on actual scientific pursuits rather than >'kewl things to do with Internet stuff'. > > > Does anyone know of any commercial applications that call the > > SCPS-TP options. SCPS-FP is the only application one I know of. > >Ummm... Why would you think that an application *needs* to call >socket options just because they exist? I think you would lots >of commercial applications that don't call TCP options. This >proves what? > >I'd be surprised if most "commercial applications" need to call the >SCPS specific TCP options. If it would be beneficial to the hosted >applications, chances are the system would be configured to use them >by default. > >Just to set you straight, every "commercial" TCP application that >you would ever want to use works just fine over "SCPS-TP" (read: TCP), >I do it all the time - but I don't expect it really matters or >that anybody really cares. > > > Does anyone know of a commercial vendor implementing a SCPS-NP router? To > > take full advantage of some options in SCPS-TP, one needs as SCPS-NP > router. > >This is certainly new information to me. > >Exactly which TCP behavior enhancements *require* SCPS-NP and >this can not be provided over IP? > > > We performed high-speed testing those SCPS options we could test > > and found no significant performance improvements. > >Depending on the conditions under which you tested, that probably >wouldn't surprise me at all. Of course, you aren't claiming that >your (yet undocumented) tests are conclusive - are you? > >Do you have any non-Powerpoint versions of your results? >I'd love to see your results - but more so I'd love to read >the technical paper that generated them. > >Often when running my traffic over the Internet, I also see no >performance increase when I'm running a TCP with the SCPS defined >enhancements - I see no performance degradation either. > >However, when I run across more challenged paths (say those that >include satellite hops), then I certainly do see improvements. > > > The report is being written, but not yet available. The results were > > presented as the 2nd Space Internet Workshop in June and will be > > presented at SpaceOps 2002. > > > > http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html > >Hmmm... hopefully the paper will be finished before you present the >results again. I'm looking forward to reading, commenting on the actual >report. > > > By the way, SCPS-TP advertises TCP's protocol number for reliable transport > > protocol selections. It does this even if the pure rate-based transmission > > is used. IMO, this is terrible as it make QoS and queue management very > > difficult. I may be putting a rate-based protocol into a WRED > queue. Guess > > who loses. > >Well, if someone is foolish enough to stick metal pots into a microwave >oven, guess who loses? Obviously this makes metal cookware terrible for >deployment in any kitchen environment. > >IMO, you are a bit confused here. Exactly what are you expressing a concern >about here - that it is possible for people to make stupid configuration >choices? > >There are certain configuration options that only make sense if you >*know* the characteristics of your entire end-to-end path. Isn't it >obvious to you that choosing pure rate-based transmission obviously >fits into this category? > >The rule is darned simple: > > If you do not have an end-to-end bandwidth reservation, > you are foolish (if not just evil) to configuring > flows to run with only rate-pacing. > >The reason that an intelligent person would even consider running >in a purely paced manner is when they have arranged to have reserved >capacity for the flow *over the entire end-to-end path*. > >If it is unreasonable for you to have this guarantee, then it is >unreasonable to be running without any other congestion mechansims >active. > >Given that you have to actually do work to force this configuration >one would guess that a clueful network administrator and end-user >would make sure that this makes sense with whatever else was going >on in the end-to-end path. > >If you are upset that you can't make queuing decisions based on a >simple check of a protocol ID rather than observed flow behavior, >then be happy to have learned something useful outside the parameters >of the satellite universe. > >Not all TCP flavors/implementations have the exact same mechanisms - and >the evolution and divergence in behavior is likely to grow over time. >Even subtle differences in behavior might want to influence your queuing >decisions. Further, there is nothing preventing anybody from hacking a >TCP implementation to exhibit antisocial/greedy behavior. > >Making decisions on *assumed* behavior is ultimately going to be the >wrong choice and not going to yield the desired results. Police flows >on actual - not assumed - behavior. > >A robust network can't "trust" its users to be nice, honest and never >attempt to consume more resources than they are due. Making such decisions >based on a label generated by the end-user entity (even a protocol ID) >is just a bad idea. > >Having managed capacity down to the granularity of individual flows >is quite reasonable in a space mission environment. This is the >intended use of purely rate limited TCP streams. If someone chooses >to misuse this capability, hopefully the flow will be suitably punished >for it's non-TCP friendly behavior over shared paths (just as should >any purely rate-paced UDP traffic). > >If you are trying to express a desire to be able to transparently >multiplex returned mission science data with traffic like e-mail >over a common IP backbone... You would run the very real risk having >to retransmit the science data over the spacelink because of terrestrial >congestion... that would be an excellent example of a silly configuration >decision. > >Eric Dan Shell Network Architect CISCO Systems Gobal Defense and Space Group Wireless/Mobile Networking/ Satellite 216 643 2422 From owner-tcpsat@grc.nasa.gov Tue Jun 18 12:13:55 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24904 for ; Tue, 18 Jun 2002 12:13:50 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id D2EBA640FA for ; Tue, 18 Jun 2002 12:13:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5IFx4QB012123 for tcpsat-outgoing; Tue, 18 Jun 2002 11:59:04 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IFx0ra012056 for ; Tue, 18 Jun 2002 11:59:01 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IFwxSl029020 for ; Tue, 18 Jun 2002 11:58:59 -0400 (EDT) Received: from gst.gst.com (gst.gst.com [208.219.159.150]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1B731C696D for ; Tue, 18 Jun 2002 11:58:59 -0400 (EDT) Received: from gst.com (travis@mako.gst.com [208.219.159.163] (may be forged)) by gst.gst.com (8.11.6/8.11.6) with ESMTP id g5IFpIu19966; Tue, 18 Jun 2002 11:51:18 -0400 Message-ID: <3D0F58BF.7EC6CBD5@gst.com> Date: Tue, 18 Jun 2002 11:58:55 -0400 From: Eric Travis X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Shell Cc: tcpsat@grc.nasa.gov Subject: Re: Satellites running IP References: <4.3.2.7.2.20020618082508.0170da30@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Shell wrote: > > Is SCPS an IETF RFC on a standards track yet? > > Dan Shell > Network Architect > CISCO Systems > Gobal Defense and Space Group > Wireless/Mobile Networking/ Satellite > 216 643 2422 Hi Dan, How are things going at Glenn? I'm confused by what you are asking but you've been affiliated with NASA/Glenn and familiarity with SCPS goes back long enough for me to remind you (sadly, not for the first time): SCPS is NOT a protocol, but it is a set of recommendations covering four protocol layers (or 3.5 if you consider security a sublayer). Lots of things in the SCPS recommendations are covered by IETF RFCs that are standards or standards track - those things include such obscure things as IP, TCP, UDP, ICMP, etc. You knew all that, however. If you are specifically asking whether the enhancements that contribute to TCP Tranquility are covered by an IETF RFC (Standard, Standards Track, Experimental, etc.) - then the answer is: Nope - nobody every claimed they were, and nobody in known space loses any sleep over it. But: The SCPS options have valid IANA assignments (Options 20-23) and the protocol 106 covers operation when using the SCPS compressed TCP headers. As an aside: I happen to pass lots of traffic onto the Internet using TCP-Tranquility and I'm at least as nice as every other TCP flow that I observe. Had NASA (or any other Space agency) expressed a non niche interest (backed with the commitment of necessary resources) in deploying any Internet derived technologies over the space link and beyond, the TCP modifications probably would have been submitted as IDs with the desirement/goal of having them someday make Experimental RFCs[*]; [*] If I remember correctly, you folks at GRC stated several times that you were going to take elements of the SCPS recommendations into IETF as part of the ACTS 118X (or Next?) activities - maybe I should be asking you your question - eh? :o) As it stands, the question needs to be answered: Why waste the IETF's time and meeting space on such a insignificant problem space (no pun desired) that even the mission folk at the space agencies don't realm consider more than research? Does everything need to be covered by an IETF Standard? As I've said many time before (to you and others): for a terrestrial environment, the elements of the TCP-Tranquility feature set are experimental and tailored primarily for the space environment (but work well in any lossy tetherless network): Pure Rate Pacing is only useful for reserved paths Selective Negative Acknowledgements are best for environments far more lossy than should be on any end-to-end path going over the Internet backbone. The Vegas modifications seem to work well in general but there still *may* be some nasty edge conditions in networks that would not be typical to the space environment. Any bandwidth estimation techniques are likely to be burdened by the same concerns. Separating congestion signaling from loss: We've never advocated running a default loss assumption other than congestion for anything sharing an end-to-end path with a public network (that may have different assumptions and not the necessary machinery to explicitly signal congestion) Explicit signaling of loss (trends) I seem to remember some traffic polling for interest on this topic (this mailing list or end-to-end); This is somewhat of a localized issue and maybe not something that needs an IETF standard. Link outages are a local problem and probably not something that requires an IETF standard. There is more, need I continue down the list or have I made the point? We've never been looking to push these concepts on a wired infrastructure, but rather have always advocated using them in networks which interface to a wired infrastructure. The most valuable thing that the space community (and anyone else) gets from protocol standards are standard *interfaces* - which include important things like header formats; Further, standardized state machines seem to track across diverse environments, but the behaviors not covered by those state machines may not. It is not clear to many of us that the protocol behaviors which are best for operating over a diverse terrestrial network are necessarily the best behaviors for operation over a resource constrained, time bounded delivery infrastructure that is prevalent in most space environments (and more than a few tetherless environments) You've probably been dealing in networking for long enough that you probably remember the stupid/evil days of GOSIP - right? Please don't depress me and claim that everything used in a space environment needs to be blessed as an IETF Standard (or Standards track) RFC? Do you think the behavior of all the traffic that you are seeing on your networks is strictly covered by (and conforming to) IETF Standards? Faith in guiding principles *can* lead to many wonderful things, Dogma *always* leads to disaster, grief and collateral damage... Now - what was your question again? Eric From owner-tcpsat@grc.nasa.gov Tue Jun 18 13:16:35 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27021 for ; Tue, 18 Jun 2002 13:16:35 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 1E1EE64117 for ; Tue, 18 Jun 2002 13:16:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5IH4pt5029908 for tcpsat-outgoing; Tue, 18 Jun 2002 13:04:51 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IH4nra029900 for ; Tue, 18 Jun 2002 13:04:49 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IH4mSl010606 for ; Tue, 18 Jun 2002 13:04:49 -0400 (EDT) Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.160.40]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 69171640B8 for ; Tue, 18 Jun 2002 13:04:48 -0400 (EDT) Received: from ahooke-2k.jpl.nasa.gov (hookepc2.jpl.nasa.gov [137.79.10.230]) by eis-msg-012.jpl.nasa.gov (8.12.1/8.12.1) with ESMTP id g5IH4eol022765; Tue, 18 Jun 2002 10:04:40 -0700 (PDT) Message-Id: <5.1.0.14.2.20020618093400.0213e6a0@pop.jpl.nasa.gov> X-Sender: ahooke@pop.jpl.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 10:04:40 -0700 To: Daniel Shell From: "Adrian J. Hooke" Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: <4.3.2.7.2.20020618082508.0170da30@lint.cisco.com> References: <3D0A5B4A.485E0B9E@gst.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk At 08:25 AM 6/18/2002 -0400, Daniel Shell wrote: >Is SCPS an IETF RFC on a standards track yet? Dan: Could you perhaps ask your question a bit more precisely? Which of the four SCPS protocols would you suggest should be launched on an IETF standards track? If you are talking about the SCPS flavor of TCP (TCP Tranquility), in what context do you ask the question? TCP running between two ground end systems over a satellite link, or TCP running from a ground end system to an end system onboard a satellite? If the latter, what would be the benefit to you of IETF standardization of TCP Tranquility? If it was on a standards track, would CISCO Systems Gobal [sic] Defense and Space Group then be interested in investing corporate funds to build a bunch of COTS products to support space missions? Best regards Adrian J. Hooke Manager, DOD-NASA Space Communications Protocol Standards (SCPS) Project NASA Jet Propulsion Laboratory, Interplanetary Network Directorate M/S 303-400, 4800 Oak Grove Drive Pasadena, California 91109-8099, USA +1.818.354.3063 OFFICE +1.818.653.9553 MOBILE +1 818.354.6290 FAX http://www.scps.org From owner-tcpsat@grc.nasa.gov Tue Jun 18 16:43:56 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04289 for ; Tue, 18 Jun 2002 16:43:56 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 06C48C6A47 for ; Tue, 18 Jun 2002 16:44:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5IKTron021520 for tcpsat-outgoing; Tue, 18 Jun 2002 16:29:53 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IKTqra021508 for ; Tue, 18 Jun 2002 16:29:52 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IKToSl015728 for ; Tue, 18 Jun 2002 16:29:50 -0400 (EDT) Received: from hwembaz0001.honeywell.com (hwembaz0001.honeywell.com [129.239.31.106]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id F0E48C697D for ; Tue, 18 Jun 2002 16:29:44 -0400 (EDT) Received: by hwembaz0001.cas.honeywell.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jun 2002 13:29:40 -0700 Message-ID: <174E624A2F17C64197CCE6AE6BD0094B071869A6@dvtex221.CAS.HONEYWELL.COM> From: brian.smith@honeywell.com To: adrian.j.hooke@jpl.nasa.gov, dshell@cisco.com Cc: tcpsat@grc.nasa.gov Subject: RE: Satellites running IP Date: Tue, 18 Jun 2002 13:29:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Adrian, Excuse me for jumping in on this but I want to mention that Honeywell, as well as others, are beginning to connect aircraft to ground networks using geosynchronous satellites and TCP. For example, we are using INMARSAT Swift64 (64Kbps) circuit connections for this purpose right now. We require than airborne laptops be able to use their normal stacks though so for now are using gateways to handle TCP issues. The potential market is far greater than space based hosts. Regards, Brian Smith Honeywell > -----Original Message----- > From: Adrian J. Hooke [SMTP:adrian.j.hooke@jpl.nasa.gov] > Sent: Tuesday, June 18, 2002 10:05 AM > To: Daniel Shell > Cc: tcpsat@grc.nasa.gov > Subject: Re: Satellites running IP > > At 08:25 AM 6/18/2002 -0400, Daniel Shell wrote: > >Is SCPS an IETF RFC on a standards track yet? > > Dan: > > Could you perhaps ask your question a bit more precisely? Which of the > four > SCPS protocols would you suggest should be launched on an IETF standards > track? > > If you are talking about the SCPS flavor of TCP (TCP Tranquility), in what > > context do you ask the question? TCP running between two ground end > systems > over a satellite link, or TCP running from a ground end system to an end > system onboard a satellite? > > If the latter, what would be the benefit to you of IETF standardization of > > TCP Tranquility? If it was on a standards track, would CISCO Systems Gobal > > [sic] Defense and Space Group then be interested in investing corporate > funds to build a bunch of COTS products to support space missions? > > Best regards > > Adrian J. Hooke > Manager, DOD-NASA Space Communications Protocol Standards (SCPS) Project > NASA Jet Propulsion Laboratory, > Interplanetary Network Directorate > M/S 303-400, 4800 Oak Grove Drive > Pasadena, California 91109-8099, USA > +1.818.354.3063 OFFICE > +1.818.653.9553 MOBILE > +1 818.354.6290 FAX > http://www.scps.org From owner-tcpsat@grc.nasa.gov Tue Jun 18 18:54:01 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07624 for ; Tue, 18 Jun 2002 18:54:00 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 431AFC6A66 for ; Tue, 18 Jun 2002 18:54:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5IMebWU014621 for tcpsat-outgoing; Tue, 18 Jun 2002 18:40:37 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IMeara014617 for ; Tue, 18 Jun 2002 18:40:36 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5IMeZSl005232 for ; Tue, 18 Jun 2002 18:40:35 -0400 (EDT) Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.160.40]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 1240F640F8 for ; Tue, 18 Jun 2002 18:40:35 -0400 (EDT) Received: from ahooke-2k.jpl.nasa.gov (hookepc2.jpl.nasa.gov [137.79.10.230]) by eis-msg-012.jpl.nasa.gov (8.12.1/8.12.1) with ESMTP id g5IMeXol019879; Tue, 18 Jun 2002 15:40:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20020618152552.01d75e20@pop.jpl.nasa.gov> X-Sender: ahooke@pop.jpl.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Jun 2002 15:40:32 -0700 To: brian.smith@honeywell.com From: "Adrian J. Hooke" Subject: RE: Satellites running IP Cc: tcpsat@grc.nasa.gov, l.freudinger@dfrc.nasa.gov In-Reply-To: <174E624A2F17C64197CCE6AE6BD0094B071869A6@dvtex221.CAS.HONE YWELL.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk At 01:29 PM 6/18/2002 -0700, brian.smith@honeywell.com wrote: >For example, we are using INMARSAT >Swift64 (64Kbps) circuit connections for this purpose right now. We require >than airborne laptops be able to use their normal stacks though so for now >are using gateways to handle TCP issues. Brian: Yes, we're aware of these neat aircraft applications via our close work with Larry Freudinger at NASA Dryden Flight Research Center, and in particular with the use of intermediate PEP gateways. The question is whether (in order to use the gateway capabilities) you feel that their various internal flavors of TCP need to be put on an *IETF* standards track. Dan Shell apparently feels that they do; what about you? TCP Tranquility is a full International Standard within the space community; do you feel in any way inhibited from experimenting with its use? Adrian Hooke From owner-tcpsat@grc.nasa.gov Wed Jun 19 09:03:47 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16659 for ; Wed, 19 Jun 2002 09:03:47 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B01E2C6ABA for ; Wed, 19 Jun 2002 09:02:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JCl2dF025370 for tcpsat-outgoing; Wed, 19 Jun 2002 08:47:02 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JCl0ra025358 for ; Wed, 19 Jun 2002 08:47:00 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JCkxSl028217 for ; Wed, 19 Jun 2002 08:47:00 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 0A24164213 for ; Wed, 19 Jun 2002 08:46:59 -0400 (EDT) Received: from DSHELL-W2K.cisco.com (rtp-dial-1-73.cisco.com [10.83.97.73]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA11385; Wed, 19 Jun 2002 05:46:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20020619084548.01712508@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jun 2002 08:46:45 -0400 To: Eric Travis From: Daniel Shell Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: <3D0F58BF.7EC6CBD5@gst.com> References: <4.3.2.7.2.20020618082508.0170da30@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Eric So the answer is no. Sorry for the short reply but I am on vacation will get you a more detailed answer later At 11:58 AM 6/18/2002, Eric Travis wrote: >Daniel Shell wrote: > > > > Is SCPS an IETF RFC on a standards track yet? > > > > Dan Shell > > Network Architect > > CISCO Systems > > Gobal Defense and Space Group > > Wireless/Mobile Networking/ Satellite > > 216 643 2422 > >Hi Dan, > >How are things going at Glenn? > >I'm confused by what you are asking but you've been >affiliated with NASA/Glenn and familiarity with SCPS >goes back long enough for me to remind you (sadly, not >for the first time): > > SCPS is NOT a protocol, but it is a set of > recommendations covering four protocol layers > (or 3.5 if you consider security a sublayer). > >Lots of things in the SCPS recommendations are >covered by IETF RFCs that are standards or standards >track - those things include such obscure things as >IP, TCP, UDP, ICMP, etc. > >You knew all that, however. > >If you are specifically asking whether the enhancements >that contribute to TCP Tranquility are covered by an IETF >RFC (Standard, Standards Track, Experimental, etc.) - then >the answer is: > > Nope - nobody every claimed they were, and > nobody in known space loses any sleep over it. > >But: > > The SCPS options have valid IANA assignments > (Options 20-23) and the protocol 106 covers > operation when using the SCPS compressed TCP > headers. > > As an aside: > I happen to pass lots of traffic onto the Internet > using TCP-Tranquility and I'm at least as nice as > every other TCP flow that I observe. > >Had NASA (or any other Space agency) expressed >a non niche interest (backed with the commitment >of necessary resources) in deploying any Internet >derived technologies over the space link and >beyond, the TCP modifications probably would have >been submitted as IDs with the desirement/goal of >having them someday make Experimental RFCs[*]; > >[*] If I remember correctly, you folks at GRC > stated several times that you were going to > take elements of the SCPS recommendations > into IETF as part of the ACTS 118X (or Next?) > activities - maybe I should be asking you > your question - eh? :o) > >As it stands, the question needs to be answered: > >Why waste the IETF's time and meeting space on such >a insignificant problem space (no pun desired) that >even the mission folk at the space agencies don't >realm consider more than research? > >Does everything need to be covered by an IETF Standard? > >As I've said many time before (to you and others): >for a terrestrial environment, the elements of the >TCP-Tranquility feature set are experimental and tailored >primarily for the space environment (but work well in any >lossy tetherless network): > > Pure Rate Pacing is only useful for reserved paths > > Selective Negative Acknowledgements are best for > environments far more lossy than should be on any > end-to-end path going over the Internet backbone. > > The Vegas modifications seem to work well in general > but there still *may* be some nasty edge conditions > in networks that would not be typical to the space > environment. > > Any bandwidth estimation techniques are > likely to be burdened by the same concerns. > > Separating congestion signaling from loss: > We've never advocated running a default loss assumption > other than congestion for anything sharing an end-to-end > path with a public network (that may have different > assumptions and not the necessary machinery to explicitly > signal congestion) > > Explicit signaling of loss (trends) > I seem to remember some traffic polling for interest > on this topic (this mailing list or end-to-end); > This is somewhat of a localized issue and maybe not > something that needs an IETF standard. > > Link outages are a local problem and probably not something > that requires an IETF standard. > >There is more, need I continue down the list or have I made >the point? > >We've never been looking to push these concepts on a wired >infrastructure, but rather have always advocated using them >in networks which interface to a wired infrastructure. > >The most valuable thing that the space community (and anyone else) >gets from protocol standards are standard *interfaces* - which >include important things like header formats; > >Further, standardized state machines seem to track across diverse >environments, but the behaviors not covered by those state machines >may not. > >It is not clear to many of us that the protocol behaviors which are >best for operating over a diverse terrestrial network are necessarily >the best behaviors for operation over a resource constrained, time >bounded delivery infrastructure that is prevalent in most space >environments (and more than a few tetherless environments) > >You've probably been dealing in networking for long enough that you >probably remember the stupid/evil days of GOSIP - right? > >Please don't depress me and claim that everything used in a space >environment needs to be blessed as an IETF Standard (or Standards >track) RFC? > >Do you think the behavior of all the traffic that you are seeing on >your networks is strictly covered by (and conforming to) IETF Standards? > >Faith in guiding principles *can* lead to many wonderful things, >Dogma *always* leads to disaster, grief and collateral damage... > >Now - what was your question again? > >Eric Dan Shell Network Architect CISCO Systems Gobal Defense and Space Group Wireless/Mobile Networking/ Satellite 216 643 2422 From owner-tcpsat@grc.nasa.gov Wed Jun 19 09:30:24 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17837 for ; Wed, 19 Jun 2002 09:30:24 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C513564231 for ; Wed, 19 Jun 2002 09:30:32 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JDInNf006049 for tcpsat-outgoing; Wed, 19 Jun 2002 09:18:49 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JDIlra006042 for ; Wed, 19 Jun 2002 09:18:47 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JDIkSl005067 for ; Wed, 19 Jun 2002 09:18:46 -0400 (EDT) Received: from mimesweeper.inmarsat.org (gw.inmarsat.org [161.30.211.130]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id DC4F9C6935 for ; Wed, 19 Jun 2002 09:18:45 -0400 (EDT) Received: from gw.inmarsat.com (unverified) by mimesweeper.inmarsat.org (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 19 Jun 2002 14:30:00 +0100 Received: from acca.inmarsat.com by nautilus.inmarsat.org (8.8.8/1.1.22.3/28Dec00-0957PM) id OAA0000021890; Wed, 19 Jun 2002 14:18:30 +0100 (BST) Received: by acca.inmarsat.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 14:18:02 +0100 Message-ID: <27880C387A864946AEB3A5BF4C6FB9BF0AE038@acca.inmarsat.com> From: Tom Mchugh To: tcpsat@grc.nasa.gov Cc: "Tristan Wood (E-mail)" , dshell@cisco.com, adrian.j.hooke@jpl.nasa.gov, "'brian.smith@honeywell.com'" Subject: RE: Satellites running IP: simulator Date: Wed, 19 Jun 2002 14:17:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Just in case it's useful to you folk: Inmarsat has had a network simulator developed for the 64kbit/s channel, and associated bearer services. The MINS (M4 ISDN Network Simulator) can be purchased from Livewire Digital Ltd ( http://www.livewire.co.uk/products/satell/satinm/mins/mins.htm ) Note its a transparent connection: your TCP is your own. tom tom_mchugh@inmarsat.com 99 city road london +44 (0)207 728 1761 -----Original Message----- From: brian.smith@honeywell.com [mailto:brian.smith@honeywell.com] Sent: Tuesday, June 18, 2002 21:30 To: adrian.j.hooke@jpl.nasa.gov; dshell@cisco.com Cc: tcpsat@grc.nasa.gov Subject: RE: Satellites running IP Adrian, Excuse me for jumping in on this but I want to mention that Honeywell, as well as others, are beginning to connect aircraft to ground networks using geosynchronous satellites and TCP. For example, we are using INMARSAT Swift64 (64Kbps) circuit connections for this purpose right now. We require than airborne laptops be able to use their normal stacks though so for now are using gateways to handle TCP issues. The potential market is far greater than space based hosts. Regards, Brian Smith Honeywell > -----Original Message----- > From: Adrian J. Hooke [SMTP:adrian.j.hooke@jpl.nasa.gov] > Sent: Tuesday, June 18, 2002 10:05 AM > To: Daniel Shell > Cc: tcpsat@grc.nasa.gov > Subject: Re: Satellites running IP > > At 08:25 AM 6/18/2002 -0400, Daniel Shell wrote: > >Is SCPS an IETF RFC on a standards track yet? > > Dan: > > Could you perhaps ask your question a bit more precisely? Which of the > four > SCPS protocols would you suggest should be launched on an IETF standards > track? > > If you are talking about the SCPS flavor of TCP (TCP Tranquility), in what > > context do you ask the question? TCP running between two ground end > systems > over a satellite link, or TCP running from a ground end system to an end > system onboard a satellite? > > If the latter, what would be the benefit to you of IETF standardization of > > TCP Tranquility? If it was on a standards track, would CISCO Systems Gobal > > [sic] Defense and Space Group then be interested in investing corporate > funds to build a bunch of COTS products to support space missions? > > Best regards > > Adrian J. Hooke > Manager, DOD-NASA Space Communications Protocol Standards (SCPS) Project > NASA Jet Propulsion Laboratory, > Interplanetary Network Directorate > M/S 303-400, 4800 Oak Grove Drive > Pasadena, California 91109-8099, USA > +1.818.354.3063 OFFICE > +1.818.653.9553 MOBILE > +1 818.354.6290 FAX > http://www.scps.org ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. In accordance with Inmarsat Information Security Policy and Guidelines on Computer use, emails sent or received may be monitored. Inmarsat Limited 99 City Road London EC1Y 1AX. Registered in England and Wales No. 3675885 ********************************************************************** From owner-tcpsat@grc.nasa.gov Wed Jun 19 09:54:55 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16661 for ; Wed, 19 Jun 2002 09:03:47 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 0E922C6A61 for ; Wed, 19 Jun 2002 09:02:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JCmlXq025801 for tcpsat-outgoing; Wed, 19 Jun 2002 08:48:47 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JCmkra025793 for ; Wed, 19 Jun 2002 08:48:46 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JCmjSl028713 for ; Wed, 19 Jun 2002 08:48:45 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1C9FBC6962 for ; Wed, 19 Jun 2002 08:48:44 -0400 (EDT) Received: from DSHELL-W2K.cisco.com (rtp-dial-1-73.cisco.com [10.83.97.73]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA11860; Wed, 19 Jun 2002 05:48:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20020619084709.04337838@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jun 2002 08:48:33 -0400 To: "Adrian J. Hooke" From: Daniel Shell Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: <5.1.0.14.2.20020618093400.0213e6a0@pop.jpl.nasa.gov> References: <4.3.2.7.2.20020618082508.0170da30@lint.cisco.com> <3D0A5B4A.485E0B9E@gst.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Adrian CISCO is not interested in SCPS at this time. NASA/JPL needs to approach the IETF to make it standard. So far that has not happened. At 01:04 PM 6/18/2002, Adrian J. Hooke wrote: >At 08:25 AM 6/18/2002 -0400, Daniel Shell wrote: >>Is SCPS an IETF RFC on a standards track yet? > >Dan: > >Could you perhaps ask your question a bit more precisely? Which of the >four SCPS protocols would you suggest should be launched on an IETF >standards track? > >If you are talking about the SCPS flavor of TCP (TCP Tranquility), in what >context do you ask the question? TCP running between two ground end >systems over a satellite link, or TCP running from a ground end system to >an end system onboard a satellite? > >If the latter, what would be the benefit to you of IETF standardization of >TCP Tranquility? If it was on a standards track, would CISCO Systems Gobal >[sic] Defense and Space Group then be interested in investing corporate >funds to build a bunch of COTS products to support space missions? > >Best regards > >Adrian J. Hooke >Manager, DOD-NASA Space Communications Protocol Standards (SCPS) Project >NASA Jet Propulsion Laboratory, >Interplanetary Network Directorate >M/S 303-400, 4800 Oak Grove Drive >Pasadena, California 91109-8099, USA >+1.818.354.3063 OFFICE >+1.818.653.9553 MOBILE >+1 818.354.6290 FAX >http://www.scps.org > Dan Shell Network Architect CISCO Systems Gobal Defense and Space Group Wireless/Mobile Networking/ Satellite 216 643 2422 From owner-tcpsat@grc.nasa.gov Wed Jun 19 10:24:36 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20285 for ; Wed, 19 Jun 2002 10:24:36 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 80E98C6AA9 for ; Wed, 19 Jun 2002 10:24:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JECko4021596 for tcpsat-outgoing; Wed, 19 Jun 2002 10:12:46 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JECira021588 for ; Wed, 19 Jun 2002 10:12:44 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JECiSl014653 for ; Wed, 19 Jun 2002 10:12:44 -0400 (EDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 5D02DC694B for ; Wed, 19 Jun 2002 10:12:43 -0400 (EDT) Received: (qmail 17992 invoked from network); 19 Jun 2002 14:12:42 -0000 Received: from unknown (HELO gst.com) ([66.92.165.221]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Jun 2002 14:12:42 -0000 Message-ID: <3D109159.8030304@gst.com> Date: Wed, 19 Jun 2002 10:12:41 -0400 From: Eric Travis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 MIME-Version: 1.0 To: Daniel Shell Cc: tcpsat@grc.nasa.gov Subject: Re: Satellites running IP References: <4.3.2.7.2.20020618082508.0170da30@lint.cisco.com> <4.3.2.7.2.20020619084548.01712508@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan, I need to better understand your question... An onboard stack using (any flavor of) TCP and IP (version 4 or 6) is part of the SCPS recommendations. CISCO manufactures equipment that could be labeled "SCPS Compliant" if there were such a classification. Based on this, the answer to your question is: Yes If only there were a market for onboard networking equipment, CISCO marketing folks could add that to the marketing brochures :o) Now, when one asks a rhetorical question, there is generally a reason - I honestly want to understand your motivation was for asking a question (in this forum) where you know the answer. Please understand that missions will adopt whatever satisifies their goals (which are not limited to reducing risk from unfamiliar code-bases, increasing efficiency and maximizing the amount of science they can get down per unit of time and radiated power); These requirements may not mesh with the goals of the larger IETF, and hence may not justify attempting to standardize differentiated behaviors for use in the Internet (where they probably will never be used); When you have sufficent time, *please* reread my responses and then let's take this off list. It is not apparent to me that the discussion that you want to have is really relevant to the to the rest of the list... Enjoy the remainder of your vacation. Eric Daniel Shell wrote: > Eric > > So the answer is no. > > Sorry for the short reply but I am on vacation will get you a more > detailed > answer later > From owner-tcpsat@grc.nasa.gov Wed Jun 19 12:28:51 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25676 for ; Wed, 19 Jun 2002 12:28:51 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C9617C6935 for ; Wed, 19 Jun 2002 12:29:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JGF5cQ025178 for tcpsat-outgoing; Wed, 19 Jun 2002 12:15:05 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JGF3ra025169 for ; Wed, 19 Jun 2002 12:15:03 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JGF3Sl007449 for ; Wed, 19 Jun 2002 12:15:03 -0400 (EDT) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 3CD2BC698A for ; Wed, 19 Jun 2002 12:15:01 -0400 (EDT) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw2a.lmco.com (8.11.6/8.11.6) with ESMTP id g5JGEvd02529 for ; Wed, 19 Jun 2002 12:14:57 -0400 (EDT) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-33 #38886) id <0GXY00601NSUN3@lmco.com> for tcpsat@grc.nasa.gov; Wed, 19 Jun 2002 09:14:56 -0700 (PDT) Received: from emss01i00.ems.lmco.com ([129.197.181.70]) by lmco.com (PMDF V5.2-33 #38886) with ESMTP id <0GXY00PRHNSQ1W@lmco.com> for tcpsat@grc.nasa.gov; Wed, 19 Jun 2002 09:14:50 -0700 (PDT) Received: by emss01i00.ems.lmco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 09:14:49 -0700 Content-return: allowed Date: Wed, 19 Jun 2002 09:14:47 -0700 From: "Smith JR, Harry E" Subject: Satellites running IP To: tcpsat@grc.nasa.gov Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT I have been following the thread with interest and enjoyment. However, as a newcomer to the SCPS, is there a technical summary of the differences and extension of the SCPS Suite to the most common stack ( not best) Winsock 2.0 ? Or even any commonly used stack? Thanks Harry Smith ---------------------------------------------------------------------------- --------- Harry Smith l Systems Engineer Senior Staff LM MDS/WR 280/4/26 3200 Zanker Road, MS X-75, San Jose, CA. 95134 408 473 6491 From owner-tcpsat@grc.nasa.gov Wed Jun 19 12:35:29 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25933 for ; Wed, 19 Jun 2002 12:35:29 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 7BFF864253 for ; Wed, 19 Jun 2002 12:35:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JGNSwT027932 for tcpsat-outgoing; Wed, 19 Jun 2002 12:23:28 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JGNRra027917 for ; Wed, 19 Jun 2002 12:23:27 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JGNQSl009003 for ; Wed, 19 Jun 2002 12:23:26 -0400 (EDT) Received: from hwembaz0002.honeywell.com (hwembaz0002.honeywell.com [129.239.31.107]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 69258640DE for ; Wed, 19 Jun 2002 12:23:24 -0400 (EDT) Received: by hwembaz0002.cas.honeywell.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 09:14:21 -0700 Message-ID: <174E624A2F17C64197CCE6AE6BD0094B071869AC@dvtex221.CAS.HONEYWELL.COM> From: brian.smith@honeywell.com To: adrian.j.hooke@jpl.nasa.gov, brian.smith@honeywell.com Cc: tcpsat@grc.nasa.gov, l.freudinger@dfrc.nasa.gov Subject: RE: Satellites running IP Date: Wed, 19 Jun 2002 09:14:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Adrian, The niche for these gateways is so small that I don't see a driving need for a standard. However, better yet would be if there was a way for all common stacks (read Windows, etc.) to "detect" a long latency link and tune themselves appropriately, so gateways were not required. Again, there probably won't be enough of a user base to warrant this. Regards, Brian > -----Original Message----- > From: Adrian J. Hooke [SMTP:adrian.j.hooke@jpl.nasa.gov] > Sent: Tuesday, June 18, 2002 3:41 PM > To: brian.smith@honeywell.com > Cc: tcpsat@grc.nasa.gov; l.freudinger@dfrc.nasa.gov > Subject: RE: Satellites running IP > > At 01:29 PM 6/18/2002 -0700, brian.smith@honeywell.com wrote: > >For example, we are using INMARSAT > >Swift64 (64Kbps) circuit connections for this purpose right now. We > require > >than airborne laptops be able to use their normal stacks though so for > now > >are using gateways to handle TCP issues. > > Brian: > > Yes, we're aware of these neat aircraft applications via our close work > with Larry Freudinger at NASA Dryden Flight Research Center, and in > particular with the use of intermediate PEP gateways. The question is > whether (in order to use the gateway capabilities) you feel that their > various internal flavors of TCP need to be put on an *IETF* standards > track. Dan Shell apparently feels that they do; what about you? TCP > Tranquility is a full International Standard within the space community; > do > you feel in any way inhibited from experimenting with its use? > > Adrian Hooke From owner-tcpsat@grc.nasa.gov Wed Jun 19 13:42:55 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28687 for ; Wed, 19 Jun 2002 13:42:54 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 5FBE764253 for ; Wed, 19 Jun 2002 13:42:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JHT1Zh016852 for tcpsat-outgoing; Wed, 19 Jun 2002 13:29:01 -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 GRC 8.12.3/8.12.3) with ESMTP id g5JHT0ra016836; Wed, 19 Jun 2002 13:29:00 -0400 (EDT) Received: from katrinajoy (tb2-78.lerc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id NAA00046; Wed, 19 Jun 2002 13:28:59 -0400 (EDT) Message-Id: <4.2.1.20020619132429.00be9da0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 19 Jun 2002 13:29:00 -0400 To: brian.smith@honeywell.com From: William Ivancic Subject: RE: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: <174E624A2F17C64197CCE6AE6BD0094B071869AC@dvtex221.CAS.HONE YWELL.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk At 09:14 AM 6/19/02 -0700, brian.smith@Honeywell.com wrote: >Adrian, >The niche for these gateways is so small that I don't see a driving need for >a standard. However, better yet would be if there was a way for all common >stacks (read Windows, etc.) to "detect" a long latency link and tune >themselves appropriately, so gateways were not required. There is lots of research being done in this area, but nothing is yet proven and tested in the sufficiently open networks to then take these to standards. Most are still very much research. I expect this will come in the future - maybe 3 to 5 years. However, it is not here today. Will From owner-tcpsat@grc.nasa.gov Wed Jun 19 14:49:06 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00665 for ; Wed, 19 Jun 2002 14:49:06 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B1E2DC6A9C for ; Wed, 19 Jun 2002 14:49:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JIaXlL008628 for tcpsat-outgoing; Wed, 19 Jun 2002 14:36:33 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JIaWra008623 for ; Wed, 19 Jun 2002 14:36:32 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JIaVSl003940 for ; Wed, 19 Jun 2002 14:36:31 -0400 (EDT) Received: from mail5.uunet.ca (mail5.uunet.ca [142.77.1.28]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id AFF3D64128 for ; Wed, 19 Jun 2002 14:36:30 -0400 (EDT) Received: from bugsbunny ([216.95.199.148]) by mail5.uunet.ca with SMTP id <587613-10662>; Wed, 19 Jun 2002 14:32:34 -0400 From: "Charlie Younghusband" To: "Smith JR, Harry E" , Subject: RE: Satellites running IP Date: Wed, 19 Jun 2002 14:36:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit You and many others on this list following this thread may be interested in a technical paper "Performance of SCPS-TP in Complex Networks" presented last month at an AIAA conference. It can be found at: http://www.xiphos.ca/files/papers/The_Performance_of_SCPS_in_Complex_Network s.pdf Charlie -- Charlie Younghusband Network Software Engineering Xiphos Technologies 514-848-9640 http://www.xiphos.ca/ -----Original Message----- From: owner-tcpsat@grc.nasa.gov [mailto:owner-tcpsat@grc.nasa.gov]On Behalf Of Smith JR, Harry E Sent: June 19, 2002 12:15 PM To: tcpsat@grc.nasa.gov Subject: Satellites running IP I have been following the thread with interest and enjoyment. However, as a newcomer to the SCPS, is there a technical summary of the differences and extension of the SCPS Suite to the most common stack ( not best) Winsock 2.0 ? Or even any commonly used stack? Thanks Harry Smith ---------------------------------------------------------------------------- --------- Harry Smith l Systems Engineer Senior Staff LM MDS/WR 280/4/26 3200 Zanker Road, MS X-75, San Jose, CA. 95134 408 473 6491 From owner-tcpsat@grc.nasa.gov Wed Jun 19 15:53:14 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02157 for ; Wed, 19 Jun 2002 15:53:14 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 806C364127 for ; Wed, 19 Jun 2002 15:53:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JJdtLD026692 for tcpsat-outgoing; Wed, 19 Jun 2002 15:39:55 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JJdrra026683 for ; Wed, 19 Jun 2002 15:39:53 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JJdpSl015988 for ; Wed, 19 Jun 2002 15:39:52 -0400 (EDT) Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [192.80.55.70]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 5E48BC69C5 for ; Wed, 19 Jun 2002 15:39:51 -0400 (EDT) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g5JJdnl15244; Wed, 19 Jun 2002 15:39:49 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g5JJdlO23908; Wed, 19 Jun 2002 15:39:47 -0400 (EDT) Received: from mailhubf.mitre.org (129.83.25.49) by mailhub2.mitre.org with SMTP id 10594495; Wed, 19 Jun 2002 15:39:39 -0400 Received: from m26959-pc.mitre.org (128.29.105.162) by mailhubf.mitre.org with SMTP id 546017; Wed, 19 Jun 2002 15:39:35 -0400 Message-Id: <5.1.0.14.2.20020619144520.00ae5d08@mailsrv2.mitre.org> X-Sender: kscott@mailsrv2.mitre.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 19 Jun 2002 15:39:33 -0400 To: harry.e.smith.jr@lmco.com (Smith JR, Harry E) From: kscott@mitre.org (Keith Scott) Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Harry, The specifications for the SCPS suite of protocols (including transport, network, and security layers) can be found at: http://www.ccsds.org/documents/pdf/CCSDS-714.0-B-1.pdf http://www.ccsds.org/documents/pdf/CCSDS-713.0-B-1.pdf http://www.ccsds.org/documents/pdf/CCSDS-713.5-B-1.pdf http://www.ccsds.org/documents/pdf/CCSDS-717.0-B-1.pdf The SCPS Transport protocol (also known as TCP Tranquility) that has received much attention here of late specifies a set of sender-side modifications and some TCP options that can be used to shift TCP's operating domain. That is, any TCP implementation such as TCP Reno (or TCP SACK, ...) has an 'operating regime' where it performs well. Not surprisingly, the operating regime of commonly deployed TCP stacks covers most wired situations, and in a pinch can be stretched across wireless links. TCP Tranquility specifies a set of options that can be used to shift (or extend) TCP's operating domain to perform better in certain stressed conditions, including: o Long delays (e.g. geosynchronous satellite communications) o Large data rate asymmetries (e.g. communications with some satellites) o High bit error rates (e.g. some terrestrial wireless and some space communciations) o Link outages (e.g. some terrestrial wireless and some space communications) Additional information about the SCPS protocols, including the results of some flight tests, can be found at http://www.scps.org There's also a point of contact there where you can request a free copy of the TCP Tranquility Reference Implemenation (RI) (full source code). The RI runs on most unix-like operating systems, including solaris, linux, freebsd, ... To get this level of portability, the RI runs in user-space, and applications have to explicitly link in the Tranquility stack (and make appropriate calls). Tranquility versions of FTP and ttcp, useful for network testing, come with the RI. The RI can also be configured as a Transparent TCP gateway (similar in functionality to some commercial products). In the gateway configuration, Tranquility can implement different congestion control mechanisms on the two sides of the gateway so that it can, for instance, run VJ congestion control with a modest (say 32k) windows on one side (to communicate with terrestrial users) and run with congestion control disabled (i.e. limited only by the rate control setting, discussed below) to communicate with a peer gateway across, say, a satellite hop. The short answer to your question: what are the differences between TCP Tranquility and, say, TCP NewReno is that Tranquility provides for a number of sender-side modifications to TCP behavior, and a number of negotiated options. The sender-side modifications include: 1 TCP Tranquility provides for the sender-side to use either VJ- or Vegas-style congestion control, or none. Obviously, disabling congestion control is something that should only be done when the Tranquility flow won't interfere with congestion-controlled flows. There are also paced acknowledgement modes useful for very highly asymmetric situations. 2 TCP Tranquility includes a sender-side rate control cap on transmission rate (this can be useful, for example, to prevent the VJ congestion control algorithm from repeatedly driving the bottleneck link into congestion). In addition, TCP Tranquility specifies a number of TCP options, including: 1 SCPS-Capabilities TCP Option Used during the SYN exchange to negotiate various TCP Tranquility capabilities such as SNACK, SCPS Loss-Tolerant Header Compression, Partial Reliability Service, ...) If a Tranquility endpoint is communicating with a non-Tranquility endpoint (or another Tranquility stack, for that matter) that does not agree to use SCPS options, either by not including a SCPS capabilities option in the SYN exchange or by including a SCPS-capabilities option that declines all extensions, communications take place using the standard TCP protocol as specified by RFC 793 and its supporting RFCs. 2 Selective Negative Acknowledgements TCP Option SNACK is a bandwidth-efficient form of NACK useful in moderate to high error rate environments. 3 Record Boundary Marking TCP Tranquility specifies a method for marking record boundaries in the TCP stream. These record boundaries are indicated at the source and are carried through to the destination. 4 Corruption Experienced TCP Option TCP Tranquility specifies a way to inform a TCP sender that a link in the path has gone down. This allows the sender to suspend various timers until the link comes back up. This essentially keeps the sender from backing off a lot while waiting for the link to come up. TCP Tranquility Loss-Tolerant Header Compression TCP Tranquility specifies a loss-tolerant header compression scheme that does not use delta encoding, as RFC1144 compression does[1]. The loss-tolerant header compression generally doesn't achieve the compression ratios of VJ header compression, but a single corrupted packet does not prevent decompression of later packets at the receiver. If both ends of the connection agree to do Tranqility header compression during the SYN exchange, then the remainder of the connection switches to the TCP Tranquility IP protocol number (105). TCP Tranquility Partial Reliability Service During the initial SYN exchange, both endpoints may agree to use partial reliability. This mode of operation allows the sender to 'give up' on retransmitting data after a specified timeout period. The receiver then receives a stream with holes in it. Application-layer support to correctly detect and deal with holes in the received stream is required. If you have any other questions, I'd be happy to answer, --keith [1] VJ Header compression (RFC1144) uses delta-encoding, essentially transmitting the changes to some fields in the TCP/IP headers instead of the whole values. This can be unfriendly to lossy links because there's shared state at the link endpoints that, when a packet is corrupted on the link, becomes inconsistent. This can cause data to fall on the floor until the source retransmits the lost packet. Things like the twice algorithm and the header compression for IPv6 try to get around this problem. At 09:14 AM 6/19/2002 -0700, Smith JR, Harry E wrote: >I have been following the thread with interest and enjoyment. > >However, as a newcomer to the SCPS, is there a technical summary of the >differences and extension of the SCPS Suite to the most common stack ( not >best) Winsock 2.0 ? Or even any commonly used stack? > >Thanks >Harry Smith > >---------------------------------------------------------------------------- >Harry Smith >l >Systems Engineer Senior Staff >LM MDS/WR 280/4/26 > >3200 Zanker Road, MS X-75, San Jose, CA. 95134 >408 473 6491 From owner-tcpsat@grc.nasa.gov Wed Jun 19 15:58:05 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02316 for ; Wed, 19 Jun 2002 15:58:05 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 41EAB6416E for ; Wed, 19 Jun 2002 15:58:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JJlKxA028389 for tcpsat-outgoing; Wed, 19 Jun 2002 15:47:20 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JJlJra028377 for ; Wed, 19 Jun 2002 15:47:19 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JJlISl016952 for ; Wed, 19 Jun 2002 15:47:18 -0400 (EDT) Received: from telefonica (16.Red-80-33-132.pooles.rima-tde.net [80.33.132.16]) by seraph3.grc.nasa.gov (Postfix) with SMTP id 70468640B9 for ; Wed, 19 Jun 2002 15:47:17 -0400 (EDT) From: "ANALISIS DEL SECTOR INMOBILIARIO" To: Subject: Información de interés Público Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Jun 2002 21:47:12 Message-Id: <20020619194717.70468640B9@seraph3.grc.nasa.gov> Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk ANALISIS DEL SECTOR INMOBILIARIO Desde hace unos años el sector inmobiliario ha sufrido un fuerte crecimiento Primero, por el aumento de la demanda debido a la baja del tipo de interés en las hipotecas. Segundo, a la necesidad de aflorar el dinero negro tras la conversión al EURO. Tercero, a la falta de expectativas en la bolsa. Haciendo que parte del capital dirigido a este Mercado fuese reconducido al sector inmobiliario por los que buscan la fácil especulación. El mercado inmobiliario en España, esta sobre valorado en un 45%.Según estudios internacionales. Por estos motivos y otros llegamos a la actualidad con un parón en las ventas sin precedentes en menos de un año se estima que las ventas caerán un 40%. (Son datos que guardan los GRANDES del sector, incluso tienen estrategias internas, como es filtrar e incluso comprar la información que sale en prensa, alterándola con datos contrarios. Para salvaguardar sus intereses. Hay varios sectores implicados en la especulación, el financiero, las grandes corporaciones inmobiliarias y el propio estado, por los beneficios indirectos que les reporta. El sector ha ido en sentido contrario a su naturaleza, ya que hoy en dia por el avance tecnológico y por la subida de salarios moderada, tendría que estar en otro nivel. Al final pasará la tormenta, el sector se ajustará quedarán los verdaderos profesionales y habrá una demanda en armonía con el mercado. From owner-tcpsat@grc.nasa.gov Wed Jun 19 17:28:09 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04090 for ; Wed, 19 Jun 2002 17:28:09 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id BCEA36415D for ; Wed, 19 Jun 2002 17:28:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5JLG1Gr021522 for tcpsat-outgoing; Wed, 19 Jun 2002 17:16:01 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JLG0ra021518 for ; Wed, 19 Jun 2002 17:16:00 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5JLFxSl003417 for ; Wed, 19 Jun 2002 17:15:59 -0400 (EDT) Received: from gst.gst.com (gst.gst.com [208.219.159.150]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 2DF5AC68F7 for ; Wed, 19 Jun 2002 17:15:59 -0400 (EDT) Received: from gst.com (travis@mako.gst.com [208.219.159.163] (may be forged)) by gst.gst.com (8.11.6/8.11.6) with ESMTP id g5JL7uu18473; Wed, 19 Jun 2002 17:07:57 -0400 Message-ID: <3D10F480.2417896F@gst.com> Date: Wed, 19 Jun 2002 17:15:44 -0400 From: Eric Travis X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: dshell@cisco.com Cc: adrian.hooke@jpl.nasa.gov, tcpsat@grc.nasa.gov Subject: The (perceived) requirement to be an IETF Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan, I read your response to Adrian (below) and I'm still struggling... but I'm trying to learn. While you've been a bit cryptic (possibly because you are on vacation) I now think that a discussion of the perceived requirement for IETF standardization of things for niche communities is an appropriate discussion for this list. While I don't imagine there is *any* viable business case for CISCO to divert energy or resources to supporting any space-based protocols/hardware in their mainstream product line, should I interpret your response to Adrian to indicate: CISCO *only* implements protocols that are IETF standards? CISCO will find a business case to support space-based protocols if they are IETF standards? Does your work at GRC lead you to believe that there is a large market for space-based networking? Large enough to sustain a working community of interest within the IETF? The point of the parent thread is TCP - does CISCO make many end-user devices that would be relevant to this discussion? Are you planning on building middle-boxes - in which case the dynamics of the discussion changes a lot and the need for IETF standardization of the behavior what goes over the *private* links and is terminated prior to the public network becomes even less obvious... For this environment, I'd imagine that any business decisions would *not* be based on whether a frob is an IETF Standard, but rather there is a sufficiently large market to recover development and support costs while eventually turning a profit. You keep asserting that: "NASA/JPL needs to approach the IETF to make it standard" (there is no 'it' appropriate here, a 'them' perhaps) My sincere question to you is: Why? I'm not the sharpest crayon in the box, so could you please explain to me what exactly will be gained by the communities of interest by going through the justifiably rigorous and lengthy process of making *these* protocol enhancements IETF standards? They are already standards (several times over)... Also, why might the IETF care to bother standardizing what is running on mostly closed/private networks? If you can make a good case, then perhaps *we* can convince NASA to divert some research funds to support that effort. The money is there, but it would need to be reprogrammed to support the effort. I'm reluctantly up for the challenge, but I need your help making a convincing case to the folks that matter at NASA HQ. The topic will keep until you return to work, but if you can convince me that it is necessary, I'd like to pursue this within NASA if at all possible. Eric > Adrian > > CISCO is not interested in SCPS at this time. > NASA/JPL needs to approach the IETF to make it standard. > So far that has not happened. > > At 01:04 PM 6/18/2002, Adrian J. Hooke wrote: > >At 08:25 AM 6/18/2002 -0400, Daniel Shell wrote: > >>Is SCPS an IETF RFC on a standards track yet? > > > >Dan: > > > >Could you perhaps ask your question a bit more precisely? Which of the > >four SCPS protocols would you suggest should be launched on an IETF > >standards track? > > > >If you are talking about the SCPS flavor of TCP (TCP Tranquility), in what > >context do you ask the question? TCP running between two ground end > >systems over a satellite link, or TCP running from a ground end system to > >an end system onboard a satellite? > > > >If the latter, what would be the benefit to you of IETF standardization of > >TCP Tranquility? If it was on a standards track, would CISCO Systems Gobal > >[sic] Defense and Space Group then be interested in investing corporate > >funds to build a bunch of COTS products to support space missions? > > > >Best regards > > > >Adrian J. Hooke > >Manager, DOD-NASA Space Communications Protocol Standards (SCPS) Project > >NASA Jet Propulsion Laboratory, > >Interplanetary Network Directorate > >M/S 303-400, 4800 Oak Grove Drive > >Pasadena, California 91109-8099, USA > >+1.818.354.3063 OFFICE > >+1.818.653.9553 MOBILE > >+1 818.354.6290 FAX > >http://www.scps.org > > > > Dan Shell > Network Architect > CISCO Systems > Gobal Defense and Space Group > Wireless/Mobile Networking/ Satellite > 216 643 2422 From owner-tcpsat@grc.nasa.gov Thu Jun 20 15:02:55 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10688 for ; Thu, 20 Jun 2002 15:02:55 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7EB62C694A for ; Thu, 20 Jun 2002 15:03:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5KBulTP001351 for tcpsat-outgoing; Thu, 20 Jun 2002 07:56:47 -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 GRC 8.12.3/8.12.3) with ESMTP id g5KBukra001347; Thu, 20 Jun 2002 07:56:46 -0400 (EDT) Received: from katrinajoy (vtcp2-22.lerc.nasa.gov [139.88.246.22]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id HAA04441; Thu, 20 Jun 2002 07:56:43 -0400 (EDT) Message-Id: <4.2.1.20020620075223.00bf0100@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Thu, 20 Jun 2002 07:56:49 -0400 To: kscott@mitre.org (Keith Scott), harry.e.smith.jr@lmco.com (Smith JR, Harry E) From: William Ivancic Subject: Re: Satellites running IP Cc: tcpsat@grc.nasa.gov In-Reply-To: <5.1.0.14.2.20020619144520.00ae5d08@mailsrv2.mitre.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Keith, Thanks for the summary. It may be useful to put this summary (the stuff below) on the SCPS site as it is probably a question that comes up often. Reading this summary is much easier that examining the documents. Will >The short answer to your question: what are the differences between TCP >Tranquility and, say, TCP NewReno is that Tranquility provides for a >number of sender-side modifications to TCP behavior, and a number of >negotiated options. The sender-side modifications include: > >1 TCP Tranquility provides for the sender-side to use either VJ- or >Vegas-style congestion control, or none. Obviously, disabling congestion >control is something that should only be done when the Tranquility flow >won't interfere with congestion-controlled flows. There are also paced >acknowledgement modes useful for very highly asymmetric situations. >2 TCP Tranquility includes a sender-side rate control cap on transmission >rate (this can be useful, for example, to prevent the VJ congestion >control algorithm from repeatedly driving the bottleneck link into congestion). > >In addition, TCP Tranquility specifies a number of TCP options, including: > >1 SCPS-Capabilities TCP Option >Used during the SYN exchange to negotiate various TCP Tranquility >capabilities such as SNACK, SCPS Loss-Tolerant Header Compression, Partial >Reliability Service, ...) If a Tranquility endpoint is communicating >with a non-Tranquility endpoint (or another Tranquility stack, for that >matter) that does not agree to use SCPS options, either by not including a >SCPS capabilities option in the SYN exchange or by including a >SCPS-capabilities option that declines all extensions, communications take >place using the standard TCP protocol as specified by RFC 793 and its >supporting RFCs. > >2 Selective Negative Acknowledgements TCP Option >SNACK is a bandwidth-efficient form of NACK useful in moderate to high >error rate environments. > >3 Record Boundary Marking >TCP Tranquility specifies a method for marking record boundaries in the >TCP stream. These record boundaries are indicated at the source and are >carried through to the destination. > >4 Corruption Experienced TCP Option >TCP Tranquility specifies a way to inform a TCP sender that a link in the >path has gone down. This allows the sender to suspend various timers >until the link comes back up. This essentially keeps the sender from >backing off a lot while waiting for the link to come up. > >TCP Tranquility Loss-Tolerant Header Compression >TCP Tranquility specifies a loss-tolerant header compression scheme that >does not use delta encoding, as RFC1144 compression does[1]. The >loss-tolerant header compression generally doesn't achieve the compression >ratios of VJ header compression, but a single corrupted packet does not >prevent decompression of later packets at the receiver. If both ends of >the connection agree to do Tranqility header compression during the SYN >exchange, then the remainder of the connection switches to the TCP >Tranquility IP protocol number (105). > >TCP Tranquility Partial Reliability Service >During the initial SYN exchange, both endpoints may agree to use partial >reliability. This mode of operation allows the sender to 'give up' on >retransmitting data after a specified timeout period. The receiver then >receives a stream with holes in it. Application-layer support to >correctly detect and deal with holes in the received stream is required. > > >If you have any other questions, I'd be happy to answer, > > --keith > > >[1] VJ Header compression (RFC1144) uses delta-encoding, essentially >transmitting the changes to some fields in the TCP/IP headers instead of >the whole values. This can be unfriendly to lossy links because there's >shared state at the link endpoints that, when a packet is corrupted on the >link, becomes inconsistent. This can cause data to fall on the floor >until the source retransmits the lost packet. Things like the twice >algorithm and the header compression for IPv6 try to get around this problem. > ======================================= 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 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic From owner-tcpsat@grc.nasa.gov Thu Jun 20 21:52:03 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18314 for ; Thu, 20 Jun 2002 21:52:03 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 59760C6A2D for ; Thu, 20 Jun 2002 21:52:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5L1TLDb002503 for tcpsat-outgoing; Thu, 20 Jun 2002 21:29:21 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5L1TKra002497 for ; Thu, 20 Jun 2002 21:29:20 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5L1TJSl005186 for ; Thu, 20 Jun 2002 21:29:19 -0400 (EDT) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 2B1F664131 for ; Thu, 20 Jun 2002 21:29:19 -0400 (EDT) Received: (qmail 20230 invoked from network); 21 Jun 2002 01:29:17 -0000 Received: from unknown (HELO gst.com) ([66.92.165.221]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Jun 2002 01:29:17 -0000 Message-ID: <3D128167.3060905@gst.com> Date: Thu, 20 Jun 2002 21:29:11 -0400 From: Eric Travis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 MIME-Version: 1.0 To: wivancic@grc.nasa.gov Cc: tcpsat@grc.nasa.gov Subject: SCPS-TP, TCP and Rate-Based Protocol Evaluation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Will: Last week you provided a link for your results of your high-speed SCPS and rate-based protocol testing which you will be presenting at SpaceOps 2002: "SCPS-TP, TCP and Rate-Based Protocol Evaluation" I've spent the past few evenings going over the briefing material and there appear to be several troublesome aspects of the data curves which could lead to a suspicion that some of the measured data may be flawed. Summaries are provided in [footnote 1]. In there even that there is any merit to them, there should be ample time to fix any problems prior to SpaceOps.. In spite of these possible discrepancies, an impartial examination of the provided performance curves could in fact lead to a surprisingly upbeat assessment of the performance of all the protocols. Conclusions can be drawn that would be in stark contrast to those provided in slide 20 of the presentation - which is transcribed for reference in [footnote 2]. I am offering the following set of alternative conclusions and invite interested parties on this mailing list to independently analyze the results and comment back. Eric The *complete* text including the footnotes has been placed at: http://www.ipnrg.org/travis/Peer_Review/GRC_SpaceOps2002.txt ======================================================= An alternative set of conclusions drawn from the data presented at: http://roland.grc.nasa.gov/~ivancic/papers_presentations/SpaceOps2002_TCP_SCPS.ppt 1 Depending on the mode of operation, even very small transactions such as spacecraft command and control traffic *may* indeed see a benefit from using a rate-based protocol 2 Rate-based protocols are advisable for *any* environment where bandwidth reservation is practical and available. 3 The performance problems experienced with the rate-based protocols was most likely due to accidental misconfiguration of the protocols, causing them to congest the network. 4 With proper configuration, all the rate-based protocols could have performed better in the errored environments. - An increase in error frequency has the same effect as increasing the rtt, and hence changes the bandwidth/ delay product - The measured curves illustrate the effects of window limiting rather than the expected error performance curve decay - The buffer sizes used on the rate-based TCPs and MDP should have been re-tuned to reflect the effective bandwidth-delay product 5 The single stream and multi-stream test results clearly illustrate that the SCPS enhancements to TCP provide measurable performance improvements over the TCP SACK implementation tested. - The value of these performance increases is subjective and would need to be judged on a mission by mission basis 6 Even with equal performance, the deployment of a rate-based TCP is more desirable than the deployment of MDP or other non-TCP protocols when unicast data delivery is the goal. - The rate-based TCP is a sending-side only modification - All "standard" TCP applications can be deployed without modification 7 While the space community should be aware of current and future TCP research, the existing standard protocols and capabilities (drawn from a variety of communities) appear to satisfy all known mission needs. From owner-tcpsat@grc.nasa.gov Fri Jun 21 11:14:07 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16423 for ; Fri, 21 Jun 2002 11:14:06 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id EBBAC641B4 for ; Fri, 21 Jun 2002 11:14:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5LEtLfG019521 for tcpsat-outgoing; Fri, 21 Jun 2002 10:55:21 -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 GRC 8.12.3/8.12.3) with ESMTP id g5LEtJra019504; Fri, 21 Jun 2002 10:55:19 -0400 (EDT) Received: from katrinajoy (vtcp2-20.lerc.nasa.gov [139.88.246.20]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id KAA27081; Fri, 21 Jun 2002 10:55:17 -0400 (EDT) Message-Id: <4.2.1.20020621102948.00bf5e90@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Fri, 21 Jun 2002 10:55:29 -0400 To: Eric Travis From: William Ivancic Subject: Re: SCPS-TP, TCP and Rate-Based Protocol Evaluation Cc: tcpsat@grc.nasa.gov In-Reply-To: <3D128167.3060905@gst.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk At 09:29 PM 6/20/02 -0400, Eric Travis wrote: >Will: > >I am offering the following set of alternative conclusions and invite >interested parties on this mailing list to independently analyze the >results and comment back. > >Eric > Thanks for the input. I will definitely incorporate much of this. See below for a few comments. >An alternative set of conclusions drawn from the data presented at: > >http://roland.grc.nasa.gov/~ivancic/papers_presentations/SpaceOps2002_TCP_S >CPS.ppt > >1 Depending on the mode of operation, even very small > transactions such as spacecraft command and control > traffic *may* indeed see a benefit from using a > rate-based protocol Will Include >2 Rate-based protocols are advisable for *any* environment where >bandwidth reservation is practical and available. Will include with as: Rate-based protocols may be applicable for *any* environment where bandwidth reservation is practical and available >3 The performance problems experienced with the rate-based > protocols was most likely due to accidental misconfiguration > of the protocols, causing them to congest the network. I wish this were the case, but we configured and tuned these to the best of our capabilities and consulted with the developers (Mitre, NRL, etc...). The problem appears to be (at least for MDP) that the receiving system choked. It can not process fast enough due to the algorithm and implementation of the protocol. > >4 With proper configuration, all the rate-based protocols > could have performed better in the errored environments. > > - An increase in error frequency has the same effect as > increasing the rtt, and hence changes the bandwidth/ > delay product > > - The measured curves illustrate the effects of window > limiting rather than the expected error performance > curve decay > > - The buffer sizes used on the rate-based TCPs and MDP > should have been re-tuned to reflect the effective > bandwidth-delay product Same comment as for item 4. We tuned these for best performance at Zero BER. It is impractical to expect one to constantly, manually tune a protocol for a given time-varying unknown link condition. We believe our tuning was valid for today's protocols. That being said, I believe work needs to be done for autotuning as I believe it is impractical and unreasonable to expect the general users of systems to possess the knowledge to tune each protocol for a particular environment. Obviously a research area with lots of work being done here. >5 The single stream and multi-stream test results clearly > illustrate that the SCPS enhancements to TCP provide > measurable performance improvements over the TCP SACK > implementation tested. > > - The value of these performance increases is > subjective and would need to be judged on a > mission by mission basis Will includes something along these lines. >6 Even with equal performance, the deployment of a > rate-based TCP is more desirable than the deployment > of MDP or other non-TCP protocols when unicast data > delivery is the goal. > > - The rate-based TCP is a sending-side only modification > - All "standard" TCP applications can be deployed > without modification Well, I don't consider a pure rate-base, not congestion control protocol TCP for reasons I previously stated - even though the protocol header is the same as TCP. However, an in-kernel reliable rate-based protocol may be more desirable for unicast data than an application level rate-based protocol. There is definitely room for debate here. This is a philosophical debate. I see merit on both sides and I don't really care to carry on such a debate here. IMHO, neither answer is right or wrong and both are right and wrong depending on the situation. I'll consider this, but I definitely cannot accept it as worded. >7 While the space community should be aware of current and > future TCP research, the existing standard protocols and > capabilities (drawn from a variety of communities) appear > to satisfy all known mission needs. > Nice touch, I'll add this. ======================================= 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 Yahoo Instant Messenger ID: ivancic http://roland.grc.nasa.gov/~ivancic From owner-tcpsat@grc.nasa.gov Fri Jun 21 18:03:23 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02639 for ; Fri, 21 Jun 2002 18:03:23 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id CFA76C6940 for ; Fri, 21 Jun 2002 18:03:32 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5LLl4m1016184 for tcpsat-outgoing; Fri, 21 Jun 2002 17:47:04 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5LLl2ra016180; Fri, 21 Jun 2002 17:47:02 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5LLl1Sl028250; Fri, 21 Jun 2002 17:47:01 -0400 (EDT) Received: from gst.gst.com (gst.gst.com [208.219.159.150]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 3ED5364182; Fri, 21 Jun 2002 17:47:01 -0400 (EDT) Received: from gst.com (travis@mako.gst.com [208.219.159.163] (may be forged)) by gst.gst.com (8.11.6/8.11.6) with ESMTP id g5LLcqu00724; Fri, 21 Jun 2002 17:38:53 -0400 Message-ID: <3D139ED4.5BD54E2E@gst.com> Date: Fri, 21 Jun 2002 17:47:00 -0400 From: Eric Travis X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: William Ivancic Cc: tcpsat@grc.nasa.gov Subject: Re: SCPS-TP, TCP and Rate-Based Protocol Evaluation References: <4.2.1.20020621102948.00bf5e90@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit William Ivancic wrote: >>2 Rate-based protocols are advisable for *any* environment >>where bandwidth reservation is practical and available. > >Will include with as: Rate-based protocols may be applicable for *any* >environment where bandwidth reservation is practical and available I know that I'm being a nudge but - within a *space environment* rate-based protocols really (honestly) are always advisable from a performance perspective: The biggest performance hit one takes from a well tuned TCP operating in a benign environment (no congestion, no corruption) is the cost of the initial bandwidth estimation. There may indeed be stable/safe alternatives to slow-start (an excellent research area), but they can never be cheaper to any flow than a priori knowledge (read: not having to probe at all). Once a source of loss is introduced, the benefits of a rate-based approach become even more pronounced. Hence, when one has bandwidth reservation available to them and timeliness of delivery is critical (pretty much a given if one is being as wasteful as providing dedicated bandwidth), then rate-based mechanisms will *always* preferable. >>3 The performance problems experienced with the rate-based >> protocols was most likely due to accidental misconfiguration >> of the protocols, causing them to congest the network. > >I wish this were the case, but we configured and tuned these to >the best of our capabilities and consulted with the developers >(Mitre, NRL, etc...). The problem appears to be (at least for MDP) >that the receiving system choked. It can not process fast enough >due to the algorithm and implementation of the protocol. OK, but the proper tuning is only as good as the knowledge of the effective end-to-end capacity of the path. When examined together, the performance graphs (slides 12, 14, 15, 18 and 19) still strongly suggest that the intermediate buffering in the path can only support flows of 35-40Mbps when subjected to a 500ms rtt. In fact, the measurements from the in-kernel TCP (slide 12, in particular the 100MB file results) are what are causing my stubbornness in believing that the capacity was actually somewhat lower than the assumed 100Mbps. If you've gone through footnote one, items 1 & 2, verified the end-to-end path was capable of supporting flows greater than 35-40 Mbps with an rtt of 500ms and the tcpdump traces indeed verify that all the packets were actually making it to the receiving host's side of the Cisco 7100 than that's just the way it is... But - out of curiosity, if you were hook the two test hosts together with just a cross-over cable (bypass the routers and SX/14), do they still choke at 35 - 40 Mbps? I confess that the reason I find the data troubling is because I routinely run userspace protocols that can achieve about 94Mbps of throughput in now modest hardware (333MHz Pentium II) using the same algorithms (and even some of the same code) as in the SCPS-TP implementation you tested, and so I'm slightly reluctant to believe that the bottleneck was ~35Mbps on hosts capable of sinking an in-kernel 65Mbps TCP connection (though those hosts should have been able to achieve ~ 94Mbps performance over 100baseT). The cost of crossing the kernel/userspace boundary is really not that high any more. Userspace protcols can run at very high speeds, so the fact that the MDP and SCPS implementations couldn't handle the load is surprising. >>4 With proper configuration, all the rate-based protocols >> could have performed better in the errored environments. >> >> - An increase in error frequency has the same effect as >> increasing the rtt, and hence changes the bandwidth/ >> delay product >> >> - The measured curves illustrate the effects of window >> limiting rather than the expected error performance >> curve decay >> >> - The buffer sizes used on the rate-based TCPs and MDP >> should have been re-tuned to reflect the effective >> bandwidth-delay product > > >Same comment as for item 4. We tuned these for best performance >at Zero BER. It is impractical to expect one to constantly, manually >tune a protocol for a given time-varying unknown link condition. >We believe our tuning was valid for today's protocols. That being >said, I believe work needs to be done for autotuning as I believe it >is impractical and unreasonable to expect the general users of systems >to possess the knowledge to tune each protocol for a particular >environment. Obviously a research area with lots of work being done >here. I agree, the tuning was indeed valid for the Zero BER case... However, if one of the goals of the effort was to measure where the protocols break, then it really makes sense to try and not artificially limit their performance - or at least note the reason(s) for the performance degradation... Practically speaking, if one can expect the end-users to have *some* knowledge of the end-to-end path (say, tuning for a 500ms rtt) then at least in *space environments* it is probably reasonable for them to also know the expected error characteristics of the path... The mission folks have this data readily available. Now, I absolutely agree that it is indeed unreasonable to expect a general user to be able to - or be willing to optimally tune their protocols (and frankly, it is part of our business model); To stay on point, as the space environment is more managed (and likely to stay that way for some time) than a general user environment, the expected error characteristics of the space-link will be known well in advance and the hosts *can* be tuned appropriately. Auto-tuning is enticing (we've experimented a bit with it and our 'terrestrial TCP over satellite paths' customers want it so we still have notions of adding it to our code-base someday), but I have lingering doubts as to whether any auto-tuning mechanism can tune fast-enough to still be relevant for any particular flow or valid across multiple time-disjoint flows. In the real world I always advise folks to tune their rate-based buffers to conform to an expected *worst case* expected error conditions (at least in the case where the rate-based protocols are using a flow control window to prevent overwhelming the receiver), it is perfectly safe to over provision those buffers. >>6 Even with equal performance, the deployment of a >> rate-based TCP is more desirable than the deployment >> of MDP or other non-TCP protocols when unicast data >> delivery is the goal. >> >> - The rate-based TCP is a sending-side only modification >> - All "standard" TCP applications can be deployed >> without modification > >Well, I don't consider a pure rate-base, not congestion control >protocol TCP for reasons I previously stated - even though the >protocol header is the same as TCP. However, an in-kernel reliable >rate-based protocol may be more desirable for unicast data than an >application level rate-based protocol. There is definitely room >for debate here. This is a philosophical debate. I see merit on >both sides and I don't really care to carry on such a debate here. >IMHO, neither answer is right or wrong and both are right and wrong >depending on the situation. > >I'll consider this, but I definitely cannot accept it as worded. Not to be a persistent pain, RFC 793 is still the root definition of TCP and it is not a "congestion control protocol". I'm *not* saying that is a good thing, but just that it is. A rate-paced TCP interoperates perfectly with any other implementation of TCP (paced or not). The protocol definition covers the protocol header format, the interaction of the pairwise state machines and the end-to-end semantics; The behavior of the bits over the ether in response to external stimulus is something else. Perhaps it would be difficult to accept a purely rate-based TCP as a "TCP friendly" or "congestion friendly" protocol, but it is still TCP. Remember, a purely rate-paced system *does* have congestion control but it is only suitable for use over bandwidth reserved paths: doing slow-start just makes no sense in these environments, and if you experience loss over your reserved paths, you probably don't want to trigger a congestion response. However, the important point is that it is better in general to use a protocol with TCP's end-to-end semantics rather than having to write new applications for new protocols. Having a single application that works over a reserved bandwidth deployment or a shared resource environment is preferable to having two different applications - and needing to know which one to use depending on who you are interacting with... The obvious advantage for a rate-paced TCP is that the receiving host need not even be cognizant that it's peer is rate-paced. As for user-space versus kernel-space implementation, the real requirement is for multiple entities to share the same token-bucket(s). The cause of your multi-streams testing grief was that the SCPS Reference implementation really wasn't built to support that - it was originally for a spacecraft were we were providing the OS... It wasn't expected to be used that way - even for experimentation. Generally, if you are using the SCPS Reference Implementation and want/need to support multiple application, the best way is to configure it as a transparent gateway. Eric From owner-tcpsat@grc.nasa.gov Mon Jun 24 09:11:03 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05272 for ; Mon, 24 Jun 2002 09:11:03 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 3B98FC6960 for ; Mon, 24 Jun 2002 09:11:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5OCpWsF002070 for tcpsat-outgoing; Mon, 24 Jun 2002 08:51:32 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5OCpVra002066 for ; Mon, 24 Jun 2002 08:51:31 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5OCpUSl007250 for ; Mon, 24 Jun 2002 08:51:31 -0400 (EDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7F0D5C68F9 for ; Mon, 24 Jun 2002 08:51:30 -0400 (EDT) Received: from DSHELL-W2K.cisco.com (rtp-dial-1-97.cisco.com [10.83.97.97]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA02853; Mon, 24 Jun 2002 05:51:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20020624085057.0b481ef0@lint.cisco.com> X-Sender: dshell@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jun 2002 08:51:18 -0400 To: Eric Travis From: Daniel Shell Subject: Re: The (perceived) requirement to be an IETF Standard Cc: adrian.hooke@jpl.nasa.gov, tcpsat@grc.nasa.gov In-Reply-To: <3D10F480.2417896F@gst.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Eric This my opinion on SCPS. If NASA/JPL decide that this is SCPS and it family the "space standard" then do it. Do not expect much commercial support for a new IP protocol. Also there are lot of options using IP that NASA has not even explored and should be look at such as RTP, and other enhancements ongoing in the IETF. Also if SCPS and its family is put on the RFC standards track if give this protocol some legitimacy with every one who is going to use it. So why not? At 05:15 PM 6/19/2002, Eric Travis wrote: >Dan, > >I read your response to Adrian (below) and I'm still struggling... >but I'm trying to learn. > > >While you've been a bit cryptic (possibly because you are on >vacation) I now think that a discussion of the perceived requirement >for IETF standardization of things for niche communities is an >appropriate discussion for this list. > >While I don't imagine there is *any* viable business case >for CISCO to divert energy or resources to supporting any >space-based protocols/hardware in their mainstream product >line, should I interpret your response to Adrian to indicate: > > CISCO *only* implements protocols that are IETF standards? > > CISCO will find a business case to support space-based > protocols if they are IETF standards? > >Does your work at GRC lead you to believe that there is >a large market for space-based networking? Large enough >to sustain a working community of interest within the >IETF? > >The point of the parent thread is TCP - does CISCO make many >end-user devices that would be relevant to this discussion? > >Are you planning on building middle-boxes - in which case the >dynamics of the discussion changes a lot and the need for IETF >standardization of the behavior what goes over the *private* links >and is terminated prior to the public network becomes even less >obvious... > >For this environment, I'd imagine that any business decisions >would *not* be based on whether a frob is an IETF Standard, >but rather there is a sufficiently large market to recover >development and support costs while eventually turning a profit. > >You keep asserting that: > > "NASA/JPL needs to approach the IETF to make it standard" > (there is no 'it' appropriate here, a 'them' perhaps) > >My sincere question to you is: Why? > >I'm not the sharpest crayon in the box, so could you please >explain to me what exactly will be gained by the communities >of interest by going through the justifiably rigorous and >lengthy process of making *these* protocol enhancements >IETF standards? > >They are already standards (several times over)... > >Also, why might the IETF care to bother standardizing what >is running on mostly closed/private networks? > >If you can make a good case, then perhaps *we* can convince >NASA to divert some research funds to support that effort. >The money is there, but it would need to be reprogrammed >to support the effort. > >I'm reluctantly up for the challenge, but I need your help >making a convincing case to the folks that matter at NASA HQ. > >The topic will keep until you return to work, but if you can >convince me that it is necessary, I'd like to pursue this within >NASA if at all possible. > >Eric > > > Adrian > > > > CISCO is not interested in SCPS at this time. > > NASA/JPL needs to approach the IETF to make it standard. > > So far that has not happened. > > > > At 01:04 PM 6/18/2002, Adrian J. Hooke wrote: > > >At 08:25 AM 6/18/2002 -0400, Daniel Shell wrote: > > >>Is SCPS an IETF RFC on a standards track yet? > > > > > >Dan: > > > > > >Could you perhaps ask your question a bit more precisely? Which of the > > >four SCPS protocols would you suggest should be launched on an IETF > > >standards track? > > > > > >If you are talking about the SCPS flavor of TCP (TCP Tranquility), in > what > > >context do you ask the question? TCP running between two ground end > > >systems over a satellite link, or TCP running from a ground end system to > > >an end system onboard a satellite? > > > > > >If the latter, what would be the benefit to you of IETF > standardization of > > >TCP Tranquility? If it was on a standards track, would CISCO Systems > Gobal > > >[sic] Defense and Space Group then be interested in investing corporate > > >funds to build a bunch of COTS products to support space missions? > > > > > >Best regards > > > > > >Adrian J. Hooke > > >Manager, DOD-NASA Space Communications Protocol Standards (SCPS) Project > > >NASA Jet Propulsion Laboratory, > > >Interplanetary Network Directorate > > >M/S 303-400, 4800 Oak Grove Drive > > >Pasadena, California 91109-8099, USA > > >+1.818.354.3063 OFFICE > > >+1.818.653.9553 MOBILE > > >+1 818.354.6290 FAX > > >http://www.scps.org > > > > > > > Dan Shell > > Network Architect > > CISCO Systems > > Gobal Defense and Space Group > > Wireless/Mobile Networking/ Satellite > > 216 643 2422 Dan Shell Network Architect CISCO Systems Gobal Defense and Space Group Wireless/Mobile Networking/ Satellite 216 643 2422 From owner-tcpsat@grc.nasa.gov Mon Jun 24 09:57:23 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07149 for ; Mon, 24 Jun 2002 09:57:23 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id A1FCEC6953 for ; Mon, 24 Jun 2002 09:57:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5ODkhDM017790 for tcpsat-outgoing; Mon, 24 Jun 2002 09:46:43 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ODkgra017785 for ; Mon, 24 Jun 2002 09:46:42 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5ODkfSl016676 for ; Mon, 24 Jun 2002 09:46:41 -0400 (EDT) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B9245C6948 for ; Mon, 24 Jun 2002 09:46:40 -0400 (EDT) Received: (qmail 21468 invoked from network); 24 Jun 2002 13:46:39 -0000 Received: from unknown (HELO gst.com) ([66.92.165.221]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 24 Jun 2002 13:46:39 -0000 Message-ID: <3D1722BE.5030103@gst.com> Date: Mon, 24 Jun 2002 09:46:38 -0400 From: Eric Travis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 MIME-Version: 1.0 To: Daniel Shell Cc: adrian.hooke@jpl.nasa.gov, tcpsat@grc.nasa.gov Subject: Re: The (perceived) requirement to be an IETF Standard References: <4.3.2.7.2.20020624085057.0b481ef0@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan, Daniel Shell wrote: > Eric > > This my opinion on SCPS. > > If NASA/JPL decide that this is SCPS and it family the "space standard" > then do it. Do not expect much commercial support for a new IP protocol. I'm afraid that you are mistaken... There is *nobody* advocating a "new IP protocol", IPv4 and IPv6 do nicely with the identified space extensions - if that's what a mission eventually chooses to use. I think you will find that all the testing that Will had previously referenced was over IPv4. Commercial support means different things to different "industries"; The space community is well supported by industry, it's just that it may not be yours. Diversity is generally a good thing. The overlap between the traditional Internet economy and the spaceborne community is likely to be terribly small except when the data hits a groundstation - then it is more of a traditional networking environment. Spacecraft have been operating a long time without commercial support from "Internet-related" companies... The ability to purchase flight qualified hardware/software from companies such as your own would be nice, but it is hardly a critical requirement. So, while it is a cool idea to stitch up end-to-end connections from an orbiting instrument to a principle investigator in Lyon, a compelling reason to do so (economic or technical) has yet to surface. In time, it may still come - until then, mission architects always have had that option. BTW: SCPS is not a "NASA/JPL" thing; Please let's try and get past these attempts at marginalizing, OK? You are inadvertantly insulting more people that you might imagine who have never been affiliated with NASA, let alone JPL. > Also there are lot of options using IP that NASA has not even explored > and should be look at > such as RTP, and other enhancements ongoing in the IETF. There is always the promise of something brighter on the horizon. RTP is not really a suitable solution for reliable bulk data transfer. I would have expected a reference to something like SCTP in such an argument. Surely this isn't all just a case of "Not Invented Here"... > Also there are lot of options using IP that NASA has not even explored > and should be look at > such as RTP, and other enhancements ongoing in the IETF. Well... the space community (the folks who *are* intended to use the SCPS recommendations) has already "given them legitimacy" by standardizing them; You may not think much of the standards organizations (plural) that cover the community of interest - and that is your right. > So why not? Lack of return on investment? Lack of forseeable benefit to the IETF (what motivation is there for the an IETF area director to put this on an agenda)? Lack of forseeable benefit to the space community? I'm afraid that if this is as cogent the argument gets for bringing niche community requirments (how many spacecraft get launched each year that are not telecommunication bent-pipes?) then we're not going to get very far in convincing those who capable of supporting an IETF effort. I'm still faced with the question: Why? Based on your response, I can only conclude that there is no compelling need/benefit for the IETF to attempt to standardize what happens in niche communities. Terrestrial wireless will eventually have a huge impact on the Internet, but communications to space based entities? Not in the foreseeable future. Eric From owner-tcpsat@grc.nasa.gov Mon Jun 24 11:44:04 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12747 for ; Mon, 24 Jun 2002 11:44:04 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 084E264123 for ; Mon, 24 Jun 2002 11:44:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5OFSSHQ016910 for tcpsat-outgoing; Mon, 24 Jun 2002 11:28:28 -0400 (EDT) Received: from opus.lerc.nasa.gov (opus.lerc.nasa.gov [139.88.102.98]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5OFSRra016903; Mon, 24 Jun 2002 11:28:27 -0400 (EDT) Received: from grc.nasa.gov (ras140.lerc.nasa.gov [139.88.123.140]) by opus.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA31769; Mon, 24 Jun 2002 11:28:26 -0400 Message-ID: <3D173AAD.6080003@grc.nasa.gov> Date: Mon, 24 Jun 2002 11:28:45 -0400 From: David Carek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Shell Cc: tcpsat@grc.nasa.gov Subject: Re: The (perceived) requirement to be an IETF Standard References: <4.3.2.7.2.20020624085057.0b481ef0@lint.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Shell wrote: > Eric > > This my opinion on SCPS. > > If NASA/JPL decide that this is SCPS and it family the "space standard" > then do it. Do not expect much commercial support for a new IP protocol. > > Also there are lot of options using IP that NASA has not even explored > and should be look at > such as RTP, and other enhancements ongoing in the IETF. > > Also if SCPS and its family is put on the RFC standards track if give > this protocol some legitimacy > with every one who is going to use it. > > So why not? My guess is that the market won't demand it. Standards seem to benefit the industry when there are sufficient quantities and companies involved to warrant a standard. I doubt the space segment will ever have similar market forces that drive the terrestrial side. Also, the needs that govern space qualified hardware and software are very different than the terrestrial market, so there may be a culture clash trying to develop these standards through the IETF (this is just a total guess). If the SCPS spec were part of the IETF standard, I doubt it would cause terrestrial vendors to start supporting it. That's not to say that the IETF standards track would be a bad idea for the space segment, I just don't think there's a driving market force that will make it happen. SCPS is a very nice specification to handle the limitations of space communications. If a few flight qualified implementations can be developed, it could still benefit the space segment. It's mostly roll your own right now. From owner-tcpsat@grc.nasa.gov Mon Jun 24 12:07:15 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14674 for ; Mon, 24 Jun 2002 12:07:15 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id ED151C699B for ; Mon, 24 Jun 2002 12:07:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5OFqkpV023998 for tcpsat-outgoing; Mon, 24 Jun 2002 11:52:46 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5OFqira023990 for ; Mon, 24 Jun 2002 11:52:44 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5OFqiSl009623 for ; Mon, 24 Jun 2002 11:52:44 -0400 (EDT) Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.160.40]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C5B6DC696C for ; Mon, 24 Jun 2002 11:52:43 -0400 (EDT) Received: from ahooke-2k.jpl.nasa.gov (hookepc2.jpl.nasa.gov [137.79.10.230]) by eis-msg-012.jpl.nasa.gov (8.12.1/8.12.1) with ESMTP id g5OFqOol001165; Mon, 24 Jun 2002 08:52:25 -0700 (PDT) Message-Id: <5.1.0.14.2.20020624080659.01f5f1d0@pop.jpl.nasa.gov> X-Sender: ahooke@pop.jpl.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 24 Jun 2002 08:52:24 -0700 To: Daniel Shell From: "Adrian J. Hooke" Subject: Re: The (perceived) requirement to be an IETF Standard Cc: tcpsat@grc.nasa.gov In-Reply-To: <4.3.2.7.2.20020624085057.0b481ef0@lint.cisco.com> References: <3D10F480.2417896F@gst.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk At 08:51 AM 6/24/2002 -0400, Daniel Shell wrote: >Also if SCPS and its family is put on the RFC standards track if give this >protocol some legitimacy >with every one who is going to use it. Dan: the SCPS variant of TCP/UDP - "TCP Tranquility" - exists as: a) An International Standard (ISO 15893:2000) and; b) A US Department of Defense Military Standard (MIL-STD-2045-44000). c) A NASA Preferred Technical Standard We are interested in hearing from other people on this list: would putting Tranquility through the RFC process further increase its "legitimacy" as far as you are concerned? Does anyone out there feel inhibited about experimenting with SCPS capabilities by the current status? >So why not? Time and money, both of which are in short supply. What would be the return on investment? ///adrian [ BTW, as Eric notes, the SCPS capabilities are not a "NASA/JPL" thing. They exist as full NASA Technical Standards that are approved by the NASA Chief Engineer (http://standards.nasa.gov/ ). That means that, unlike the products of NASA's Research Centers, they are the preferred standards for use on NASA's flight missions. They are programmatically managed by the Office of Space Communications within the Office of Space Flight at NASA Headquarters in Washington DC. ] From owner-tcpsat@grc.nasa.gov Tue Jun 25 05:04:53 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27117 for ; Tue, 25 Jun 2002 05:04:53 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 6D3B064139 for ; Tue, 25 Jun 2002 05:05:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5P8q33T001132 for tcpsat-outgoing; Tue, 25 Jun 2002 04:52:03 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5P8q2ra001122 for ; Tue, 25 Jun 2002 04:52:02 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5P8q1Sl006707 for ; Tue, 25 Jun 2002 04:52:01 -0400 (EDT) Received: from mail.hellasnet.gr (mail.hellasnet.gr [212.54.192.3]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 0D8096410B for ; Tue, 25 Jun 2002 04:51:56 -0400 (EDT) Received: from teacher.com (ppp3-239.pop.hellasnet.gr [193.92.197.239]) by mail.hellasnet.gr (8.12.1/8.12.1) with SMTP id g5P8prXn013558 for ; Tue, 25 Jun 2002 11:51:53 +0300 (EET DST) Message-Id: <200206250851.g5P8prXn013558@mail.hellasnet.gr> From: "NEWSLETTER" To: Subject: CALL FOR PAPERS Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 25 Jun 2002 11:51:57 +0300 Content-Transfer-Encoding: 8bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit A MESSAGE FROM THE GENERAL CHAIRMAN, PROF. P.EKEL ------------------------------------------------- The WSEAS (http://www.wseas.org) International Conferences on: *** SYSTEM SCIENCE (ICOSYS 2002) *** APPLIED MATHEMATICS AND COMPUTER SCIENCE (AMCOS 2002) *** POWER ENGINEERING SYSTEMS (ICOPES 2002) will be held in Sheraton Hotel, Rio de Janeiro, Brazil, October 21-24, 2002. Types of Submission Accepted: - Papers - Special Sessions - Tutorials - Workshops - Panel Discussions All submissions are to be done electronically. The submission pages as well as other conference details can be found at: http://www.wseas.com/conferences/2002/brazil/icosys - ICOSYS 2002 http://www.wseas.com/conferences/2002/brazil/amcos - AMCOS 2002 http://www.wseas.com/conferences/2002/brazil/icopes - ICOPES 2002 All accepted papers are simultaneously published in: Conference Proceedings (CD) + Post-Conference Luxurious Edition from the Series of International Reference Books and Textbooks or Conference Proceedings (CD) + WSEAS Transactions (Journals) IMPORTANT DEADLINES: Submissions due: June 30,2002 Notification of acceptance: one month after its submission or earlier We should be very grateful if you could distribute the information about our Conferences among your faculty members and colleagues. Prof. Petr Ekel Post-Graduate Program in Electrical Engineering Pontifical catholic University of Minas Gerais Av. Dom Jose Gaspar, 500 30.535-610, Belo Horizonte, MG Brazil Phone: +55031-3319-4305 Fax: +55-31-3319-4225 ******************************************************** * * * * * * * * * * * * * * DO YOU WANT TO UNSUBSCRIBE? * * * * * * * * * * * * * * To unsubscribe, send an email to remove_for_ever@wseas.org with subject REMOVE or UNSUBSCRIBE. If you use different email account, include the email account(s) that you want to unsubscribe in the Body of your message. If you think this email is SPAM, contact abuse@wseas.org with a copy of this message From owner-tcpsat@grc.nasa.gov Tue Jun 25 17:57:19 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00721 for ; Tue, 25 Jun 2002 17:57:19 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id E7942C69DF for ; Tue, 25 Jun 2002 17:57:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5PLdQ8h000475 for tcpsat-outgoing; Tue, 25 Jun 2002 17:39:26 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5PLdNra000450 for ; Tue, 25 Jun 2002 17:39:23 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5PLdMSl013383 for ; Tue, 25 Jun 2002 17:39:22 -0400 (EDT) Received: from Eng.Auburn.EDU (dns.eng.auburn.edu [131.204.10.13]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 5EBB2C69B1 for ; Tue, 25 Jun 2002 17:39:21 -0400 (EDT) Received: from chadia.eng.auburn.edu (chadia.eng.auburn.edu [131.204.19.11]) by Eng.Auburn.EDU (8.11.6/8.11.6) with ESMTP id g5PLd9a07070; Tue, 25 Jun 2002 16:39:09 -0500 (CDT) Received: from localhost (sbiaz@localhost) by chadia.eng.auburn.edu (8.10.2+Sun/8.6.4) with ESMTP id g5PLdDB09626; Tue, 25 Jun 2002 16:39:13 -0500 (CDT) X-Authentication-Warning: chadia.eng.auburn.edu: sbiaz owned process doing -bs Date: Tue, 25 Jun 2002 16:39:13 -0500 (CDT) From: Saad Biaz To: csse-faculty@eng.auburn.edu, bluehoc-discussion@www-124.southbury.usf.ibm.com, ecn-interest@research.att.com, Conferencesa@comsoc.org, tcpsat@lerc.nasa.gov Cc: Mohammed Erradi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk --------- Please, accept our apologies if you receive multiple copies ------- CALL FOR PAPERS International Workshop on Communication Software Engineering (IWCSE’2002) December 19, 2002 As part of the activities of IEEE 2nd International Symposium on Signal Processing and Information Technology ISSPIT’2002 Web Site: http://www.u-bourgogne.fr/isspit2002 December 18-21, 2002, Marrakech, Morocco Co-sponsored by IEEE Signal Processing Society and the IEEE Computer Society As part of the activities of IEEE ISSPIT 2002, the second in a series of international symposia that aims to cover most of the aspects in the fields of signal processing and information technology, a special workshop on Communication Software Engineering will be organized. Communication Software is a discipline at the intersection of Telecommunication Networks and Software Engineering. Both areas are at heart of the Information Technology and the Internet, which are playing a more and more important role in our societies. The aim of this special workshop is to bring together researchers, from both academia and industries, to present and discuss their recent research results in this discipline. Papers dealing with any aspect of communication software engineering are solicited for submission to the workshop. Topics of particular interest include but not limited to: Quality of Service, Formal methods, Verification, Specification, Testing, features interaction, Real-time systems, Mobile Agents, Network and Service Management, and Mobile Systems. Poster Proposals on these topics are also invited. With the Internet we are entering a new era where telecommunication systems are playing a key role. Software is critical component of these systems. Understanding its development process and mastering is becoming a must. We are confident that the contributions in this special event will help to better understand communication software, and the recent development in this discipline. Authors are invited to submit four-page papers in two-column formats including diagrams and references in attached PDF or Postscript files to an email message. The title page should include author(s) name(s), affiliation, mailing address, fax, and email address. Papers should be submitted to the workshop chair. Important Dates : Full-Paper Submission : July 24 , 2002 Notification for Acceptance: September 6th, 2002 Final Version Due : September 30, 2002 Chair: Mohammed Erradi Mohamed V-Souissi University, ENSIAS, B.P.713, Agdal, Rabat, Morocco Phone : (212) 37-77 73 17 / 37 77 85 79 Fax : (212) 37- 77 72 30 Email: erradi@ensias.ma ---------------------------------------------------------------------- Saad Biaz, Ph.D., Assistant Prof. Voice: (334) 844 6307 114 Dunstan Hall Auburn University Fax : (334) 844 6329 Auburn, AL 36849-5347, USA http://www.eng.auburn.edu/~sbiaz ---------------------------------------------------------------------- From owner-tcpsat@grc.nasa.gov Wed Jun 26 11:56:44 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25518 for ; Wed, 26 Jun 2002 11:56:43 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 547A564188 for ; Wed, 26 Jun 2002 11:56:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5QFZpxs004549 for tcpsat-outgoing; Wed, 26 Jun 2002 11:35:51 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5QFZora004543; Wed, 26 Jun 2002 11:35:50 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5QFZnSl013691; Wed, 26 Jun 2002 11:35:49 -0400 (EDT) Received: from mailhost4.gsfc.nasa.gov (mailhost4.gsfc.nasa.gov [128.183.244.179]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id EDC2764157; Wed, 26 Jun 2002 11:35:48 -0400 (EDT) Received: from ipinspace.gsfc.nasa.gov (ipinspace.gsfc.nasa.gov [128.183.223.86]) by mailhost4.gsfc.nasa.gov (8.11.4/8.11.4) with ESMTP id g5QFZlS29176; Wed, 26 Jun 2002 11:35:47 -0400 (EDT) Received: from ipinspace.gsfc.nasa.gov (ssppbg3.gsfc.nasa.gov [150.144.200.44]) by ipinspace.gsfc.nasa.gov (8.9.3+Sun/8.9.1) with ESMTP id PAA06285; Wed, 26 Jun 2002 15:35:47 GMT Message-ID: <3D19DF62.2EB927E8@ipinspace.gsfc.nasa.gov> Date: Wed, 26 Jun 2002 11:36:03 -0400 From: Keith Hogie X-Mailer: Mozilla 4.79C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Eric Travis Cc: William Ivancic , tcpsat@grc.nasa.gov Subject: UDP versus SCPS-TP, TCP etc. References: <4.2.1.20020621102948.00bf5e90@popserve.grc.nasa.gov> <3D139ED4.5BD54E2E@gst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit All, I have been following the discussion on Satellites running IP and it seems to have gone off heavily in the TCP direction. I realize this is the TCPSAT group but the question seemed to be broader than just TCP. What we see for missions using IP is a very heavy use of UDP and not TCP. TCP will always have limitations that we feel are best avoided by using UDP. This allows us to do things like data transfers over one-way links which does not work with TCP. I have seen people attempting to fix TCP for all sorts of special cases for years and still don't see much convergence. For an example of other UDP use see the following: http://www.esa.int/export/esaCP/ESALS5OED2D_index_0.html http://www.gcs-salzburg.at/ http://www.gcs-salzburg.at/products/p_odg.html http://www.simple.at/ http://www.datacast.at/technology.html We are looking at the MDP/NORM UDP-based file transfer protocol and plan on using it to transfer files from the Space Shuttle payload bay on STS-107 (scheduled to launch on July 19th but may be slipping right now). The bottom line is we want to use standard IP/UDP/TCP protocols that are supported in every operating system available. Using a modified TCP requires more software support that creates more problems when you are building and deploying operational control centers and level-zero processing systems. We really prefer to use standard protocols at layer 4 and below and do any space specific tweaks in the application layer. ---------------------------------------------------------------------- Keith Hogie e-mail: Keith.Hogie@gsfc.nasa.gov Computer Sciences Corp. office: 301-794-2999 fax: 301-794-9480 7700 Hubble Dr. Lanham-Seabrook, MD 20706 USA 301-286-3203 @ NASA/Goddard ---------------------------------------------------------------------- From owner-tcpsat@grc.nasa.gov Wed Jun 26 12:56:39 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29109 for ; Wed, 26 Jun 2002 12:56:39 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 9A4C8641B4 for ; Wed, 26 Jun 2002 12:56:52 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5QGikaW024801 for tcpsat-outgoing; Wed, 26 Jun 2002 12:44:46 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5QGiira024784; Wed, 26 Jun 2002 12:44:44 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5QGihSl026376; Wed, 26 Jun 2002 12:44:43 -0400 (EDT) Received: from gst.gst.com (gst.gst.com [208.219.159.150]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 36C48C69F1; Wed, 26 Jun 2002 12:44:43 -0400 (EDT) Received: from gst.com (travis@mako.gst.com [208.219.159.163] (may be forged)) by gst.gst.com (8.11.6/8.11.6) with ESMTP id g5QGZju07682; Wed, 26 Jun 2002 12:35:45 -0400 Message-ID: <3D19EF76.5AE98353@gst.com> Date: Wed, 26 Jun 2002 12:44:38 -0400 From: Eric Travis X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Keith Hogie Cc: William Ivancic , tcpsat@grc.nasa.gov Subject: Re: UDP versus SCPS-TP, TCP etc. References: <4.2.1.20020621102948.00bf5e90@popserve.grc.nasa.gov> <3D139ED4.5BD54E2E@gst.com> <3D19DF62.2EB927E8@ipinspace.gsfc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Keith, With all due apologies to Sir Arthur Conan Doyle ("The Sign of Four"): "It is UDP," he said, "a seven-per-cent solution. Would you care to try it?" UDP doesn't help to avoid *any* of the problems of TCP, it just moves them to something above UDP. You will still need to build the required subset of: {sequencing, reordering, flow control, congestion avoidance, reliability, etc.} into a "standard" application - or applications. If, for a particular task, the required subset of the above is indeed the null set (and as you note, data broadcasting is one such deployment), UDP is an excellent choice for an IP-based implementation of that particular application - but this really is not the model that most people fall in love with when they first hear the siren's song of "Internet in Space"... > The bottom line is we want to use standard IP/UDP/TCP protocols > that are supported in every operating system available. You desires are as valid as anyone else involved; It has been said many times before, it's the prerogative of any given mission to choose their desired communications model and supporting mechanisms. As for "IP/UDP/TCP protocols that are supported in *every* operating system available" - that's not demonstrably true is it? "Supportable" absolutely, universally supported - not quite. We can name some cases where support had to be added to an OSes, so the distinction is: "IP/UDP/TCP protocols that *can* be supported in *every* operating system - period." This is the case for *any* layer four protocol. Whether or not a particular layer four protocol *needs* to be supported by a particular operating system depends on the assumed communications architecture (see next) > I have seen people attempting to fix TCP for all sorts of special > cases for years and still don't see much convergence. In all fairness, I've also seen people providing reliable services over UDP for many more years, and still there is no convergence; I don't consider a lack of convergence a bad thing :o) > Using a modified TCP requires more software support that creates > more problems when you are building and deploying operational control > centers and level-zero processing systems. I respectfully disagree - any UDP-based solution clearly requires some sort of applications software; How is the deployment of this application software any more complex than the deployment of something capable of handling TCP (which can be application software or a tiny box with two 100BaseT ports, etc.)? Further, if we are going to the trouble to encapsulate the spacecraft traffic in IP datagrams - I would imagine that the desire is to *eliminate* the level zero processing and to route those IP datagrams directly to the principle investigators... What role must the control centers have in the end-to-end data flow for this operational model? > We really prefer to use standard protocols at layer 4 and below and > do any space specific tweaks in the application layer. That's certainly a position that could be advocated - to help move that notion forward you need to get people to converge on a full solution: an application layer protocol (and it's interface) so that people can build the same sort of diverse applications set that they have available to them over stream and datagram sockets. As silly as the notion is to *me* (and I DO think it to be silly), the people who demonstrate the greatest support for the concept of "IP in Space" have expressed interest in supporting things like telnet and http between their spaceborne instruments and their ground-based infrastructure. These - and many of the other services people commonly associate with an "Internet experience" are TCP-based. Unless we can build and (widely) deploy UDP-based alternatives to these, UDP-based solutions remains a "seven (or [1..9]7 percent solution". So, while UDP is part of an IP-based solution set, it is not sufficient. Eric Keith Hogie wrote: > > All, > > I have been following the discussion on Satellites running IP and it > seems to have gone off heavily in the TCP direction. I realize this is > the TCPSAT group but the question seemed to be broader than just TCP. > > What we see for missions using IP is a very heavy use of UDP and not > TCP. TCP will always have limitations that we feel are best avoided > by using UDP. This allows us to do things like data transfers over > one-way links which does not work with TCP. I have seen people > attempting to fix TCP for all sorts of special cases for years and > still don't see much convergence. > > For an example of other UDP use see the following: > > http://www.esa.int/export/esaCP/ESALS5OED2D_index_0.html > http://www.gcs-salzburg.at/ > http://www.gcs-salzburg.at/products/p_odg.html > http://www.simple.at/ > http://www.datacast.at/technology.html > > We are looking at the MDP/NORM UDP-based file transfer protocol and > plan on using it to transfer files from the Space Shuttle payload > bay on STS-107 (scheduled to launch on July 19th but may be slipping > right now). > > The bottom line is we want to use standard IP/UDP/TCP protocols that > are supported in every operating system available. Using a modified > TCP requires more software support that creates more problems when > you are building and deploying operational control centers and > level-zero processing systems. We really prefer to use standard > protocols at layer 4 and below and do any space specific tweaks > in the application layer. > > ---------------------------------------------------------------------- > Keith Hogie e-mail: Keith.Hogie@gsfc.nasa.gov > Computer Sciences Corp. office: 301-794-2999 fax: 301-794-9480 > 7700 Hubble Dr. > Lanham-Seabrook, MD 20706 USA 301-286-3203 @ NASA/Goddard > ---------------------------------------------------------------------- From owner-tcpsat@grc.nasa.gov Wed Jun 26 17:37:03 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12115 for ; Wed, 26 Jun 2002 17:37:03 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 0911AC693A for ; Wed, 26 Jun 2002 17:37:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5QLMIQY004435 for tcpsat-outgoing; Wed, 26 Jun 2002 17:22:18 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5QLMGra004425; Wed, 26 Jun 2002 17:22:17 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5QLMFSl015099; Wed, 26 Jun 2002 17:22:15 -0400 (EDT) Received: from larces.uece.br (unknown [200.129.27.6]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 2A07D6409B; Wed, 26 Jun 2002 17:22:13 -0400 (EDT) Received: from insoft.softex.br (insoft.softex.br [200.17.44.1]) by larces.uece.br (8.9.2/8.9.2) with SMTP id RAA18952 for ; Wed, 26 Jun 2002 17:32:39 -0300 Received: (qmail 18364 invoked from network); 26 Jun 2002 13:44:24 -0000 Received: from unknown (HELO toshibauser) (200.17.44.51) by insoft.softex.br with SMTP; 26 Jun 2002 13:44:24 -0000 From: =?iso-8859-1?Q?Joaquim_Celestino_J=FAnior?= To: Subject: =?iso-8859-1?Q?GRES'03_-_Fortaleza-Cear=E1-Br=E9sil?= Date: Wed, 26 Jun 2002 14:14:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit APPEL A COMMUNICATIONS GRES'03 Colloque Francophone sur la Gestion de Réseaux Et de Services 24-27 février 2003, Fortaleza, Ceará, Brésil Président du Colloque Joaquim Celestino Júnior (UECE, Brésil) Comité Scientifique Nazim Agoulmine (Lip6, France) Kamel Barkaoui (CNAM Paris, France) Mounir Boukaddoum (UQAM, Canada) Raouf Boutaba (Université de Waterloo, Canada) Antoine Boutignon (Cégétel, France) Ken Chen (L2TI, France) Omar Cherkaoui (UQAM, Canada) Jean-Pierre Claudé (Université de Versailles, France) Gilles Desoblin (Alcatel, France) Olivier Festor (INRIA Lorraine, France) Monique Gibeaux (Bouygues Télécom, France) Marie-Pierre Gervais (Lip6, France) Farouk Kamoun (ENSI de Tunis, Tunisie) Ahmed Karmouch (Université d’Ottawa) Daniel Kofman (ENST, Paris) Jacques Labetoulle (IAAI deMarseille, France) José Marcos Nogueira (UFMG, Brésil) Joberto Martins (UNIFACS, Brésil) Mauro Oliveira (CEFET-CE, Brésil) Fetah Ouzzani (Qosmic, France) Guy Pujolle (Lip6, France) Ahmed Serhrouchni (ENST, France) Noèmie Simoni (ENST, France) Jose Neuman de Souza (UFC, Brésil) Sami Tabbane (SupCom, Tunisie) Carlos Westphall (UFSC, Brésil) Simon Znaty (Efort, France) Comité d'organisation José Carvalho Filho (INSOFT, Brésil) Ana Luiza Diniz (UECE, Brésil) Marcos Clayton Fernandes (UECE, Brésil) Taumaturgo Oliveira (UECE, Brésil) José Luiz Pires (INSOFT, Brésil) Marcus Rodrigues (CEFET-CE, Brésil) Objectif du colloque : Le Colloque Francophone sur Gestion de Réseaux Et de Services est actuellement à sa cinquième édition. Il a déjà eu lieu à Paris en 1995, à Rennes en 1997, à Montréal en 1999 et enfin à Marrakech en 2001. Son objectif est de permettre à la communauté francophone des enseignants, chercheurs et industriels dans le domaine de la gestion de réseaux et des services de faire régulièrement le point sur les avancées dans le domaine. Ce colloque comprend une journée de tutoriaux, suivie de trois jours de conférence. Le comite de programme souhaite se voir soumettre des communications qui traitent de tout sujet relatif a pour objectif de réunir des doctorants, des enseignants-chercheurs et des industriels sur le thème important de la QoS à travers des tutoriaux, des tables rondes, des conférences et les sessions d'exposés des articles retenus. La liste non exhaustive qui suit, donne quelques sujets d’intérêt pour le colloque : - Plates-formes de gestion, normes et protocoles - Réseau actif et Réseau programmable - Réseaux privés virtuels - Réseaux et Services IP, Téléphonie sur IP, Transition de IPv4 à IPv6 - Réseaux "Soft" (Soft-Switch, MSF, Parlay, OSA, etc.) et commutation de niveau 4 - Gestion des réseaux (ad-hoc, mobiles, optiques, CATV) - Gestion de la Qualité de service - Gestion de la QoS sur IP (MPLS, Diffserv, COPS, Intserv, Traffic Engineering) - Gestion des services orientés transaction et de commerce électronique - SLA et courtage de la bande passante - Nouvelles Technologies de gestion - Agents mobiles, Agents intelligents - Plans de contrôle et plan de gestion - Approches "Policy-Driven" - Approches ASP et solutions de gestion associées - Modèles d’Information pour la gestion - Métrologie de la QoS - Spécification de la QoS - Création de service - Pricing, Accounting et Billing - Surveillance et performance de bout en bout - Fautes, Corrélation des alarmes, Filtrage et résolution de pannes, - Gestion de la Sécurité - Gestion Distribuée et Scalabilité - Gestion dynamique, Gestion proactive - Ingénierie des Processus de gestion des réseaux et des services des opérateurs - Applications, études de cas et retours d'expériences - Interfaces utilisateur et réalité virtuelle dans la gestion - Data Warehousing, Mining et méthodes statistiques de gestion - Logiciel de gestion Open-Source Soumissions de papiers : L'auteur est invité à soumettre un article complet non publié dans d'autres conférences ou journaux. La soumission des communications se fait sur la base d'articles complets (10 à 12 pages, soit environ 4000 mots). La langue officielle est le français (les articles écrits en anglais seront également accepté). Les versions électroniques (le format Microsoft Word est privilégié, postcript ou pdf) sont préconisées et doivent être envoyées par E-mail à : colloque.gres@larces.uece.br ou colloque.gres@insoft.softex.br . La première page de l'article doit indiquer clairement le titre de l'article, le ou les noms des auteurs, l'adresse de correspondance postale, un numéro de téléphone, un numéro de fax et une adresse électronique. Pour être publiées dans les actes du congrès, les versions finales des articles devront respecter strictement les consignes d'édition (qui seront mises très prochainement sur le site de GRES'2003) et être envoyées par E-mail à l'adresse suivante : colloque.gres@larces.uece.br ou colloque.gres@insoft.softex.br . Dates à retenir : 15/11/2002 : date limite pour la réception des articles soumis. 21/12/2003 : notification aux auteurs de la décision du comité scientifique. 20/01/2003 : date limite pour la réception des textes définitifs à inclure dans les actes du colloque. From owner-tcpsat@grc.nasa.gov Thu Jun 27 11:37:54 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24871 for ; Thu, 27 Jun 2002 11:37:54 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 348446418F for ; Thu, 27 Jun 2002 11:38:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5RFIwaj009575 for tcpsat-outgoing; Thu, 27 Jun 2002 11:18:58 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5RFIvra009569 for ; Thu, 27 Jun 2002 11:18:57 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5RFIuSl016809 for ; Thu, 27 Jun 2002 11:18:56 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 9C6266412F for ; Thu, 27 Jun 2002 11:18:46 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17Nb2d-0003zg-00 for tcpsat@grc.nasa.gov; Thu, 27 Jun 2002 16:18:39 +0100 Date: Thu, 27 Jun 2002 16:18:38 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: tcpsat@grc.nasa.gov Subject: JSAC special issue: broadband IP networks via satellites Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *17Nb2d-0003zg-00*URvA/P3rvmg* (SECM, UniS) Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk http://www.argreenhouse.com/society/J-SAC/Calls/broadband_ip.html closing date Dec 2nd 2002. L. From owner-tcpsat@grc.nasa.gov Fri Jun 28 06:33:56 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17061 for ; Fri, 28 Jun 2002 06:33:56 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 731F5C6A4E for ; Fri, 28 Jun 2002 06:34:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5SAJaZD004900 for tcpsat-outgoing; Fri, 28 Jun 2002 06:19:36 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5SAJZra004893; Fri, 28 Jun 2002 06:19:35 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5SAJYSl002107; Fri, 28 Jun 2002 06:19:34 -0400 (EDT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id DD1EC64096; Fri, 28 Jun 2002 06:19:33 -0400 (EDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.4/jtpda-5.4+victor) with ESMTP id g5SAGpBn004206 ; Fri, 28 Jun 2002 12:16:51 +0200 X-pt: isis.lip6.fr Received: from GP (rp-dhcp19 [132.227.61.219]) by tibre.lip6.fr (8.11.3nb1/8.11.3) with SMTP id g5SAFuw03146; Fri, 28 Jun 2002 12:15:56 +0200 (MEST) Message-ID: <00f301c21e8c$4a5b7e40$db3de384@GP> From: "Pujolle Charlotte" To: Subject: Med-hoc-net'2002 Date: Fri, 28 Jun 2002 12:04:42 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01C21E9B.FC49E2E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D4_01C21E9B.FC49E2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES ____________________________________________________________________ CALL FOR PAPERS- Med-hoc-net'2002 Grand Hotel Chia Laguna, Chia (CA), Sardegna, Italy = (www.hotelchialaguna.com) Conference web site: www.med-hoc-net.org The First Annual Mediterranean Ad Hoc Networking Workshop, Med-hoc-Net = 2002, sponsored by IFIP, will take place in Sardegna, Italy, Sept 4-6, = 2002. The aim of the Med-hoc-Net Workshop is to bring together researchers = from both sides of the Atlantic (and Pacific) to the shores of the = Mediterranean Sea. The Workshop will serve as a forum for ad hoc network = technologists and visionaries from academia, industry and research labs, = to present current research, advanced technology, ongoing prototyping = efforts, experience reports, case studies, and descriptions of = innovative ad hoc systems. Each offering of the Workshop will have a = different theme. The specific theme this year will be "Quality of = Service" in ad hoc networks. ____________________________________________________________________ To unsubscribe from our CFP Mail List. Please send back this message = with Unsubcribe in the object of the message. ------=_NextPart_000_00D4_01C21E9B.FC49E2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES
________________________________________________________________= ____

CALL FOR PAPERS- Med-hoc-net'2002
Grand Hotel Chia = Laguna, Chia (CA),=20 Sardegna, Italy (www.hotelchialaguna.com)

Conference web site: = www.med-hoc-net.org

The=20 First Annual Mediterranean Ad Hoc Networking Workshop,  Med-hoc-Net 2002, sponsored by = IFIP,=20 will take place in Sardegna,=20 Italy,=20 Sept 4-6, 2002.
The aim of the Med-hoc-Net Workshop is to bring = together=20 researchers from both sides of the Atlantic=20 (and Pacific) to the shores of the Mediterranean=20 Sea.=20 The Workshop will serve as a forum for ad hoc network technologists and=20 visionaries from academia, industry and research labs, to present = current=20 research, advanced technology, ongoing prototyping efforts, experience = reports,=20 case studies, and descriptions of innovative ad hoc systems. Each = offering of=20 the Workshop will have a different theme. The specific theme this year = will=20 be =93Quality of Service=94 in ad hoc networks.
________________________________________________________________= ____
 
To unsubscribe from our CFP Mail List. Please send back this = message with=20 Unsubcribe in the object of the=20 message.
------=_NextPart_000_00D4_01C21E9B.FC49E2E0-- From owner-tcpsat@grc.nasa.gov Sat Jun 29 05:15:29 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20879 for ; Sat, 29 Jun 2002 05:15:28 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 17364C6A56 for ; Sat, 29 Jun 2002 05:15:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5T8ujNO006756 for tcpsat-outgoing; Sat, 29 Jun 2002 04:56:45 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5T8uira006752 for ; Sat, 29 Jun 2002 04:56:44 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5T8uiSl009758 for ; Sat, 29 Jun 2002 04:56:44 -0400 (EDT) Received: from telefonica (16.Red-80-33-132.pooles.rima-tde.net [80.33.132.16]) by seraph2.grc.nasa.gov (Postfix) with SMTP id DD8B3C68D2 for ; Sat, 29 Jun 2002 04:56:42 -0400 (EDT) From: "Grupo Psicopedagogico de Enseñanza" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 29 Jun 2002 10:56:37 Message-Id: <20020629085642.DD8B3C68D2@seraph2.grc.nasa.gov> Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk Grupo Psicopedagogico de Enseñanza PROFESORES A DOMICILIO para la etapa de 6 a 18 años Primaria , E.S.O. y Bachiller AFIANCE Y GARANTICE EL FUTURO A SU HIJO LA SOLUCION CLASES DE RECUPERACION. En su domicilio, dias y horarios adaptados al alumno incluso los sabados. Disponemos de profesores de todas las materias y Asesores Pedagógicos. Llamenos les informaremos Telefono 902180066 From owner-tcpsat@grc.nasa.gov Sat Jun 29 21:08:12 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09190 for ; Sat, 29 Jun 2002 21:08:11 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 52A3A640EB for ; Sat, 29 Jun 2002 21:08:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5U0pHYi025388 for tcpsat-outgoing; Sat, 29 Jun 2002 20:51:17 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5U0pGra025384 for ; Sat, 29 Jun 2002 20:51:16 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5U0pFSl019662 for ; Sat, 29 Jun 2002 20:51:15 -0400 (EDT) Received: from chat.ru (unknown [194.129.174.209]) by seraph2.grc.nasa.gov (Postfix) with SMTP id 76513C68D2 for ; Sat, 29 Jun 2002 20:51:14 -0400 (EDT) From: "Arcady 25106" To: Subject: Real ZOO web site, welcome! X-Priority: 3 X-Mailer: The Bat! (v1.54d) Date: Sun, 30 Jun 2002 04:54:05 +0400 Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-2" Status: R X-Status: N X-Warning: wfsvdwCjuf1qdvd1jry@27844 Message-Id: <20020630005114.76513C68D2@seraph2.grc.nasa.gov> Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk I got your email from ICQ, may be it will be interested?
The BEST zoo site on the @net!
Sex With Dogs
Horse Blow Jobs.
Snake Fuck.
REAL ANIMAL FUCKING!
100% HARDCORE!
rol.rape-sexy.com
unsub
Good luck.

From owner-tcpsat@grc.nasa.gov Sat Jun 29 21:52:45 2002 Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10381 for ; Sat, 29 Jun 2002 21:52:45 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 2BF0CC68F9 for ; Sat, 29 Jun 2002 21:53:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) id g5U1dUfD000613 for tcpsat-outgoing; Sat, 29 Jun 2002 21:39:30 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5U1dTra000605 for ; Sat, 29 Jun 2002 21:39:29 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id g5U1dTSl025081 for ; Sat, 29 Jun 2002 21:39:29 -0400 (EDT) Received: from terra (18.Red-80-33-10.pooles.rima-tde.net [80.33.10.18]) by seraph3.grc.nasa.gov (Postfix) with SMTP id C7D81640B9 for ; Sat, 29 Jun 2002 21:39:27 -0400 (EDT) From: "FORMACIÓN Y TECNOLOGÍA INFORMATICA" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 30 Jun 2002 03:33:22 Message-Id: <20020630013927.C7D81640B9@seraph3.grc.nasa.gov> Sender: owner-tcpsat@grc.nasa.gov Precedence: bulk INFORMACION Y RESERVAS TEL 902180066 Le ofrecemos nuestro sistema único de FORMACION sin desplazarse de su casa o empresa para aprender en pocas horas . CURSOS CON PROFESOR PRESENCIAL (Los profesores se deplazan a la empresa o domicilio) Módulos de 5 a 10 horas solamente. · .WINDOWS 95-98,MIL 2000 · .PROCESADOR TEXTOS "WORD" · .HOJA DE CALCULO "EXCEL" · .GESTION BASE DE DATOS "ACCESS" · .MICROSOFT PROJET · .INTERNET · .DISEÑO GRAFICO · .DISEÑO Y ADMN_PAG. WEB · .DISEÑO INDUSTRIAL Y TECNICO AUTOCAD-3D ESTUDIO · .CONTABILIDAD INFORMATIZADA - GESTION .COMERCIO ELECTRONICO · OTROS PROGRAMAS A CONSULTAR - CURSOS A MEDIDA Dirigido a: Academicos,profesionales liberales,Directivos, Jefes, licenciados, a aquellas personas que disponen de poco tiempo y desean una enseñanza personalizada y de alto rendimiento. De nuestra mano no lo dude podrá entrar en el mundo de la informática, haciendo que sus capacidades y aptitudes se multipliquen. Objetivos: Adquirir los conocimientos teóricos y prácticos necesarios para trabajar eficazmente. Durante el proceso de formación el alumno asimilará una filosofía de trabajo que le permitirá dominar las materias propuestas, con mucha motivación y disfrute de sus logros. .Al final de la formación se expedirá diploma acreditativo. Información y reserva de plazas en el teléfono 902180066 FORMACIÓN Y TECNOLOGÍA INFORMATICA