On Tue, 16 Dec 1997, Fred Baker wrote:
> At 7:22 PM -0500 12/16/97, [email protected] wrote:
> >I'd like to explore some of the pros and cons of leos and geos re
> >latency--find out where things stand in the IETF on best practices in
[snip]
>
> But it does so at a cost - instead of the nice stable geosynchronous orbit,
> you've now got the message bouncing from satellite to satellite (which are
> at random distances from each other, continuously changing), traversing
> something resembling an arc around the earth, but with a significantly
> wider radius. It's therefore not going to be as little time as the
> corresponding terrestrial link would be. And the amount of time will be
> continuously varying - sometimes in a steady drift (what we geeks call "low
> frequency jitter"), and sometimes in a jump, as the next hop in a
> satellite-satellite route jumps from one bird to another (what we geeks
> call "high frequency jitter"). This continuous variation in delay means
> that TCP's window duration measurement algorithms will be constantly
> rubber-banding - and snapping - and it means that there can be packet
> reordering in the air - well, in the vacuum above the air.
Can someone clarify how fast the 'route' is going to change in a TCP (or
other) connection when GEO inter-satellite routing is involved? It would
seem that satellites move across the sky relatively fast, but still will
spend at least a few minutes above the horizon when they are the next hop
for each machine. Doesn't this mean that the number of individual TCP
connections that are severely affected by this will be relatively small,
or is there something I'm missing here? I guess what I'm asking whether
a connection is going to be changing relatively slowly (ie over a few
hundred seconds) or very rapidly (over a couple of seconds).
So, will your TCP implementation need to be *that* robust for LEO when
compared to that for GEO?
Also, does anyone know who is writing the inter-satellite routing
protocols and how to get on some sort of mailing-list about them (I'm
relatively new to this mailing-list so please forgive me if this is old
hat...)?
Thanks,
Sam
>
> So each has an advantage. GEOS is stable, and (comparitively) inexpensively
> has a very wide reach. If your application - voice, video, IP Multicast
> services, etc. - is hurt by jitter or packet reordering, GEOS is your
> friend. If your TCP implementation is VERY robust, and jitter and
> reordering are not issues to your application, then LEOS will in fact give
> you lower end to end latency; it will require a constellation of 300
> satellites to do it, though.
>
> And if you're one of the remaining 90% of the world, my advice is, try it
> and use the one that works best for you. You might decide either way, and
> make that decision for good reasons.
>
> If you want my honest opinion, in so many words, this whole debate in the
> press about GEOS vs LEOS, and delay, is not a technical debate. It has
> technical aspects, but those who understand them look at them and say "OK,
> so do this thing defined in <mumble>, and you'll be fine." It's really a
> marketing debate, and insofar as the press goes beyond its educational role
> to leading folks to make simplistic "me tarzan, you jane, this good, that
> bad" analysis, it has misled its readership and become the tool of one side
> or the other.
>
> You don't want to be in that position, right?
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Opportunity doesn't knock anymore; now it emails
>
>
>
****************************************
Sam Critchley
International Systems Engineer
UUNET
[email protected]
Tel: (+44) 1223 250444
****************************************
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:34 EST