RE: Selection of Scaling Factor

From owner-tcpsat@lerc.nasa.gov Wed Dec 1 06:30:39 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00636; Wed, 1 Dec 1999 06:30:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA26962 for tcpsat-outgoing; Wed, 1 Dec 1999 05:13:39 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA26952 for ; Wed, 1 Dec 1999 05:13:37 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA03736; Wed, 1 Dec 1999 05:13:35 -0500 (EST) Received: from qhars002.nortelnetworks.com(192.100.101.19) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003715; Wed, 1 Dec 99 05:13:07 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 1 Dec 1999 10:11:53 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 1 Dec 1999 10:11:52 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050CB0@zhard000.europe.nortel.com> From: "Julien Godard" To: "'gdo'" Cc: tcpsat@lerc.nasa.gov Subject: RE: Selection of Scaling Factor Date: Wed, 1 Dec 1999 10:11:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3BE4.7B722F2A" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF3BE4.7B722F2A Content-Type: text/plain The RFC1323 just explain a mecanism to increase the maximum value of the window. I think you are right, the scale factor will be 9x in your case. In the real world (real implementation :-), there is a strong impact of the TCP configuration you are using on the choice of the scale factor, especially from the socket size. I will explain what happend with a Linux 2.3 TCP. There some /proc files you can use to setup the default/maximum value of the send/recv socket buffer size. During the setup of the connection the sender will look at his socket buffer size and then compute the biggest scale factor possible (the TCP linux implementation roughly assume that half of the buffer will be use by TCP data, it may sound strange but it is due to the socket buffer structure) and send this factor in the first segment. The receiver does exactly the same with his own buffer and send his value to the sender. the smallest value between the sender and the receiver value will be used during the connection. Of course, if you don't specify a special value for the size of the socket buffer size, the default value will be used. Hope it may help Cheers julien > --Original Message----- > From: Greg Otto [SMTP:gdo@newf.com] > Sent: Tuesday, November 30, 1999 8:43 PM > To: tcpsat > Subject: Selection of Scaling Factor > > When using RFC1323 with Window scaling, how is the scale value selected? > My > guess is it is based on the smallest scale (left shifts) required for a > 64K > to be greater than the configured maximum. > > For example, if a WINDOW/HIWAT of 18,000,000 bytes is selected, then the > scale would be 512 (275 rounded up to the nearest multiple of 12) or a > left > shift of 9x. > > Is this correct or what is a resource which provides a better explanation? > > > Thanks, > GReg > > > Greg Otto voice: 713-995-4778 x102 > New Frontier Consulting, Inc. fax: 281-754-9170 > Houston, Texas > http://www.newf.com email: gdo@newf.com > ------_=_NextPart_001_01BF3BE4.7B722F2A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Selection of Scaling Factor

The RFC1323 just = explain a mecanism to increase the maximum value of the window.
I think you are = right, the scale factor will be 9x in your case.

In the real world = (real implementation :-), there is a strong impact of the TCP = configuration you are using on the choice of the scale factor, = especially from the socket size. I will explain what happend with a = Linux 2.3 TCP. There some /proc files you can use to setup the = default/maximum value of the send/recv socket buffer size. During the = setup of the connection the sender will look at his socket buffer size = and then compute the biggest scale factor possible (the TCP linux = implementation roughly assume that half of the buffer will be use by = TCP data, it may sound strange but it is due to the socket buffer = structure) and send this factor in the first segment. The receiver does = exactly the same with his own buffer and send his value to the sender. = the smallest value between the sender and the receiver value will be = used during the connection.

Of course, if you = don't specify a special value for the size of the socket buffer size, = the default value will be used. =

Hope it may = help

Cheers
julien

--Original Message-----

From:   Greg Otto [SMTP:gdo@newf.com]
Sent:   Tuesday, November 30, 1999 8:43 PM
To:     tcpsat
Subject:       = Selection of Scaling Factor

When using RFC1323 with Window = scaling, how is the scale value selected? My
guess is it is based on the smallest = scale (left shifts) required for a 64K
to be greater than the configured = maximum.

For example, if a WINDOW/HIWAT of = 18,000,000 bytes is selected, then the
scale would be 512 (275 rounded up to = the nearest multiple of 12) or a left
shift of 9x.

Is this correct or what is a resource = which provides a better explanation?

Thanks,
GReg

Greg = Otto           &n= bsp;           &n= bsp;    voice: 713-995-4778 x102
New Frontier Consulting, = Inc.        fax: = 281-754-9170
Houston, Texas
http://www.newf.com         &nb= sp;        email: = gdo@newf.com

------_=_NextPart_001_01BF3BE4.7B722F2A-- From owner-tcpsat@lerc.nasa.gov Wed Dec 1 10:51:26 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06837; Wed, 1 Dec 1999 10:51:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA12298 for tcpsat-outgoing; Wed, 1 Dec 1999 09:27:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA12277 for ; Wed, 1 Dec 1999 09:27:06 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA20796; Wed, 1 Dec 1999 09:27:05 -0500 (EST) Received: from ausmail.austin.ibm.com(192.35.232.19) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020770; Wed, 1 Dec 99 09:26:45 -0500 Received: from netmail2.austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97]) by ausmail.austin.ibm.com (8.9.1/8.8.5) with ESMTP id IAA14612 for ; Wed, 1 Dec 1999 08:28:06 -0600 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [9.53.150.76]) by netmail2.austin.ibm.com (8.8.5/8.8.5) with ESMTP id IAA18982; Wed, 1 Dec 1999 08:26:40 -0600 Received: (from marquard@localhost) by mojave.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id IAA08038; Wed, 1 Dec 1999 08:26:36 -0600 To: Cc: Subject: Re: Selection of Scaling Factor References: <000001bf3b73$7ee1d370$33012b0a@ottogd.newf.com> From: Dave Marquardt Date: 01 Dec 1999 08:26:34 -0600 In-Reply-To: "Greg Otto"'s message of "Tue, 30 Nov 1999 14:43:00 -0600" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk "Greg Otto" writes: > When using RFC1323 with Window scaling, how is the scale value selected? My > guess is it is based on the smallest scale (left shifts) required for a 64K > to be greater than the configured maximum. > > For example, if a WINDOW/HIWAT of 18,000,000 bytes is selected, then the > scale would be 512 (275 rounded up to the nearest multiple of 12) or a left > shift of 9x. > > Is this correct or what is a resource which provides a better explanation? Well, you've described a minimal behavior, and I suspect there's a lot of code that works as you describe. However, I know that Dave Borman has argued in the past that you might want to change the scale somewhat, perhaps to allow the window size to be increased by some factor. -Dave From owner-tcpsat@lerc.nasa.gov Sat Dec 4 21:13:33 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05122; Sat, 4 Dec 1999 21:13:32 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA16439 for tcpsat-outgoing; Sat, 4 Dec 1999 19:37:34 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA16434 for ; Sat, 4 Dec 1999 19:37:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA07164; Sat, 4 Dec 1999 19:37:33 -0500 (EST) Received: from acmey.gatech.edu(130.207.165.23) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007158; Sat, 4 Dec 99 19:37:11 -0500 Received: from localhost by acmey.gatech.edu (8.9.2/8.9.2) with ESMTP id TAA18453; Sat, 4 Dec 1999 19:37:09 -0500 (EST) Date: Sat, 4 Dec 1999 19:37:09 -0500 (EST) From: Frederick Myron Brown To: tcpsat@lerc.nasa.gov cc: gte307m@prism.gatech.edu Subject: Ka Band Transponders (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Hi- I am a student at Georgia Tech, doing some research on ka band transponders. Do you know of any companies where I can get information on Ka band transponders. Is the bandwidth at Ka band fixed at 1000 MHz no matter what manufacturer you choose or does the bandwidth of the transponder depend on the transponder you choose. The reason I need a lot of bandwidth is because I would like to deliver 20 ultra high definition movies(each movie at a rate of 250 Mbps= 5 Gbps) to movie theatres across the world. I am planning on using three geostationary satellites to cover three zones. Frederick Myron Brown Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gte307m@prism.gatech.edu From owner-tcpsat@lerc.nasa.gov Mon Dec 6 17:40:18 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13692; Mon, 6 Dec 1999 17:40:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA19126 for tcpsat-outgoing; Mon, 6 Dec 1999 16:09:42 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA19092 for ; Mon, 6 Dec 1999 16:09:40 -0500 (EST) From: osama.qadan@intelsat.int Received: by seraph3.lerc.nasa.gov; id QAA17801; Mon, 6 Dec 1999 16:09:39 -0500 (EST) Received: from iserv.intelsat.int(164.86.102.11) by seraph3.lerc.nasa.gov via smap (V5.0) id xma017774; Mon, 6 Dec 99 16:09:10 -0500 Received: from pc1.adm.intelsat.int ([164.86.36.12]) by iserv.intelsat.int (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-49113U1000L2S100) with ESMTP id AAA27027; Mon, 6 Dec 1999 16:13:03 -0500 Received: (from smap@localhost) by pc1.adm.intelsat.int (8.8.6 (PHNE_14041)/8.6.10) id QAA01996; Mon, 6 Dec 1999 16:09:08 -0500 (EST) X-Authentication-Warning: pc1.adm.intelsat.int: smap set sender to using -f Received: from admexc1b.adm.intelsat.int(164.86.33.18) by pc1 via smap (V2.1) id xma001932; Mon, 6 Dec 99 21:08:10 GMT Received: by admex1.adm.intelsat.int with Internet Mail Service (5.5.2448.0) id ; Mon, 6 Dec 1999 16:08:10 -0500 Message-ID: <490B4C213EC8D211851F00105A29CA5A030830B0@admex1.adm.intelsat.int> To: gte307m@prism.gatech.edu, tcpsat@lerc.nasa.gov Subject: RE: Ka Band Transponders (fwd) Date: Mon, 6 Dec 1999 16:08:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Fred, The bandwidth of the Ka-Band transponders is not equal to any fixed value. It really depends on the system you have, and different systems have different BW's per transponder (or beam), at least conceptually at this point, as there is no full Ka-Band system at this point except the retiring NASA ACT system. My suggestion to you is to look at the problem parameterically, and see what will be the QoS #'s to get with using a range of BW's. Now, which platform you use to deliver this becomes secondary. But your idea of using GEO's for this is good, as to use the broadcast nature of the satellites. ------------ Osama Qadan - INTELSAT BSP "You can never be too rich, too thin, or have too much bandwidth." (Anonymous) > -----Original Message----- > From: Frederick Myron Brown [mailto:gte307m@prism.gatech.edu] > Sent: Saturday, December 04, 1999 7:37 PM > To: tcpsat@lerc.nasa.gov > Cc: gte307m@prism.gatech.edu > Subject: Ka Band Transponders (fwd) > > > Hi- > > I am a student at Georgia Tech, doing some research on ka band > transponders. Do you know of any companies where I can get > information on > Ka band transponders. Is the bandwidth at Ka band fixed at > 1000 MHz no > matter what manufacturer you choose or does the bandwidth of the > transponder depend on the transponder you choose. > > The reason I need a lot of bandwidth is because I would like > to deliver 20 > ultra high definition movies(each movie at a rate of 250 > Mbps= 5 Gbps) to > movie theatres across the world. > > I am planning on using three geostationary satellites to cover three > zones. > > Frederick Myron Brown > Georgia Institute of Technology, Atlanta Georgia, 30332 > Email: gte307m@prism.gatech.edu > > From owner-tcpsat@lerc.nasa.gov Sat Dec 11 09:29:58 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26225; Sat, 11 Dec 1999 09:29:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA29061 for tcpsat-outgoing; Sat, 11 Dec 1999 08:16:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA28924; Sat, 11 Dec 1999 08:09:14 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA22702; Sat, 11 Dec 1999 08:09:13 -0500 (EST) Received: from taiba.ufc.br(192.160.50.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022671; Sat, 11 Dec 99 08:08:38 -0500 Received: from ufc.br ([200.19.179.142]) by taiba.ufc.br (8.9.1/8.9.1) with ESMTP id KAA22210; Sat, 11 Dec 1999 10:05:41 -0300 Message-ID: <38524ED5.2A9F47A4@ufc.br> Date: Sat, 11 Dec 1999 11:17:09 -0200 From: =?iso-8859-1?Q?Jos=E9?= Neuman de Souza X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: webrepl@cs.utk.edu, tfiw-announce@akalice.research.att.com, tcpsat@lerc.nasa.gov, tcp-impl@lerc.nasa.gov, tccc@ieee.org, end2end-interest@ISI.EDU, tci-announce@computer.org, prosoft@iro.umontreal.ca, xtp-relay@cs.concordia.ca, sigmedia@bellcore.com, itc@ieee.org, ieee_rtc_list@cs.tamu.edu, fokus-user@fokus.gmd.de, f-troup@CODEX.CIS.upenn.edu, ccrc@workin.wustl.edu, reres@laas.fr, performance@haven.epm.ornl.gov, osimcast@BBN.COM, modern-heuristics@uk.ac.mailbase, mobile-ip@tadpole.coms, isadsoc@fokus.gmd.de, ctc-members@tinac.com, cost237-transport@comp.lancs.ac.uk, comsoc-gicb@ieee.org, comsoc-chapters@ieee.org, cnom@maestro.bellcore.com, rboutaba@bbcr.uwaterloo.ca, Guy.Pujolle@prism.uvsq.fr, Dominique.Gaiti@lip6.fr, alg@comm.utoronto.ca, hafida@engsci.engga.uwo.ca, jean-pierre.hubaux@epfl.ch, kamoun@ensi.rnrt.tn, karmouch@elg.uottawa.ca, labetoul@eurecom.fr, mazum@research.bell-labs.com, giovanni@watson.ibm.com, Yves.Raynaud@irit.fr, jros@cs.up.ac.za, Roberto.Saracco@cselt.stet.it, stadler@ctr.columbia.edu, Ralph.Steinmetz@KOM.tu-darmstadt.de, wz@prosun.first.gmd.de, Simon.Znaty@enst-bretagne.fr, e.c.lupu@doc.ic.ac.uk, bettaz@hotmail.com, salah@rss.dl.nec.com Subject: MMNS'2000 - Latest CFP Content-Type: multipart/alternative; boundary="------------80130D01DB57617943AD4FDF" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk --------------80130D01DB57617943AD4FDF Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by taiba.ufc.br id KAA22210 Content-Transfer-Encoding: quoted-printable Third IFIP/IEEE International Conference on Management of Multimedia Networks and Services'2000- MMNS=922000 CALL FOR PAPERS (New Deadline) Fortaleza - Cear=E1, Brazil July 26-28, 2000 Organized by:Computer Network Research Group, Federal University of Cear=E1-UFC Co-sponsored by: IFIP Working Group 6.4 and 6.6 and IEEE (*) Communications Society (*) Pending web site : http://www.ufc.br/mmns2000 Scope : Today, the trend is towards providing telecommunications services and in particular multimedia services in the emerging broadband, multimedia and "super-highway" era. To offer reliable multimedia services, the service architecture should integrate the service with its management while the multimedia networks that are used to provide those services need also a certain level of control and management. Therefore management is requested at both the service and network levels. Integration is also of paramount importance to facilitate the overall management process. The third International Conference on Management of Multimedia Networks and Services follows the successful MMNS conference held in 1998 in Versaille (France). The conference objective is to bring together researchers working in all facets of network and service management applied to broadband networks and multimedia services. The conference will serve as a forum for the dissemination of state-of-the-art research, design, development, and implementation experiences. Topics of Special interest : Areas of interest include, but are not limited to: * Multimedia services specification, validation and management (e.g. Broadband VPN, Video on demand, tele-teaching, etc...) * Distributed management of multimedia services * Multimedia service and network management integration * Multimedia network management models and architectures * Mobility management in multimedia networks and systems * Resource management in broadband networks * Performance and Fault Management for broadband networks * Billing and Security for broadband networks * Integration of broadband network control and management * Management of multimedia wireless networks and services * Quality of service management * Policy-Driven Management * Standards Frameworks and Issues for broadband networks management: OSI, IETF, ITU-T, TINA, EURESCOM, ETSI, ATM-Forum, etc... * New software technologies for multimedia service and network management (Corba, JAVA, Mobile Agents) * AI techniques for network and service management (Intelligent Agents, Expert Systems, etc...) * Trials, case studies and experiences Important Information for Authors : Submissions should be written in English, double-spaced and no longer than 5,000 words. A separate cover sheet must be included which provides the following information: title of paper, authors' names and affiliations, contact author's name and address (both postal and electronic), a ten-line abstract, keywords, and submission area (from the list of relevant topics of interest). Please submit the paper electronically by ftp to ftp.pop-ce.rnp.br/pub/mmns2000 by mailto:mmns2000@ufc.br by mailto:neuman@ufc.br Electronic submissions should be in postscript format which may be compressed (using Unix compress) and uuencoded. In the case where electronic submission is impossible please send 4 hard copies of your paper by Postal mail to the following address : Address: Europe and Asia Jos=E9 Neuman de Souza Universidade Federal do Ceara Computer Science Department Campus do Pici, Bloco 910 60455-760 - Fortaleza-Ceara, Brazil Tel./Fax : +55 85 2889847 mailto:neuman@ufc.br America, Africa and Australia Raouf Boutaba University of Waterloo Department of Computer Science 200 University Avenue West Waterloo, Ontario N2L 3G1, Canada Phone (519) 888-4567 Fax (519) 885-1208 mailto:rboutaba@bbcr.uwaterloo.ca Authors of accepted papers will be asked to submit a camera-ready manuscript that will appear in the Conference proceedings published by Kluwer Academic Publishers. Also selected papers will be considered for publication as a special issue of the Journal of Network and System Management on Multimedia Networks and Services Management and in Interoperable Communication Networks journal. Important Dates : Today : send a message stating your intention to submit a paper or stating your general interest in the conference to mailto:mmns2000@ufc.br Electronic and hard copy paper submission deadline : January 30, 2000 Notification of acceptance : February 28, 2000 Camera-ready manuscripts due : March 31, 2000 General co-chair : Jos=E9 Neuman de Souza, Federal U. of Ceara, Brazil Raouf Boutaba, U. of Waterloo, Canada Program Committee : Salah Aidarous, NEC America, USA Mohamed Bettaz, Philadelphia University, Amman, Jordan Jean Pierre Claud=E9, U. of Versailles, France Dominique Gaiti, U. of Troyes, France Leon A. Garcia, U. of Toronto, Canada Abdelhakim Hafid, Bellcore, NJ, USA Jean-Pierre Hubaux, EPFL, Switzerland Farouk Kamoun, ENSI, Tunisia Ahmed Karmouch, U. of Ottawa, Canada Kenichi Kitami, NTT, Japan Jacques Labetoulle, Eurecom, France Subrata Mazumdar, Bell Laboratories, USA Jose N. de Souza, U. Fed. do Ceara, Brazil Giovanni Pacifici, IBM T.J.Watson Research Center, USA James W. Hong, POSTECH, Korea Guy Pujolle U. of Versailles, France Yves Raynaud, U. Paul Sabatier, France Jan Roos, U. of Pretoria, South Africa Izhak Rubin, UCLA, USA Roberto Saracco, CSELT, Italy Rolf Stadler, CTR/Columbia U., USA Ralph Steinmetz, GMD IPSI & Darmstadt U., Germany Yechiam Yemini, Columbia U., USA Wolfgang Zimmer, GMD FIRST, Germany Simon Znaty, ENST-Bretagne, France Joberto S. Martins, UNIFACS, Brazil Nicolas Georganas, University of Ottawa, Canada Emil Lupu, Imperial College, UK Douglas N. Zuckerman, BellCore, USA Michael A. Stanton, U. Fed. Fluminense, Brazil Ehab Al-Shaer, DePaul University, Chicago, IL, USA James W. Hong, POSTECH, Korea Andrew Campbell, Columbia University, USA Jose M. Nogueira, U. Fed. Minas Gerais, Brazil Joaquim Celestino J=FAnior, UECE, Cear=E1, Brazil --------------80130D01DB57617943AD4FDF Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by taiba.ufc.br id KAA22210 Content-Transfer-Encoding: quoted-printable Third IFIP/IEEE International Conference on Manag= ement of
Multimedia Networks and Services'2000- MMNS=92= 2000

&nbs= p; = ; = CALL FOR PAPERS (New Deadline)

Fortaleza - Ceará, Brazil
July 26-28, 2000

Organized by:Computer Network Research Group, Federal University of Ceará-UFC

Co-sponsored by: IFIP Working Group 6.4 and 6.6 and IEEE (*) Communica= tions Society

(*) Pending

web site : http://www.ufc.br/mm= ns2000

Scope :

Today, the trend is towards providing telecommunications services and in particular multimedia services in the emerging
broadband, multimedia and "super-highway" era. To offer reliable mult= imedia services, the service architecture should integrate
the service with its management while the multimedia networks that are used to provide those services need also a certain level
of control and management. Therefore management is requested at both the service and network levels. Integration is also of
paramount importance to facilitate the overall management process. The third International Conference on Management of
Multimedia Networks and Services follows the successful MMNS conferen= ce held in 1998 in Versaille (France). The
conference objective is to bring together researchers working in all facets of network and service management applied to
broadband networks and multimedia services. The conference will serve as a forum for the dissemination of state-of-the-art
research, design, development, and implementation experiences.

Topics of Special interest :

Areas of interest include, but are not limited to:

* Multimedia services specification, validation and management (e.g. Broadband VPN, Video on demand, tele-teaching, etc...)
   * Distributed management of multimedia services
   * Multimedia service and network management integration
   * Multimedia network management models and architectures
   * Mobility management in multimedia networks and systems
   * Resource management in broadband networks
   * Performance and Fault Management for broadband network= s
   * Billing and Security for broadband networks
   * Integration of broadband network control and managemen= t
   * Management of multimedia wireless networks and service= s
   * Quality of service management
   * Policy-Driven Management
   * Standards Frameworks and Issues for broadband networks management: OSI, IETF, ITU-T, TINA,      &n= bsp; EURESCOM,
ETSI, ATM-Forum, etc...
   * New software technologies for multimedia service and network management (Corba, JAVA, Mobile Agents)
   * AI techniques for network and service management (Inte= lligent Agents, Expert Systems, etc...)
   * Trials, case studies and experiences

Important Information for Authors :

Submissions should be written in English, double-spaced and no longer than 5,000 words. A separate cover sheet must be
included which provides the following information: title of paper, authors' names and affiliations, contact author's name and
address (both postal and electronic), a ten-line abstract, keywords, and submission area (from the list of relevant topics of
interest).

Please submit the paper electronically

by ftp to ftp.pop-ce.rnp.br/pub/mmns2000
by mailto:mmns2000@ufc.br
by mailto:neuman@ufc.br

Electronic submissions should be in postscript format which may be com= pressed (using Unix compress) and uuencoded. In the
case where electronic submission is impossible please send 4 hard cop= ies of your paper by Postal mail to the following address
:

Address: Europe and Asia

José Neuman de Souza
Universidade Federal do Ceara
Computer Science Department
Campus do Pici, Bloco 910
60455-760 - Fortaleza-Ceara, Brazil
Tel./Fax : +55 85 2889847
mailto:neuman@ufc.br

&nbs= p; America, Africa and Australia

Raouf Boutaba
University of Waterloo
Department of Computer Science
200 University Avenue West
Waterloo, Ontario N2L 3G1, Canada
Phone (519) 888-4567 Fax (519) 885-1208
mailto:rboutaba@bbcr.uw= aterloo.ca

Authors of accepted papers will be asked to submit a camera-ready manu= script that will appear in the Conference proceedings
published by Kluwer Academic Publishers. Also selected papers will be considered for publication as a special issue of the
Journal of Network and System Management on Multimedia Networks and Services Management and in Interoperable
Communication Networks journal.

Important Dates :

Today : send a message stating your intention to submit a paper or sta= ting your general interest in the conference to
mailto:mmns2000@ufc.br

Electronic and hard copy paper submission deadline :   =           January 30, 2000
Notification of acceptance :       = ;            =             &= nbsp;           &n= bsp;        February 28, 2000
Camera-ready manuscripts due :      &nb= sp;           &nbs= p;            = ;             March 31, 2000

General co-chair : José Neuman de Souza, Federal U. of Ceara, Brazil
&nb= sp; &nbs= p; Raouf Boutaba, U. of Waterloo, Canada

Program Committee :

Salah Aidarous, NEC America, USA
Mohamed Bettaz, Philadelphia University, Amman, Jordan
Jean Pierre Claudé, U. of Versailles, France
Dominique Gaiti, U. of Troyes, France
Leon A. Garcia, U. of Toronto, Canada
Abdelhakim Hafid, Bellcore, NJ, USA
Jean-Pierre Hubaux, EPFL, Switzerland
Farouk Kamoun, ENSI, Tunisia
Ahmed Karmouch, U. of Ottawa, Canada
Kenichi Kitami, NTT, Japan
Jacques Labetoulle, Eurecom, France
Subrata Mazumdar, Bell Laboratories, USA
Jose N. de Souza, U. Fed. do Ceara, Brazil
Giovanni Pacifici, IBM T.J.Watson Research Center, USA
James W. Hong, POSTECH, Korea
Guy Pujolle U. of Versailles, France
Yves Raynaud, U. Paul Sabatier, France
Jan Roos, U. of Pretoria, South Africa
Izhak Rubin, UCLA, USA
Roberto Saracco, CSELT, Italy
Rolf Stadler, CTR/Columbia U., USA
Ralph Steinmetz, GMD IPSI & Darmstadt U., Germany
Yechiam Yemini, Columbia U., USA
Wolfgang Zimmer, GMD FIRST, Germany
Simon Znaty, ENST-Bretagne, France
Joberto S. Martins, UNIFACS, Brazil
Nicolas Georganas, University of Ottawa, Canada
Emil Lupu, Imperial College, UK
Douglas N. Zuckerman, BellCore, USA
Michael A. Stanton, U. Fed. Fluminense, Brazil
Ehab Al-Shaer, DePaul University, Chicago, IL, USA
James W. Hong, POSTECH, Korea
Andrew Campbell, Columbia University, USA
Jose M. Nogueira, U. Fed. Minas Gerais, Brazil
Joaquim Celestino Júnior, UECE, Ceará, Brazil --------------80130D01DB57617943AD4FDF-- From owner-tcpsat@lerc.nasa.gov Sat Dec 18 05:27:11 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04115; Sat, 18 Dec 1999 05:27:10 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA09088 for tcpsat-outgoing; Sat, 18 Dec 1999 04:08:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA09084 for ; Sat, 18 Dec 1999 04:08:29 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA22846; Sat, 18 Dec 1999 04:08:29 -0500 (EST) Received: from relay.xlink.net(193.141.40.4) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022830; Sat, 18 Dec 99 04:07:57 -0500 Received: from nixe.ISAR.net (nixe.ISAR.net [212.14.65.1]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA03643; Sat, 18 Dec 1999 10:07:55 +0100 (MET) Received: (from root@localhost) by nixe.ISAR.net (8.9.3/8.9.3/ni-2.3) with UUCP id KAA02656; Sat, 18 Dec 1999 10:07:54 +0100 (CET) Received: from localhost (dieter@localhost) by m.isar.deolokai.m.lett.de (8.9.3/8.9.3) with ESMTP id QAA05365; Sat, 18 Dec 1999 16:48:33 GMT Date: Sat, 18 Dec 1999 16:48:33 +0000 (WET) From: "Dr. Dieter Pukatzki" X-Sender: dieter@molokai.m.isar.de To: Carlo Matarasso cc: tcpsat@grc.nasa.gov Subject: Re: Satellite friendly TCP code in C or C++ In-Reply-To: <37F33145.2A6F1BD0@dlr.de> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk did you find any suitable for Linux? Thanx in advance for any help. Dieter On Thu, 30 Sep 1999, Carlo Matarasso wrote: > Dear folks, > > I' m looking for the code in C or C++ of a satellite friendly version > of TCP. > Can somebody tell me where I can download (paying if necessary) it. > > Thank you in advance > > carlo > > -- > ------------------------------------------------------------------------------------------- > > DOTT. ING. CARLO MATARASSO > > carlo.matarasso@dlr.de > TEL. +49 8153 28 2848 > FAX +49 8153 28 2844 > > DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT > GERMAN AEROSPACE CENTER > www.dlr.de > POSTFACH 1116 > D - 82230 WESSLING - GERMANY > > ------------------------------------------------------------------------------------------- > > > From owner-tcpsat@lerc.nasa.gov Mon Dec 20 08:11:33 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02866; Mon, 20 Dec 1999 08:11:33 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA04923 for tcpsat-outgoing; Mon, 20 Dec 1999 06:39:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA04918 for ; Mon, 20 Dec 1999 06:39:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA14058; Mon, 20 Dec 1999 06:39:28 -0500 (EST) Received: from qhars001.nortelnetworks.com(192.100.101.18) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014050; Mon, 20 Dec 99 06:39:10 -0500 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars001.nortel.com; Mon, 20 Dec 1999 11:38:06 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 20 Dec 1999 11:38:04 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302050CFA@zhard000.europe.nortel.com> From: "Julien Godard" To: "'Dr. Dieter Pukatzki'" , Carlo Matarasso Cc: tcpsat@grc.nasa.gov Subject: RE: Satellite friendly TCP code in C or C++ Date: Mon, 20 Dec 1999 11:37:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF4ADE.AD2C5B86" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF4ADE.AD2C5B86 Content-Type: text/plain "Satellite friendly" TCP codes in C is available in all the recent linux kernel version (http://www.kernel.org) I don't know if you may found a way to only download the TCP part of it... cheers julien > -----Original Message----- > From: Dr. Dieter Pukatzki [SMTP:dieter@Lett.DE] > Sent: Saturday, December 18, 1999 4:49 PM > To: Carlo Matarasso > Cc: tcpsat@grc.nasa.gov > Subject: Re: Satellite friendly TCP code in C or C++ > > did you find any suitable for Linux? > Thanx in advance for any help. > Dieter > > On Thu, 30 Sep 1999, Carlo Matarasso wrote: > > > Dear folks, > > > > I' m looking for the code in C or C++ of a satellite friendly version > > of TCP. > > Can somebody tell me where I can download (paying if necessary) it. > > > > Thank you in advance > > > > carlo > > > > -- > > > -------------------------------------------------------------------------- > ----------------- > > > > DOTT. ING. CARLO MATARASSO > > > > carlo.matarasso@dlr.de > > TEL. +49 8153 28 2848 > > FAX +49 8153 28 2844 > > > > DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT > > GERMAN AEROSPACE CENTER > > www.dlr.de > > POSTFACH 1116 > > D - 82230 WESSLING - GERMANY > > > > > -------------------------------------------------------------------------- > ----------------- > > > > > > > ------_=_NextPart_001_01BF4ADE.AD2C5B86 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Satellite friendly TCP code in C or C++

"Satellite = friendly" TCP codes in C is available in all the recent linux = kernel version (http://www.kernel.org)
I don't know if you = may found a way to only download the TCP part of it...

cheers
julien

-----Original Message-----
From:   Dr. Dieter Pukatzki = [SMTP:dieter@Lett.DE]
Sent:   Saturday, December 18, 1999 4:49 PM
To:     Carlo Matarasso
Cc:     tcpsat@grc.nasa.gov
Subject:       = Re: Satellite friendly TCP code in C = or C++

did you find any suitable for = Linux?
Thanx in advance for any help.
Dieter

On Thu, 30 Sep 1999, Carlo Matarasso = wrote:

> Dear folks,
>
> I' m looking for the code in C = or C++ of a satellite friendly version
> of TCP.
> Can somebody tell me where I can = download (paying if necessary) it.
>
> Thank you in advance
>
> carlo
>
> --
> = ------------------------------------------------------------------------= -------------------
>
> DOTT. ING. CARLO = MATARASSO
>
> carlo.matarasso@dlr.de
> TEL. +49 8153 28 2848
> FAX +49 8153 28 = 2844
>
> DLR - DEUTSCHES ZENTRUM FUER = LUFT UND RAUMFAHRT
> GERMAN AEROSPACE CENTER
> www.dlr.de
> POSTFACH 1116
> D - 82230 WESSLING - = GERMANY
>
> = ------------------------------------------------------------------------= -------------------
>
>
>

------_=_NextPart_001_01BF4ADE.AD2C5B86-- From owner-tcpsat@lerc.nasa.gov Mon Dec 20 08:53:24 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03391; Mon, 20 Dec 1999 08:53:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA08303 for tcpsat-outgoing; Mon, 20 Dec 1999 07:51:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA08286 for ; Mon, 20 Dec 1999 07:51:29 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA18366; Mon, 20 Dec 1999 07:51:28 -0500 (EST) Received: from relay.xlink.net(193.141.40.4) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018265; Mon, 20 Dec 99 07:50:49 -0500 Received: from nixe.ISAR.net (nixe.ISAR.net [212.14.65.1]) by relay.xlink.net (8.9.3/8.8.7) with ESMTP id NAA05526; Mon, 20 Dec 1999 13:50:35 +0100 (MET) Received: (from root@localhost) by nixe.ISAR.net (8.9.3/8.9.3/ni-2.3) with UUCP id NAA03013; Mon, 20 Dec 1999 13:50:31 +0100 (CET) Received: from localhost (dieter@localhost) by lett.deolokai.m.lett.de (8.9.3/8.9.3) with ESMTP id OAA06663; Mon, 20 Dec 1999 14:26:35 GMT Date: Mon, 20 Dec 1999 14:26:33 +0000 (WET) From: "Dr. Dieter Pukatzki" To: Julien Godard cc: Carlo Matarasso , tcpsat@grc.nasa.gov, klaus@webforum.de, Johannes Schumann Subject: RE: Satellite friendly TCP code in C or C++ In-Reply-To: <0979C0AA41FED111BCFB00204804FC1302050CFA@zhard000.europe.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Julien, Thanx a million. I will let you know what comes out of it. If we cannot download it, I will be back earlier Dieter On Mon, 20 Dec 1999, Julien Godard wrote: > "Satellite friendly" TCP codes in C is available in all the recent linux > kernel version (http://www.kernel.org) > I don't know if you may found a way to only download the TCP part of it... > > cheers > julien > > > -----Original Message----- > > From: Dr. Dieter Pukatzki [SMTP:dieter@Lett.DE] > > Sent: Saturday, December 18, 1999 4:49 PM > > To: Carlo Matarasso > > Cc: tcpsat@grc.nasa.gov > > Subject: Re: Satellite friendly TCP code in C or C++ > > > > did you find any suitable for Linux? > > Thanx in advance for any help. > > Dieter > > > > On Thu, 30 Sep 1999, Carlo Matarasso wrote: > > > > > Dear folks, > > > > > > I' m looking for the code in C or C++ of a satellite friendly version > > > of TCP. > > > Can somebody tell me where I can download (paying if necessary) it. > > > > > > Thank you in advance > > > > > > carlo > > > > > > -- > > > > > -------------------------------------------------------------------------- > > ----------------- > > > > > > DOTT. ING. CARLO MATARASSO > > > > > > carlo.matarasso@dlr.de > > > TEL. +49 8153 28 2848 > > > FAX +49 8153 28 2844 > > > > > > DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT > > > GERMAN AEROSPACE CENTER > > > www.dlr.de > > > POSTFACH 1116 > > > D - 82230 WESSLING - GERMANY > > > > > > > > -------------------------------------------------------------------------- > > ----------------- > > > > > > > > > > > > From owner-tcpsat@lerc.nasa.gov Thu Dec 23 07:23:14 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20934; Thu, 23 Dec 1999 07:23:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA12667 for tcpsat-outgoing; Thu, 23 Dec 1999 06:01:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA12657 for ; Thu, 23 Dec 1999 06:01:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA09073; Thu, 23 Dec 1999 06:01:42 -0500 (EST) Received: from smtp2-out.minitel.net(193.252.91.17) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009064; Thu, 23 Dec 99 06:01:24 -0500 Received: from gmailint6 (gmailint6.globalmail.net [192.168.220.55]) by smtp2-out.minitel.net (Postfix) with SMTP id EE9F55740B for ; Thu, 23 Dec 1999 12:01:14 +0100 (MET) Received: from 139.100.0.30 by voila.fr with HTTP; Thu, 23 Dec 1999 12:01:14 +0100 From: "bc azur" Reply-To: azurbc@voila.fr To: Subject: RFC implementations MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: <19991223110114.EE9F55740B@smtp2-out.minitel.net> Date: Thu, 23 Dec 1999 12:01:14 +0100 (MET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id GAA12660 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Dear colleagues, I have recently been involved in enhancing TCP for high speed satellite communications and I would like to know the state of art in the field of RFC implementations. I know that there have been implementations of RFC 1323 and 2018 and 2001. Does any one have some view graphs showing the real benefits of these RFC implementations and the conditions it has been realized. For 1323 it's immediate but for the other RFC it's difficult to quantify. Besides these RFC's what are those likely to be normalized. I am actually working for a small company specialized in protocol evaluation. Many thanks bc From owner-tcpsat@lerc.nasa.gov Thu Dec 23 14:45:47 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02081; Thu, 23 Dec 1999 14:45:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA19967 for tcpsat-outgoing; Thu, 23 Dec 1999 13:21:19 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA19935 for ; Thu, 23 Dec 1999 13:21:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA15171; Thu, 23 Dec 1999 13:21:16 -0500 (EST) Received: from smtp2-out.minitel.net(193.252.91.17) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015109; Thu, 23 Dec 99 13:20:36 -0500 Received: from gmailint4 (gmailint4.globalmail.net [192.168.220.53]) by smtp2-out.minitel.net (Postfix) with SMTP id DA046573E8; Thu, 23 Dec 1999 19:20:26 +0100 (MET) Received: from 139.100.0.30 by voila.fr with HTTP; Thu, 23 Dec 1999 19:20:26 +0100 From: "bc azur" Reply-To: azurbc@voila.fr To: , Cc: Subject: Re: RE: RFC implementations MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: <19991223182026.DA046573E8@smtp2-out.minitel.net> Date: Thu, 23 Dec 1999 19:20:26 +0100 (MET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id NAA19951 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit I know actually the performance of 1323 but my question is as follows: does any one have done some tests on RFC 2001 and 2018 specifically to evaluate the gain or are there publications on this topic comparing the different enhancement and their evaluations. For 1323 I know this formula and I have tested window size variation. >It's actually very simple to explain how RFC1323 helps. It can be >summarized as: > > WINDOW SIZE >Throughput = -------------- upto the actual bandwidth minus proto oh > ROUNDTRIP TIME > >I have been able to push data at 98+% of available theoretical bandwidth >over high >delay. > >GReg > >-----Original Message----- >From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On >Behalf Of bc azur >Sent: Thursday, December 23, 1999 5:01 AM >To: tcpsat@grc.nasa.gov >Subject: RFC implementations > > >Dear colleagues, >I have recently been involved in enhancing TCP for high speed satellite >communications and I would like to know the state of art in the field >of RFC implementations. I know that there have been implementations of >RFC 1323 and 2018 and 2001. Does any one have some view graphs showing >the real benefits of these RFC implementations and the conditions it has > been realized. For 1323 it's immediate but for the other RFC it's >difficult to quantify. Besides these RFC's what are those likely to be >normalized. I am actually working for a small company specialized in >protocol evaluation. >Many thanks >bc > > > > From owner-tcpsat@lerc.nasa.gov Tue Dec 28 14:04:39 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03861; Tue, 28 Dec 1999 14:04:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA05125 for tcpsat-outgoing; Tue, 28 Dec 1999 12:31:10 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA05119 for ; Tue, 28 Dec 1999 12:31:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA06055; Tue, 28 Dec 1999 12:31:07 -0500 (EST) Received: from tc079.bbn.com(128.33.238.79) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006045; Tue, 28 Dec 99 12:31:04 -0500 Received: from lawyers (IDENT:mallman@localhost [127.0.0.1]) by lawyers.lerc.nasa.gov (8.9.3/8.9.3) with ESMTP id JAA03157; Tue, 28 Dec 1999 09:27:51 -0500 Message-Id: <199912281427.JAA03157@lawyers.lerc.nasa.gov> To: azurbc@voila.fr From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: tcpsat@grc.nasa.gov Subject: Re: RFC implementations Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Thunderstruck Date: Tue, 28 Dec 1999 09:27:51 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > I know that there have been implementations of RFC 1323 and 2018 > and 2001. Does any one have some view graphs showing the real > benefits of these RFC implementations and the conditions it has > been realized. RFC 1323 provides larger windows that allow TCP to fully utilize a long-delay pipe. RFC 2018 provides the information about exactly which segments have arrived and which have not. This allows a TCP sender to obey congestion signals, but not back off to a 1 segment window when multiple segments are lost. RFC 2001 is obsolete. RFC 2581 is the current version. That RFC really provides no performance gain to a single flow (OK, fast retransmit and fast recovery are gains over taking timeouts). Rather, that document outlines the congestion control mechanisms that everyone must follow so the network does not collapse, causing everyone to get little or no performance. The two documents produced by the tcpsat WG have more verbose descriptions and many pointers to the literature. I suggest reading RFC 2488 and draft-ietf-tcpsat-res-issues-12.txt (currently in the RFC Editor's queue). Happy Holidays! allman --- http://roland.grc.nasa.gov/~mallman/