Dear Colleagues,
In response to the person who had a bad experience with a satellite link,
I'd like to second the comment of our distinguished colleague, Matt Halsey
at INTELSAT, about how to easily avoid noisy links in building -Internet by
Satellite- with a little addendum. Tests and lots of live service provision
examples have show it really works great if one is careful and lots of
carriers of all sizes are learning how to do it.
The way you get the spectacular error-free links in satellites which he
mentioned, is simply by doing <normal> good engineering planning for TCP on
the ground when accessing the satellites: be they geostationary or any
other type. (We are talking about <Near Earth> applications of TCP, not
deep space data transport in other protocols, here, because these
conditions are specialized to the delays found in this presently relevant
discussion of geostationary Earth orbiting satellites and their
interconnection to terrestrial links). You are really just connecting one
quality medium to another comparable quality medium, and good engineering
is all that is required for error free service! Noisy satellite links come
from bad link planning and/or poor earth station implementation & link
operation, not TCP. Get a super clean satellite link, compress your data
like a smart modern carrier, and the percieved barriers to having excellent
TCP over satellite start to quickly disappear. It's really true...after 30
odd years of commerical satellite operations, pioneered by INTELSAT-which
set standards for virtually everything you can think of in satellites, the
satellite industry worldwide has tremendous accuracy built physically into
the birds and their operations, in their error-free service provision of
services to users on the ground, on ships at sea, in airplanes, or on near
Earth space stations accessing the geostationary satellites, particularly.
We suspect that one of the biggest and yet largely unaddressed problems
stems from an overloading of the satellite links and in foolishly not using
the latest compression of the multiplexed, individual, irregular
application streams flowing concurrently inside of the satellite link, so
as to lower that link throughput loading. Thus the earliest issue, we feel
at BEEDNET is to be not magnifying an avoidable problem which in essence
doesn't really have to exist. Real time link loading capabilities of TCP
Over Satellite is significantly a question of managing the instantaneous
elasticity of the link to making automatically the almost infinitely
variable and yet immediate dynamic changes in the combined quantities
interstitial separation of and hinderance-free simultaneous carriage of
user data and of necessary signalling data, so that necessary carriage of
even the smallest quantity of any one kind never impinges on the maximal,
free flow of the other, on demand (which is increasingly unplannable), and
within the confines of any other postulated and otherwise stipulated
requirements for prioritization of application level derived services, such
as for voice and video, such as would be built into a link. We feel that
SOLVING THIS is critical to 'GETTING CONNECTED' with <locally affordable
services> the 3/4 of the planet Earth called "developing countries" by OECD
organizations: most of which don't have enough other telecommunications
infrastructure, like international cable trunks...which never reach very
far inland, anyway.
The problems some people think of concerning noise in satellite links,
when they happen, come from some inexperienced ground station operators who
are not using the satellites in the sky properly for the admittedly
specialized TCP environment. Playing a piano well and playing a harpsichord
well each requires different fingering techniques & a unique way of
listening and thinking about the music one plays, as well as an intimate
understanding of the differences between striking and plucking, though both
instruments have keys and many people can play both of them quite badly!
Further, even with the above, playing a pipe organ masterfully requires
further understanding about breathing and voicing, as well. Similarly,
different telecommunications environments & applications require different
qualities or grades of underlying transmission service to work well to
deliver the derived service provision standards you expect and require. All
engineering has this basic truth. Yet it is very much in the flexibility of
TCP that lies the greatest possibilities for its use over satellites in
reaching to the most difficult to otherwise connect parts of the world and
in provisioning those regions with these critically "locally affordable"
quality telecoms services for sustainable regional development. Sloppy
engineering on the ground will get you sloppy quality of service and
unhappy users, no matter what your profession. The problem is not in the
satellites; the problem lies with the occasional 'know-it-all' idiot earth
station operator on the ground who thinks that TCP is 'just like any other
data'. (It's time for such turkeys like that to quietly retire from the
industry (immediately, whatever their age) and leave the satellite business
to new experts who understand and study constantly the new engineering
requirements! Hence, this forum!)
The true beauty of building satellite links versus using cable connections
is that you can effectively ->Specify the Quality of Derived Service<-
which you offer to a customer or end user of your satellite link, by
properly engineering the relative grade of the underlying transmission
service medium used to achieve the satellite backbone you use for carrying
your applications, such as Email, WWW, Voice, Fax, or Video. This way 'you
get what you pay for' and never waste money or transmission capabilities
such as by over-provisioning a half circuit in a cable for the 'light side'
of asymetrical circuits for Internet. In cable you have very few choices.
The happy situation in satellites is that you build exactly what you need
and pay for what you want & ->only what you want...whether your link is
large or small. You can go anywhere with your satellite link...even out in
'God's Country' where there is no cable(& no hope of one!)...which, by the
way, is where someone lives and calls it "home" in their own language.
Power and bandwidth thus combine in a satellite environment to give you a
relative 'robustness' in your link to problems of all kinds. You chose what
you want and adjust your ingredients accordingly. That's your data's
'health insurance', too, and it's what the "link budget" calculation is all
about in planning and provisioning a satellite circuit for error free
operations, in each direction, with each half circuit being individually
planned in the context of the whole 'connection'. Creatively use really
good, modern gear at each end and provision it <properly & adequitely> with
power and bandwidth and a tiny BER through each of your antennas, be they
small VSATs or much larger antennas or a combination of both, and you will
have comparable to the best fibre connections...and never have to worry
about some idiot with a backhoe digger somewhere breaking your precious
cable lifeline. Internet over satellite works great if you correctly
engineer a High QOS Environment with really low BER...which is what any
professional should be doing, anyway. Who wants errors?
As a comparison, imagine you had a section of fibre with a flaw in it(not
rare at amaturely done splices, unfortunately) or had a heavy dump truck
running occasionally over a now slightly damaged length of coaxial cable->
buried in a crushed plastic tube (such as under a sidewalk) at a building
construction site. Every passing of the truck over the cable would induce
errors for all users of the Internet link, in question, being carried
inside of that cable; and all the problems of error correction and slow
start would be potentially induced, most especially if the link was
heavilly loaded with traffic, which will cause the system to drop packets
as it struggles 'to breathe'. [It goes without saying that most people's
internet connections are considered "too slow" and are quite full of
traffic at peak times in the local working day.] In this situation, these
noise and error related problems would show up even if the local user's
mouse click addressed a server half way around the planet...and show up
equally clearly in the other direction, globally, to the unsuspecting mouse
user...a half a world away, trying to tap into a server down the
street...through this damaged cable, which isn't very healthy even in the
middle of the night, locally.
The relative various compression rates of your different applications
riding transparently and effectively statistically multiplexed inside of
the general TCP/UDP/IP envelope or environment as measured by the overall
composite compression of the underlying Interent trunk capacity at
entry/exit to the satellite link, and interfaced with the speed of real
network access throughput (not maximum rated port speed) beyond the network
boundary/interface to your satellite link combine to give you real
operating economies inside of the 'all up' or 'end-to-end link' which
stretches over the satellite and then into cable or fibre on each end,
probably. The "weakest link" rule does indeed 'rule'. However, with a clean
satellite link, Point-To-Point Tunneling, RSVP, specifying GOS for voice
and the overall quality and redundancy of sequential interconnecting
terrestrial backbone routes, particularly in multiplexed parallel backbone
sections ->to which you might interconnect and through which you
selectively route<- you can and will have a potentially huge positive
impact on your Delivered Quality of Application & Combined Service Grade,
assuming a mixed media environment of multiple and transparently,
constantly, changing service provisioning with Email, WWW, Voice, Fax, &
Video sharing the combined transmission medium in a largely unscheduled
manner. Given the tremendous flexibilites and growing capabilities of the
general TCP/UDP/IP transmission medium-through whatever transport
mechanism(s) are chosen in 'smart' routing(as opposed to sometimes
sub-standard quality least distance routing), notably with the constant and
obligatory crossing of thresholds between terrestrial and various wireless,
including satellite, this composite environment is becoming increasingly
common and increasingly inescapable in global service provisioning. Hence a
commensurately increased understanding of how to correctly engineer this
via satellite has become essential if we plan to seriously and properly
provide what we call "Locally Affordable TCP Based Services" of all kinds
to the 3/4 of the planet outside of the most economically developed regions
of the world.
Solution Set? So whatever your "application layer" may have inside, with
Email, WWW, Voice, Fax, & Video, be sure to provision your underlying
information 'transport medium in the sky' with enough power & bandwidth and
specialized gear for a low BER so as to ensure that you compensate for all
reasonable transient service degradation possibilities (which you can do!)
... and be sure to never have congestion creating the problems we all know
about and agonize about.
Hence, having said that, one of the obvious solutions is to compress each
data type to the mimimum desired Quality of Service and interconnect with
the highest grade of interconnect trunk capacity on the ground possible at
all times. Use of State-of-the-Art Compression of Internet borne data out
of the ground and over satellite with smart internetwork routing->done
intelligently, <instead of the industry average of 1:1 dinosaur engineering
of no compression> will lower your operations costs for power and bandwidth
and give you increased savings in operating costs which you can re-invest
in your links 'tax-free' and which will allow you to avoid the temptation
of overloading the links. Jumping over congested traditional MAE's and
clogged regional grids by satellite with smart routing then becomes viable
and really affordable, and helps the Internet move away from the idea of
painfully and expensively backhauling 70% of non-USA/Canada originating
international traffic to and from the United States of America & Canada
before delivering it elsewhere. This way the increased throughput of error
free data of all kinds will allow you to bypass overloaded terrestrial grid
areas by satellite and gladly exchange even geostationary satellite delays
for potentially longer peak hour 'crawls' through overloaded and bad
terrestrial grids, exchanges and MAE's. Further, focussing on tightening up
the speeds of Digital Signal Processors(DSP's) and framing/cell creation &
network management devices with faster and better chips and ASICs outside
of the satellite link will go far to improve voice carriage capabilities
even at consistently lower bit rates and higher QOS through a comparatively
non-stressed satellite environment for carrying TCP. Additionally, the huge
projected shortfalls of satellite capacity anticipated in some parts of the
world will be relieved partially by "greener carriers" using the satellite
capacity more frugally with new DAMA switching techniques which eliminate
voice channel units in a grid connectivity environment of "multi-mesh"
connectivity to terrestrial and near ground wireless and yet more
efficiently use space segment at lower cost per delivered caller minute.
Ultimately, one must also remember that when a cable fails, it's usually
cut...and it stays cut/'down' for some significant time before it's
repaired, so a little creativity in using space segment carefully is not a
bad thing; and the future for TCP Over Satellite is very bright indeed due
in part to the combined creative energies of participants in this forum.
So, in summary, it's worth remembering that TCP wants an error free
environment wherever it runs and the way to get it over satellites of any
kind is really very simple...>>>just do good engineering homework and you
won't have mountains of errors and extraneous noise and all the painful
problems we know about due to the 'pile up' in buffers and lost packets,
slow starts and all the rest of the mess! You wouldn't constantly "redline"
your car, your boat or your plane every time you took it out, so why plan
for sloppy, dinosaur style and 1:1 uncompressed data transport in your
engineering for your satellite links and in doing so stress out your
transmission environment constantly? Accept specifically only the operating
conditions that TCP really likes and build your links accordingly...and
guaranteed they will be without noise. Then the mountainous and thorny
problems being studied in this TCP-Over-Satellite Forum will seem much
smaller and will be comparatively easier to solve!
En Avant Ensemble!
Respectfully Submitted,
Charles A. Ross
Two guiding thoughts from our company:
ACANTHUS/BEEDNET Motto 1: "Labor Improbus Omnia Vincit"
"Persistent Enlightened Efforts Overcome All Difficulties"
ACANTHUS/BEEDNET Motto 2: "It takes a Little 'Vision' To Know the Needs of
the Future,
and To Know The Answers Today."
------------------------------------
Charles A. Ross
President
ACANTHUS Corporation
&
BEEDNET Group
replies to:
Prague, Representative Office
GSM mobile +420.(0)603.500.000 (voicemail)
GSM mobile +420.(0)603.49.1000 (voicemail)
Palace Novak
Vodickova 30
110 00 Prague 1
Czech Republic
+420.2.2421.9525 tel/fax/voicemail
+420.2.2421.3090
------------------------------------
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST