From: Joseph Brunner (joe@affirmedsystems.com)
Date: Mon Oct 08 2007 - 14:28:08 ART
Thanks for the info.
You watch "enemy of the state" do some research, and find out you didn't do
some very good research. When Iridium came out (and teledesic didn't) you
start to see the futility in any thing besides a good old terrestrial
T-Carrier line. At the time speeds of "2mbps" in a briefcase anywhere seemed
logical. I had the sprint "broadband" card on my laptop once... it was a
slow 19k dog from hell (even where the sprint phone had high signal)
Even my cable modem was D.O.A. last night... seems TWCNYC RR's is running
with TTL like ping times to Google.com... my remote rack was AWOL
Thanks,
Joe
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Vermillion
Sent: Monday, October 08, 2007 12:10 PM
To: 'Joseph Brunner'; slammer@broadpark.no; ccielab@groupstudy.com
Subject: RE: Multicast/Satellite Problem, Anyone who want's to take this on
!!!!!!
Joe,
There aren't many (any?) Low Earth Orbit (LEO) satellites in commercial
service these days. IIRC, the US DoD bought out Iridium for its own use
when the folks flying the Iridium birds announced bankruptcy a few years
back. Thus, shipboard service is likely to be on a geosynchronous bird @
22,300 miles up! A good number of non-DoD satellite solutions are based on
International Maritime Satellite (INMARSAT). Let me just throw out a
warning here:
INMARSAT launched its "Broadband Global Area Network" (BGAN) service
probably 18 or so months back. Not only is it outrageously expensive (as
the standard old INMARSAT once was), but it's total crap. Even with
~$17/minute 256 kbps "streaming" service, you will experience round-trip
delay on the order of 1500 - 2000 ms (and the packet-to-packet jitter might
approach 1000 ms)! My experience with this product started the day the
service was "launched" (aka the day BGAN clients began debugging the service
and the hardware at $17/min) and is as recent as just two weeks back. Not
much has changed. It's still way too much money for way too little service
offered.
Slammer,
I'm not sure I would reinvent the wheel on this one. The US Navy and large
maritime commercial interests have been doing stuff like this for a great
many years. There are no doubt solutions already in existence. What you
didn't mention was your BW requirements! That is a critical consideration
as far as the satellite side of things is concerned and you really do need
to consider the satellite side of the house up front, as that will largely
drive you towards a particular product/service/topology/approach...
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Joseph Brunner
Sent: Monday, October 08, 2007 1:46 AM
To: slammer@broadpark.no; ccielab@groupstudy.com
Subject: RE: Multicast/Sattelite Problem, Anyone who want's to take this on
!!!!!!
The delay with satellite is the fact the satellites are orbiting around the
planet 50 to 500 miles high!
Multicast traffic by nature must be UDP. So if the xcast/Gxcast is UDP or
connection less, it could help you out over TCP. You would not have the
built in reliability of a connection oriented protocol, but given the
topology and make up of this network, you just want to sling packets back
and forth...
Check with a satellite services firm (Iridium?) they have to have someone
who can go to town on this for you... Hughes, Loral Spacecomm, many other
come to mind... many people are using satellites for mission critical data.
-Joe
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
slammer@broadpark.no
Sent: Monday, October 08, 2007 3:41 AM
To: ccielab@groupstudy.com
Subject: Multicast/Sattelite Problem, Anyone who want's to take this on
!!!!!!
The topology is like this (can be changed to full mesh)
------R2--client (vessel2)
-
-
(Vessel1) server---R1---SAT------------R3--client (vessel3)
-
-
------R4--client (vessel4)
Vessel 1 is master and sends data to vessel 2,3 and 4
the clients need to send data to vessel 1.
1.This is realtime data and delay jitter can be a problem, we are talking
about
max 300ms delay
2.To avoid tcp and broadcast traffic it is suggested that multicast is
implented
in a point to multipoint topology or full mesh !!!!!!!
There is a suggestion using xcast/Gxcast protocol but as far as I know
cisco
doesn't support these protocols as far as I know
3.Ratio would be 60% transmit traffic and 40% receive traffic to and from
the
master.
Any suggestion on what type of multicast to implement and does anyone know
what
Qos tools that can be used to mesure delay jitter etc...
As the vsatmodem and sattelite is not my problem initialy I was thinking
about
setting up this in a lab
I know there's a lot of BIG brains out there, so any input will be of great
value
Thanks in advance guys.
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:12 ART