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
> 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
Thanks.
[..]
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.
[..]
FWIW, I wasn't bashing TCP, I was reporting experience data.
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
Christian Kuhtz <ck@arch.bellsouth.net> writes:
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.
FWIW, I wasn't bashing TCP, I was reporting experience data.
You can find details of tuning TCP for different operating systems
courtesy of the Pittsburgh Supercomputing Center at:
http://www.psc.edu/networking/perf_tune.html
-tex