Martin and Lloyd,
With regard to the LEO satellite concepts, they are not well suited to
multicast because the satellites rely on the use of many small-coverage spot
beams, into and out of which any fixed community of multicast receivers will
be shuttled with great difficulty. This is primarily a physical layer issue,
never mind the protocol stack problems. And, please don't hold your breath
while waiting for (LEO-based data) services to be available any time soon
.....
The public Internet multicast system which Steve Goldstein has pointed you
to look at today was developed, through the conceptual phase, here at
INTELSAT. It is tailored to work in pre-existing GEO satellite capacity
(preferably ours!) and on an international basis via global or hemispheric
antenna coverages of the earth. Data multicasting from/to private networks
via GEO satellite is something we have successfully done at INTELSAT for
more than two years, using several different "protocols" (including
StarBurst's MFTP). Nicely paying customers now exist for GEO-satellite
delivered data multicast applications. In no case - private data or public
Internet - are there latency issues with multicasting in the applications
layer. In fact our multicast-to-cache Internet system is designed to
overlay pre-existing point-to-point links already operational commercially
via satellite (so that telecom companies and ISPs don't have to buy new
antennas). And asymmetry of the links is not an issue either - it
translates for the end-user into an additional savings in service cost, and
is in widespread international use for point-to-point Internet via satellite
links today.
Hope this is helpful. If you have new advanced degree topics in mind, then
LEO concepts and their engineering issues will be fine for years to come.
If you want to run a commercial push service based on an innovative
combination of satellite multicast (reliable) and advanced (pre-fetching)
and scaleable caching, with a global market, then stay in touch.
And, yes, there are indeed other somewhat similar developments out there
......
John Stevenson
-------------
Original Text
>From EEP1LW@SMTPGATE (Lloyd Wood) {[email protected]}, on 29/07/1998 12:18
PM:
To: KOYABE@SMTPGATE (Martin Koyabe) {[email protected]}
Cc: FED-IP-M@SMTPGATE ("'[email protected]'")
{[email protected]}, IPMULTIC@SMTPGATE
("'[email protected]'") {[email protected]}, RM@SMTPGATE
("'[email protected]'") {[email protected]}, TCPSAT@SMTPGATE
("'[email protected]'") {[email protected]}
Martin Koyabe writes:
> The major issues in providing this has been asymmetry and high latency,
> unless trade-offs are done. Anyone with further info leads, I could look
> at apart from protocols supported by StarBurst and GlobalCast ?
For upcoming broadband LEO satellite constellations, overlaying of
different protocol stacks appears to be the major problem. (for
example, Motorola's original Celestri proposal included a GEO
component for broadcast, which suggests that the LEO component was
never expected to be multicast-capable; hardly surprising, since each
satellite was envisaged as an ATM switch which IP would be tunnelling
through.)
See the 'supporting group applications via satellite constellations
with multicast' paper at:
http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/
for more on this.
L.
thinks mbone-over-satellite just isn't the preferable solution.
<http://www.ee.surrey.ac.uk/Personal/L.Wood/>PGP<[email protected]>
+------------------------------------------------------------------+
| Federal IP Multicast SIG: [email protected] |
| List maintenance: [email protected] |
| List archive: http://www.antd.nist.gov/archives/fed-ip-mcast |
+------------------------------------------------------------------+
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:45 EST