[ To start of mcntp pages ]

Multicast news and the satellite

Heiko W.Rupp <hwr@pilhuhn.de>

Normal IP-Multicast sessions rely - even when they are only simplex in terms of data packets flowing unidirectionally - on a bidirectional circuit: the receiver that wants to receive multicast packets must inform the sender (in an indirect way) that he wants to send packets. Thus a back channel is needed. On a satellite connection this back channel is not necessarily on the same satellite back, but via some terrestrial circuit.

This memo describes a way to send netnews articles over IP multicast on a satellite connection. All data come from real satellite connection provided by Loral Cyberstar(formerly Orion Network Systems).


The following figure shows the used setup:
+--------+    E0             S1
+  News  +--------[Router R1]----[  Magic  ]------[Satellite]
+ Server +                       [Machinery]       /   |   \
+--------+                                        /    |     \ 
                                              S2 /   S2|       \  S2
                                          [Router]  [Router] ...[Router]
                                          [  Ra  ]  [  Rb  ] .. [  Rx  ]
                                             |          |           |
                                             |          |           |
                                          [Server]  [Server]    [Server]
The setup for Routers Ra ... Rx are more or less the same. The term 'Magic Machinery' describes in total the frame-relay switches and satellite transmission equipment that is used to get the data to the satellite.


The connections between the Router on the sender site R1 and the routers on the receiving sites Ra ... Rx are run over frame relay. All receivers will receive the save frame relay pvc and get their data from it.

Router R1:

Ethernet0 is the Ethernet with the connections to the sending news server
Serial 1 is the serial where the connection goes to the frame relay switch towards the satellite
Cisco Config:
ip multicast routing
Internface Ethernet0
ip pim dense-mode
Interface Serial1
encapsulation frame-relay IETF
frame-relay interface-dlci 100
! see below for the next two lines ('possible problems')
no fair-queue            !   (needed for next line to work)
frame-relay broadcast-queue 2048 1000000 999 !    (**)
ip pim dense mode
! repeat next command for each multicast group that you want to send over sat
! see also below
ip igmp join x.x.x.x

Routers Ra ... Rx:

Ethernet 0 is the Ethernet with connection to receiving news server
Serial 2 is the serial with data coming from satellite
Cisco Config:
ip multicast routing
Interface Ethernet0
ip pim dense-mode
Interface Serial2
encapsulation frame-relay IETF
frame-relay interface-dlci 100
ip pim dense-mode
! a.b.c.d is the IP-Address of the sending News server
ip mroute a.b.c.d Serial1

News software

The software to distribute news articles used in this setup is "mcntp" . The software is compiled as usual. The groups that need to be used for the 'ip igmp join' commands on the cisco interface are as follows: These groups with articles in them may change in future where the group assignment can be changed with a config file. It still needs to be found out if cisco will either allow a pattern for the ip igmp join-groups or if there is another good way of getting igmp join messages at least on a so called hybrid connection (where the return path is via a terrestrial link).


With the setup described one can transmit Usenet news articles from one sender machine to a virtually unlimited number of receivers.

Some raw data:

This is for sending the same 5000 articles in every sample. For the transmission, a worklist has been built and all articles are on a local disk. This mode of operation does not reflect real world usage as a) mcntp is supposed with articles coming in freshly from other servers and b) even if this mode would be used to 'catch up' other activities would slow down the system. This test is more or less a stress test to see how fast the system could actually work. The next two tables shows how long it takes for an articles which arrived at a server to be sent by this server via multicast over the satellite to a (multicast) receiver, which processes it. The times are in seconds:milliseconds - the clocks on sender and receiver have been synchronized by ntp to get exact timing data. The sender did spool articles to disk (where they can be grabbed later on and be processed further). The 'sender out' specifies the time when the article has left the news server process, but before it has been processed by the multicast sender.

With digital signature turned on:
Sender out
Receiver in
Receiver finish

With digital signature turned off (*):
Sender outReceiver inReceiver finish Diff
( with the 0.022s/a from above which is needed to send an article and an average of 0.001s/a to process it at the receiver, this gives an average delay of 0.412s/a by the satellite link and the routes and switches in between and at least a delay of 0.197s/a).

With this data one can expect an article which left the sender to appear at any location of the world (or at least where satellite data can be received) to appear within three seconds after it was send off. The average article travels even faster.

Mcntp over satellite can be a real alternative to the distribution of NetNews over terrestrial lines. Especially as prices for satellite antennas are less then about $3000 and are expected to get even lower.

(*)Note:Running without signature is considered harmful and was only used to evaluate the maximum possible speed of the sender system and the delay of the signing process. (Don't do this at home kids ;-) ).

Possible problems

(and a solution) When running the 5000 article test we encountered that some articles did not arrive at the sender. This happened in a large scale when sending articles without doing the digital signature and to a small scale when doing signatures, but not compression. Looking at the router at the sender site (and there on the outgoing serial interface) revealed the possible problem: there have been some drops of broadcast packets (multicast packets are broadcasts in that case).

One possible explanation for this behavior is as follows: the default queue has 64 entries, which all are MTU bytes in size. This gives a total queue size of 93kBytes. If now two articles are send subsequently were the total size is above 93 kBytes, at least one of them gets dropped (and possibly also some following ones). When data compression is used, a 63k article (maximum article size that the multicast sender accepts) gets compressed to about 40kBytes (see [1]) and thus two subsequent large articles still fit in the queue of the router. This problem has been resolved by enlarging the frame relay output queue (**).


[1] Heiko Rupp, "Transport von NetNews via IP-Multicast", Diploma thesis, Institute for telematics, CS dept. Univ. of Karlsruhe, Germany
$Id: mcntp-sat.html,v 1.7 2001/11/22 10:24:37 pilhuhn Exp $