Hi-
I'm a System Engineer for the Scientific Atlanta VSAT product line
("SkyRelay"). We've been pumping bits over Geo-sync, Ku-Band
satellites into many corners of the earth for the past 12 years. We
build, install, operate and maintain 1000's VSATs dozens of networks ar
ound the world. We don't own any satellites, so I'm not worried abo
ut speaking freely... Also, many of our networks make hybrid conn
ections with terrestrial....
So, all a
dv
ertising aside, I couldn't resist inserting a few words in the is dial
og....;)
I can say
q
uite honestly that much of the undeveloped world relies on the compara
tive high reliability of satellite circuits. In general, Ku-band Geo
sync satellite circuits are designed with 99.5% availabilit
y or better, assuming operational BERs around 10e-7. (For that matter
, this spec frequently out-performs some terrestrial circuits in
the developed world.) FEC makes BER curves steep, so random bit
errors are uncommon. The physical link is either working at a low er
ror rate, or "lost lock" in a totally degraded state. I should also
mention that many VSAT networks use a multiple access return path
that are subject to collisions. The L2 protocols recover packets los
t in collisions, but increase path delay.
IMHO, Geo
sy
nc satellite circuits at Ku/Ka-band can be characterized something l
ike this:
*Most
of
the time: excellent BER...10e-7 because of FEC
*A few h
ours per year: Rain Fade (link gone!) 1-30 minutes/event
*A few m
inutes a day, a few days twice per year: sun outage
*Random
terrorism: Xpol interference from analog video (SNG) trucks
*Bad Luc
k: broken gear with and MTTR << 24 hours
*Collisi
ons: multiple access return path contention hazard
That said
,
I also can't resist a comment on "spoofing:" it's essential!!
! In my experience there's 2 major problems with TCP/IP (as we know
it today) in the geo-sync delay environment:
1) a win
dowing speed limit between 200-400kbps (many variables)
2) too m
any acknowledgments in the return path
Unlike terr
estrial, satellite time is big $$$$$, so it just doesn't make financ
ial cents to blast away with an excess number of acks in a multiple ac
cess (collision prone) return path, or even in a packet multiplexed
outbound path.
Hope this
h
elps,
Regards,
-Tom Saam
_______
__
_____________________ Reply Separator _________________________________
Subject: Re: Two concerns
Author: [email protected] at PMDF
Date: 3/30/98 2:10 PM
Agreed.
Could not concur more strongly; and can't add anything to your
discourse below.
It will be a non-trivial, but important task, to have this WG
produce an appropriate document on the subject.
Unfortunately, I can't recall having a cozy relationship with
any vendor or hardware/software provider in my career.
Let me know if I can help.....
(meanwhile .... the sleeper returns to his cyber-nap)
Regards!
Tim
> No disagreement that we need to specify a range of assumed minimum
> underlying space link BER requirements. But the numbers should be based on
> practical experience and achievable technical expectations, not some
> marketing guy's mandate. I'll bet that there are more than a few satellite
> providers out there who are biting their tongues as we debate this issue,
> unable to chime-in because to do so could expose a weak flank that might
> deter potential investors and steer them towards fiber.
>
Received: from 192.168.190.1 by ALPHA.CORP.SCIATL.COM (PMDF V4.3-13 #7203)
id <[email protected]>; Mon,
30 Mar 1998 17:23:45 -0500 (EST)
Received: from [129.4.53.140] by gatekeeper.sciatl.com for
<[email protected]> id RAA04531; Mon Mar 30 17:30:27 1998
Received: by achtung.sp.trw.com (4.1/SMI-4.1) id AA02753; Mon,
30 Mar 98 11:04:08 PST
Received: from linux.silkroad.com ([198.133.151.18]) by achtung (4.1/SMI-4.1)
id AA02748; Mon, 30 Mar 98 11:04:03 PST
Received: (from bass@localhost) by linux.silkroad.com (8.7.3/)
id OAA07691; Mon, 30 Mar 1998 14:10:05 -0500
Date: Mon, 30 Mar 1998 14:10:05 -0500 (EST)
From: Tim Bass <[email protected]>
Subject: Re: Two concerns
In-reply-to: <[email protected]> from
"Adrian J. Hooke" at Mar 30, 98 10:38:49 am
Sender: [email protected]
Message-id: <[email protected]>
X-Envelope-to: "Saam, Tom%SA-MEL-420"@ccmail.corp.sciatl.com
MIME-version: 1.0
X-Mailer: ELM [version 2.4 PL24 PGP2]
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Precedence: bulk
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST