[40689] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: wanted: wireless magic tricks

daemon@ATHENA.MIT.EDU (Jon Mansey)
Thu Aug 16 14:12:26 2001

Mime-Version: 1.0
Message-Id: <a05100314b7a1bbb45c36@[192.168.2.69]>
In-Reply-To: <200108161800.OAA03425@guns.lerc.nasa.gov>
Date: Thu, 16 Aug 2001 11:10:37 -0700
To: nanog@merit.edu
From: Jon Mansey <jon@interpacket.net>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Errors-To: owner-nanog-outgoing@merit.edu


Then there are performance-enhancing proxies that terminate the TCP 
session, turn the data into UDP to send over sat, and then 
re-originate as TCP. This eliminates the adverse effects of 
bandwidth-delay over sat links.

See Mentat, FlashNetworks and Fourelle for PEPs.

This is of course doable over satellite, the problem probably is the 
"occasional-use" nature of the BW requirement, its likely to bump up 
the cost per Mb considerably over operating a full time connection.

jm




>  > Well, that is quite wonderful, but when I approached this problem
>>  with a collegue of mine over a sat link for a client that wasn't
>>  our experience and after considerable tweaking we ended up having
>>  to settle for less.
>>
>>  PS: got pointers to documents detailing the 500mbps over OC-12 sat link?
>>      email addr will do, as well, I'd love to find out what they did.
>
>Yep, sorry -- I should have included a pointer.  Try:
>
>     David E. Brooks, Craig Buffinton, Dave R. Beering, Arun Welch,
>     William D. Ivancic, Mike Zernic, Douglas J. Hoder. ACTS 118x
>     Final Report High Speed TCP Interoperability Testing, July 1999.
>     http://ctd.grc.nasa.gov/5610/publications/TM-1999-209272.pdf
>
>In the first couple of pages they show a results of 473 Mbps over an
>OC-12 circuit (a little less than line rate, but still quite good)
>using Solaris.  Results with other operating systems varied.  I seem
>to remember a presentation at the TCP Over Satellite IETF WG where
>over 500 Mbps was reported.
>
>My main point was that there is nothing wrong with the TCP
>*protocol* that makes it under-perform at large delay*bandwidth
>products.  The implementations are not necessarily up to the job in
>some cases, but the protocol is sound.
>
>(Further reference might be the TCPSAT WG's two RFCs: 2488 and 2760).
>
>allman
>
>
>---
>Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/


-- 

jon@interpacket.net                          Chief Science Officer
------------------------------------------------------------------
Verestar Networks, Inc.                    http://www.verestar.com
1901 Main St.                                   tel (310) 382 3300
Santa Monica, California 90405                  fax (310) 382 3310
------------------------------------------------------------------

home help back first fref pref prev next nref lref last post