Hello List,
I would like to make a point that seems to be being overlooked in all these
discussions of TCP over SAT.
When you use Netscape to open a web page with 8 GIF images on it, each one
of those GIFs opens a new parallel socket to be downloaded. All of a sudden
you have 35Kbytes/sec times 8 gifs for example, 280KBytes/sec or 2.2Mbps.
This may be a contrived example, and slow start would not even kick in on
such a small file as a web gif, but the point is that these "limitations"
are purely restricted to a per-TCP-socket basis. In the Unix world,
parallel tasks are everyday occurrences. It wouldn't take much to produce a
file transfer protocol which opens multiple parallel sockets for high
throughput over long fat pipes.
Next time you get the chance to browse on the end of a sat connection, try
opening multiple downloads of the same file on Netscape. You'll see each
download max out at between 15K and 30Kbytes/sec, depending on the RTT from
you to the web server, but you should be able to saturate the pipe with
just one PC.
As a satellite ISP, we actually like this property of a per-socket "limit"
on throughput. Our customers' customers are mostly on 28k-56k modems, so
they will NEVER see the kind of speed limits we are talking about. The
cumulative bandwidth of 100s of modems all sucking web pages through
multiple sockets can easily fill an E1 or 8Mb pipe. If a customer has a
particular requirement to go faster per socket, I point them to the various
tricks and tweaks available for his stack to open up the window. I can
download at 120Kbytes/sec on my Mac opened up from the normal 16K to a
64KByte window.
Moving to the bandwidth issue, right now we are testing 16QAM modulation
which will allow us to put up a T3 (45Mbps) into 18MHz of transponder.
Just some real-world input to the discussion.
Jon.
>At 12:14 16.06.98 -0400, you wrote:
>>
>> This is really sketchy. I am basically fishing here. I didn't find
>>anything at the IETF web site...
>>
>> My management has heard (nth-hand) that there is some kind of
>>statement or
>>draft associated with the IETF that says that either IP or TCP will not work
>>over satellite links with delays longer than 125 milliseconds. Has anyone
>>heard of this or is aware of where this may have come from? It sounds like
>>propaganda from LEO proponents but if there is any technical merit behind
>>such
>>an assertion I definately want to see it...
>>
>>
>>John Border
>>Hughes Network Systems
>>[email protected]
>>
>>
>
>Hello to all of you out there,
>
>in fact, everybody who has already done TCP/IP satellite traffic via GEO
>satellites knows that it works properly. But I have to point out that I miss
>relevant data in all of your mails, i.e. how is your through-put rate using
>which type of carriers on a satellite. The position and stability of the GEO
>device is not important anyway, we just need a repeater up there. We have
>achieved with 2 Mbps outbound and 64kbps inbound via a 1.2 meter VSAT and a
>3.7 meter Hub on EUTELSAT a maximum of 35 kByte/s using normal TCP/IP, but
>we think it is much to slow.
>
>Here at GMD, a national German Research institute for Information
>Technology, we have 18 MHz of satellite capacity for research and
>development to play around with. At the moment we would like to increase the
>speed by using the Win98 version with the RFC 1323 components. Does anybody
>have some ideas how to implement this 100% properly ?
>
>Thanks in advance,
>
>Andreas Voigt
>GMD - SatNET
>Satellite Laboratories
>
>--
>
>E-Mail: [email protected]
>
>Tel: +49 22 41 14 10 55
>Fax: +49 22 41 14 21 36
>
>Address:
>
>GMD
>z. H. Herrn Andreas Voigt
>Dep. SatNET
>Schlo� Birlinghoven
>
>53754 Sankt Augustin
[email protected] Chief Science Officer
------------------------------------------------------------------
InterPacket Group, Inc. http://www.interpacket.net
501 Santa Monica Blvd, #702 tel (310) 899-8920
Santa Monica, California 90401 fax (310) 656-8326
------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:43 EST