>>PS. Fooey on NASA for not predicting these problems when they turned on
>>their satellite 155mbps net -- the response-window ack-delay is obvious to
>>the most casual observer....
>30 ms delay can cause bottlenecks, but only on *really* fat pipes.
>Geostationary satellites, by contrast, have round-trip delays of over
>Teledesic's philosophy is to be to be seamless compatible with
>terrestrial fiber-based networks. Since protocols and applications are
>developed for terrestrial networks, any and all such applications will
>work correctly over Teledesic. Our strategy is for the application not
>to know it's going over a satellite.
>(A curious fact: since light travels faster through a vacuum (c) than
>through glass (0.6c), long connections over Teledesic will actually have
>lower-latency than "more direct" connections via terrestrial fiber.)
>BTW, NASA (along with everyone else) knew about TCP latency problems;
>the article was not well reported. RFC 1323 even explains how to use a
>larger window. It's an interesting point, though, that those options
>are not widely implemented today, because people design for the
>terrestrial environment. By extension, HTTP 1.1 may fix the latency
>issue of HTTP over satellites, but do businesses really want to bet that
>the next killer application, or the one after that, will tolerate
>non-standard network connections?
>I've appended the Teledesic white paper on this issue (which I wrote) to
>the end of the message.
> - dan
>Dan Kohn <firstname.lastname@example.org>
>+1-206-803-1411 (voice) 803-1404 (fax)
This is why I posted this, I've been waiting for your response. thanks!
Also, in the "my html is better than you html dept. Can we come up with a
29 frame animated .GIF for the Gigaverse Web site, "Now using HTTP 1.1,
optimized for satellite transmission."
-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Experience means knowing the unknown... -=-=-=-=-=-=-= -=-=-=-=-=-=-=-=- email@example.com