[ 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).
Scenario
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.
Setup
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 255.255.255.255 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:
- 224.0.1.51 (mcntp-directory.mcast.net)
- 239.1.1.x with 1<x<16 (groups where articles are transported)
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).
Results
With the setup described one can transmit Usenet news articles from one sender machine to
a virtually unlimited number of receivers.
- Articles that are received by the news server and which are sent off will arrive within one second
at the receivers -- on every location on the world. This is with encryption of message digest and
online compression turned off.
- Online data compression takes about 5-10% CPU on a Sparc20 (all.all Feed, <55k article size)
Running with online data compression does not noticeably delay articles. Compressing the
article actually takes 0.011s/article.
- With digital signature turned on (512bit key), one gets about 7 articles per second sent on a
Sparc20.
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.
- Doing digital signature, but no article compression:
12min06.8, 11m57.6, 11m51.9, 11m28.9 => avg: 11m51.3
gives 7.09 articles/sec. or 0.142sec./article
- Doing no digital signature (*) and no article compression:
1min56.8, 1m53.8, 1m49.0, 1m49.2, 1m43.3 => avg: 1m50.4
gives 45.2 articles/sec. or 0.2208 sec./article
- Doing no digital signature (*) , but article compression:
2min46.6, 2m45.3 => avg 2m45.95
gives 30.13 articles/sec. or 0.0331 sec./article
- Doing digital signature article compression:
(only one sample) 12min38.9 =>
gives 6.588 articles/sec. or 0.151 sec./article
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:
Time
Sender out | Time
Receiver in | Time
Receiver finish | Diff |
| 21.750 | 22.959 | 22.971 | 1.221s |
| 43.988 | 45.917 | 45.928 | 1.940s |
| 21.177 | 23.453 | 23.464 | 2.287s |
| 51.411 | 52.552 | 52.564 | 1.153s |
| 51.474 | 52.635 | 52.647 | 1.173s |
| | Average: | 1.555s |
With digital signature turned off (*):
| Sender out | Receiver in | Receiver finish | Diff |
| 40.692 | 40.936 | 40.936 | 0.244s |
| 34.071 | 34.290 | 34.291 | 0.220s |
| 21.491 | 22.164 | 22.165 | 0.674s |
| 19.968 | 21.556 | 21.571 | 0.603s |
| | Average: | 0.435s |
( 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 (**).
References
[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 $