[email protected] wrote :
> [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
>>this area, where the satellite people would like to take the issue, if
>>they're trying to go further than refining the state of the
>>specifications, and what kinds of changes are being made and might need
>>to be made in infrastructure equipment (like routers) to better
>>accomodate bandwidth from the sky.
>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.
In addition, I understand that some LEO systems could involve additional
delay due to on-board processing and switching between satellites. I have
not seen reliable estimates of this delay but I understand that it could be
significant taking into consideration that a typical message may need to
pass through several LEO satellites, each contributing some processing
delay.
If anyone has definitive knowledge in this area I would appreciate it.
Thanks.
>So each has an advantage..... (text deleted) 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.
I fully concur.
************************************************
Hany K. Eldeib, Ph.D.
Principal Engineer, Advanced Programs & Systems
INTELSAT
Washington, D.C., USA
Phone: 202-944-6949
Fax: 202-944-8211
Internet: [email protected]
INTELSAT on WWW: http://www.intelsat.int
************************************************
-------------
Original Text
>From FRED@SMTPGATE (Fred Baker) {[email protected]}, on 16/12/97 8:38 PM:
To: CBONAFIE@SMTPGATE {[email protected]}
Cc: MASCHRAD@SMTPGATE {[email protected]}, TCP-OVER@SMTPGATE
(tcp-over-satellite) {[email protected]}
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
>this area, where the satellite people would like to take the issue, if
>they're trying to go further than refining the state of the
>specifications, and what kinds of changes are being made and might need
>to be made in infrastructure equipment (like routers) to better
>accomodate bandwidth from the sky.
I think you'll find that the situation isn't as clear cut as either side of
that debate would like to make it sound. Like many things in engineering,
there are trade-offs, and things work differently depending on how you
trade them off.
First, let's talk about GEOS. GeoSynchonous Orbit satellites are 22,600
miles up in the sky. Multiply by the speed of light, and you get something
on the order of 1/8 of a second. So a message which is sent via a
geosynchronous satellite takes 1/8 second to go to the bird, and 1/8 of a
second to come back down - in addition to whatever time the message itself
would take at whatever speed you sent it (bits in message divided by bits
per second). Oh, you wanted an acknowledge? That's two messages, something
on the order of half a second of fixed propagation delay. TCP will transfer
data at one window per round trip, a round trip is on the order of half a
second, and slow start makes GEOS look bad. All of this is true.
There are some fixes. TCP "spoof" engines that terminate the TCP session on
either side of the satellite link can be used to make the "round trip" in
question only account for terrestrial time. This means that end to end
security (IPSEC) and some end to end assumptions are violated - but heck,
in a world full of NATs, that's not news. TCP Large Windows (implemented in
Microsoft Window s '98, I am told) also helps for long-lived sessions, and
with HTTP 1.1 and 2.0, sessions are growing in length. So TCP does in fact
work over GEOS, and the latency issues can be mitigated somewhat. Fifteen
years of experience in the Internet says it works just fine, there's just
some considerations you need to make.
Now, let's talk about LEOS. Low Earth Orbit means just that - on the order
of a few hundred to 1000 miles up. Multiply by the speed of light, and you
get some amount of time, but not all that much compared to 22,600 miles. So
you do the same calculation, and the base TCP session will indeed go more
rapidly at one window per round trip. This is good, and I don't think
you'll find anyone that says it's not true.
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.
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
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:34 EST