Multicast as a traffic variance smoother for IP streaming service
Satoru Ohta, Seiichiro Tani, and Toshiaki Miyazaki
NTT Network Innovation Laboratories, NTT Corporation
Japan

Abstract
Live streaming service is expected to be popular in future IP networks. However, since the traffic generated bythis service has a large bandwidth that varies unpredictably, it is very likely to bring about network congestion.
This paper clarifies that the intractability of stream distribution traffic is effectively reduced by multicast
techniques. The paper focuses on one multicast implementation technique and executes a computer simulation
to verify its effectiveness. The simulation results show that the technique successfully decreases the traffic
volume and variance for several traffic-change scenarios. It is also shown that traffic burstiness is, as measured
by self-similarity, smoothed by multicast. All these characteristics confirm that the multicast techniqueeffectively avoids the congestion possibilities associated with IP streaming services.

1. Introduction
The live streaming of contents, such as video
broadcasting or Internet radio, will become the mostpromising service among the many interesting
possibilities offered by the IP (Internet Protocol)
network. It is anticipated that this service may
providetelecommunication
carriers
orservice/contents providers with a new income source.
Unfortunately, the traffic of this service is intractablefrom the viewpoint of congestion for the following
reasons. First, the bandwidth required is large,
particularly for video broadcasts.
Next, thebandwidth is likely to increase as the service becomes
more popular. Moreover, the traffic will be bursty
because data recipients randomly join and leave thedata stream. Additionally, the geographic traffic
patterns will vary unpredictably over time sincetraffic may concentrate on a particular area due to therelease of a popular content. The asymmetry of thetraffic is another problem in providing the service.
The live streaming service is expected to become
more popular and dominate the IP network traffic.
This means that the above traffic difficulties will
become more critical. Among these difficulties,
traffic asymmetry was treated in [2] and [3]. Thus,
the remaining problems to be solved are large
bandwidth requirements, increases in theserequirements, and traffic burstiness. Considering thenature of the service, the employment of multicast
techniques is a powerful solution to these remaining
problems.
The key feature of live streaming traffic is thesimultaneous distribution of the same information to

many recipients.
Therefore, transmission may
become redundant which wastes network resources.
It is known that multicast techniques can effectively
reduce the volume of such traffic [4]. With a view toeasing implementation concerns, we can employ thestandardized IP multicast protocol [5] or othermulticast techniques [1,6]. While these multicasting
techniques are now widely available, it becomes
important to determine how effectively multicast candecrease the traffic intractability caused by live
streaming service.
This study uses computer simulations to examine theeffectiveness of multicast in decreasing the traffic
intractability. This study employs the multicast
technique proposed in [1], because it can be
introduced to the existing IP network more easily
than the alternatives. To clarify its effectiveness interms of traffic characteristics, several simulation
scenarios are examined. These scenarios include
traffic volume increases, geographic traffic patternchange/concentration and the partial placement ofcopy nodes. Traffic load characteristics were
measured under these scenarios, and compared to theperformance of unicast. The results show that themulticast technique minimizes the volume andvariance of traffic load against demand variations. In
particular, multicast dramatically reduces theburstiness of the traffic as well as its volume
compared to unicast. The burstiness reduction isverified by checking the self-similarity of the traffic
on a link. These characteristics prove that multicast
effectively reduces the possibility of congestion whenproviding live streaming service. It is also shown thata significant reduction in traffic volume and variancecan be obtained by introducing just a few copy nodes

into the network. These results suggest that multicast
is a promising technique with to solve the traffic
problems expected in the future IP network that
supports live streaming as the dominant service.
This paper is constructed as follows. Section 2
describes the multicast technique considered. The
network model and scenarios used in the simulations
are presented in Section 3. Finally, the simulation
results are given in Section 4.

children. In this way, data is transmitted from one
source to many clients simultaneously. This datatransmission may involve some legacy routers
between the server node, copy nodes and client nodes.
This configuration is summarized in Fig. 1.

Stream Data
Copy Node 1

Copy Node 2

2. Multicast technique
The term multicast originally means a communicationstyle, in which one source sends the same data to one
or more recipients simultaneously [4]. This type ofcommunication is possible by setting multiple one-toone communication relationships between the source
and recipients. However, it is more efficiently
achieved through a distribution tree. This techniqueplaces a copy function at each transit node and thus
eliminates duplicative transmission of the same data.
This study calls such communication style“multicast”; the communication method that
establishes multiple one-to-one communication
relationships is referred to as “unicast”. Several
multicast methods have been proposed [1,5,6].
Among the multicast techniques suitable for IP
networks, this study focuses on the multicast scheme
proposed in [1]. This technique provides a morepractical way of distributing the same data stream tomany recipients simultaneously than the alternatives
with regard to the following points:-

Simpler administration than standardised IP
multicast.
Load balancing and dynamic reconstruction ofmulticast trees.
Addition of personalized information such as
advertisements is possible.

The multicast technique proposed in [1] utilizes client
nodes, server nodes, copy nodes (referred to as active
nodes in [1]), and optional legacy routers. These
nodes configure logical distribution trees, throughwhich stream data are transmitted. Each distribution
tree is associated with one particular data stream, forexample, a video program. A server node is the rootof the tree and acts as the source that sends original
stream data. The leaves of the tree are client nodes,
which send distribution requests and receive thestream data. Other nodes in the tree are copy nodes.
The data passes from the server node to the copy
nodes. A copy node makes as many copies of thedata stream as its children, which may be other copy
nodes or client nodes. The copied data are sent to the

Client Node 4

Copy
Node 3

Copy
Node 4
RequestRouterServer
NodeClientNode 2

ClientNode 1

Client Node 3(a) Physical network configuration.

Server Node
Copy Node 1
Copy
Node 2
Copy
Node 3

ClientNode 1

Copy
Node 4
ClientNode 2

ClientNode 3

ClientNode 4(b) Distribution tree.

Fig. 1 Network configuration
technique of [1].

of

the

multicast

The distribution tree is constructed through a simple
protocol. The main component of the protocol is thejoin (or keep alive) packets. The join packets are
periodically sent from a client node or copy node to
the server node. They are intercepted at its parent,
which may be a copy node or a server node. The firstrole of the join packets is to notify the parent that anode has joined the tree. Second, they maintain theconnection such that the stream continues to be sentfrom its parent. If a client node wants to receive datafrom a server, it starts sending join packets to theserver. The join packets arrive at a copy node on the
IP unicast routing path from the client to the server.
The copy node picks up the join packets and extracts
their sources and destinations. According to thisinformation, the copy node puts the source of thepackets into its distribution table. The copy node

sends join packets to the server as long as it receives
join packets from some other copy node or client
node. Finally, the join packets reach the server. The
server makes its distribution table in a similar way.
The data stream is distributed from the server to thejoin packet sources written in the distribution table.
A copy node then copies and distributes the data
stream to its children indicated in its distribution table.
In this way, stream data is transmitted from the server
to clients along the distribution tree, which isconstructed by sending join packets from the clientsto the server.

Additionally, the burstiness of traffic is also a causeof congestion.

Server 0

Server 2

Center 0

Edge 0Center 1

Edge 1

Edge 2 Edge 3

Edge 4

Edge 5...

...

Server 1

Server 3...

A copy node deletes a distribution tree entry if it does
not receive any join packet from the associated childnode within a specified timeout period. Redundantdata distribution is, therefore, avoided because thechildren that no longer need the distribution
automatically leave the tree by this timeout
mechanism. When a client node cease to receive data,
it simply stops sending join packets.
The validity of the above protocol was confirmed
using a prototype system, which was built on thebasis of the active network technology [1]. Trafficload reduction may be obtained through othermulticast schemes such as the standardized IP
multicast etc [5, 6]. However, this paper focuses on
the above protocol because it is more practical than
the alternatives.

3. Network model and scenarios
To clarify the effectiveness of multicast, this study
simulated the network model shown in Fig. 2. The
model is composed of two connected hierarchical star
networks. The network includes 90 client nodes, 8
copy nodes/routers, and 4 server nodes. Notice thatcopy nodes can be replaced with legacy routers when
the unicast technique is evaluated or alternative copy
node locations are compared. The server nodes areconnected to the top-level copy nodes/routers as wellas to the bottom-level copy nodes/routers. The latter
configuration corresponds to peer type servers, suchas personal IP broadcast stations. As seen in the
figure, copy nodes/routers are labeled Center 0,
Center 1, Edge 0, etc. according to their level whileserver nodes are labeled Server 0, 1, etc. The link
capacity was set at 45 Mb/s.
For this network model, several scenarios were
examined to test various network congestion
situations. Traffic congestion can be created byseveral factors. First, the network can become
congested simply because the traffic load exceeds
network resources. Traffic variance across regions
and over time may congest particular links or nodes.

...

...

...

15 Client Nodes ×6

Fig. 2 Network model for simulation.

This study examines the effectiveness of the multicast
technique in decreasing the traffic congestion createdby the above causes in the following simulation
scenarios.
Scenario 1) Demand increases with simulation time t.
This was simulated by increasing the number of client
nodes that send requests. That is, only 30 of the 90
client nodes send requests at the simulation start time
to t = 1 (hour). The number of client nodes joining
the distribution tree was increased by 30 every hour.
The bit rate over one link was measured at regularintervals. This scenario approximates the customer
increase according to the popularization of the service.
Scenario 2) Geographic traffic pattern changes at a
specified time. Namely, the requests directed toServer 1 are switched to Server 3 at time t = 1 (hour).
The link bit rates were measured before and after thischange. This scenario approximates the situation
where server popularity changes at time t. Such asituation can occur if the content is changed or if theservers are mobile and move.
Scenario 3) Requests from a particular region
increase during a specified time period. Specifically,
5 out of 15 client nodes supported by each edge node
send requests to servers throughout simulation time.
In addition to this basic demand, the remaining 10
client nodes connected to a specified edge node (Edge1) also send requests from simulation time t = 1(hour) to t = 2 (hour). We used the measure of thelink bit rate. This scenario simulates a transient
traffic concentration.
With the method of [1], some transit routers must be
replaced with copy nodes. Since this replacement

Scenario 4) This scenario considers three schemes tolocating copy nodes. Scheme A places the copy
function at each transit node. Scheme B places the
copy function only at the edge locations and not at thecenter. Scheme C places the copy function only at thecenter.
The payload size of each data stream packet was set
at 1500 Bytes, while the interval between the packets
was set at 0.1875 sec. These values lead to the stream
bit rate of 64 kb/s. Although the bit rate looks low
against the current values, it was selected to improve
simulation efficiency. The request generation processfrom each client node was modeled as an on-off
source. Namely, it repeats the on period in which join
packets are transmitted periodically and the off period
in which no join packets are transmitted. During theon period, one join packet was generated every
second, and the packet size was set at 200 Bytes. The
on and off periods were randomly determinedaccording to the Pareto distribution of shapeparameter α = 1.2 to obtain bursty traffic. The
minimum values of on and off periods were 10 and 40
seconds, respectively.
The simulation program was built with using atelecommunication simulation tool (OPNET [7]).
The program was executed on the Sun Ultra 60
computer.

4. Simulation result
Figure 3 shows the simulation result for Scenario 1.
The x-axis is the simulation time, while the y-axis isthe bit rate over the link from Server 0 to Center 0.
The figure compares the bit rates for multicast andunicast techniques.
As seen in Fig. 3, link utilization is strongly
decreased with the multicast technique. This isbecause of the copy functions provided by multicast,and thus a server need send only one stream to a copy
node. By contrast, since the server must send as
many streams as there are clients in the distributiongroup with unicast, far greater bandwidth is required
for unicast.
This advantage of multicast isparticularly significant for servers that have narrow
bandwidth access lines, such as personal broadcast
servers. Moreover, the required link bandwidth does
not increase commensurate with the demand. Thisfeature suggests that the multicast technique well

supports the popularization of streaming service
because additional demand requires little in the wayof additional investment.

2
Unicast (Mb/s)
1.5
Multicast (Mb/s)

requires additional investment, it would be better if
the effectiveness of multicast could be obtained byintroducing as few copy nodes as possible. To clarify
this point, the following scenario was examined as
well.

1

0.5
Multicast (Mb/s)
00

12
Simulation Time, t (hour)3

Fig. 3 Bit rate comparison for demand increase(Scenario 1).

Figure 3 also shows that multicast greatly smoothes
the burstiness in the bit rate. This smoothing effect isobvious from the figure because the bit rate is almost
constant with multicast. We verified this effect bychecking the self-similarity of the traffic. Selfsimilarity is a rational measure of burstiness because
self-similar traffic is considered to be more bursty [8].
A simple method of checking self-similarity is thevariance-time plot [8] shown in Fig. 4. The data
represents a simulation period of 16 hours with 90
clients. The figure shows the relationship between
the logarithms of m-aggregated bit rates and block
size m. At a glance, the curve for unicast is a slowly
falling line, which is a clear indication of selfsimilarity. This characteristic is brought by the Pareto
distribution that determines the off and on period
lengths. By contrast, the curve for multicast sharply
falls against log(m). Thus, multicast traffic is not
self-similar and so is less bursty. This characteristicof multicast is desirable because non-self-similar
traffic will yield less congestion for the same level of
network resources.
The result for Scenario 2 is shown in Fig. 5. The
figure depicts the bit rate between Center 0 andCenter 1 against simulation time. In both cases ofmulticast and unicast, the bit rate changes when the
demand pattern changes (t = 1). However, multicast
minimizes the traffic load before and after thedemand pattern change. This fact suggests thatmulticast ensures that the change does not seriously
impact the total traffic load on the backbone link.
Unicast, on the other hand, allows large suddenswings in traffic loads due to the demand patternchange.
This may cause traffic congestion if
resources are assigned without predicting suchchanges.

log10(Var(Aggregated Bit Rate))

1210Unicast8
Multicast
6

4
0

1

2

3

4

log10(m)Fig. 4 Variance-time plot of bit rate from Server 0 toCenter 0.

Bit Rate (Mb/s)characteristic is also confirmed through the results of
Scenario 3 shown in Fig. 6. This figure shows the bit
rate from Center 0 to Edge 1. Apparently, unicast
makes the link utilization high when the traffic loadconcentrates at Edge 1. By contrast, the link
utilization hardly changes with multicast during thisperiod. Thus, the temporal demand concentration is
successfully absorbed by the copy function in thenodes and does not affect the load on the backbone
network. This result implies that multicast makes the
backbone network free of congestion even for
unpredictable traffic changes. However, edge nodeload is affected by the temporal traffic change. Thus,
the capacity of a copy node must be sufficiently large
if multicast is to realize its full potential in absorbing
the effect of unpredictable and temporal trafficchanges.

2
Unicast1
Multicast

Another target of the simulation was to clarify theeffectiveness of partial copy node introduction. Thisis addressed in Fig. 7, which is the result for Scenario
4. Figure 7 (a) shows the bit rate from Server 0 toCenter 0, while Fig. 7 (b) shows that from Center 0 to
Edge 1. The figure confirms that the traffic reduction
and smoothing effects can be obtained by introducing
copy functions into just a few nodes. In Fig. 7 (a), theserver traffic load with Scheme C is lighter than thatwith Scheme B. This is because the copy node iscloser to the server in Scheme C than Scheme B so
the server need support fewer streams. However, link
utilization is lower with Scheme B than Scheme C in
Fig. 7 (b). Therefore, the best location can not be
unequivocally determined from these results. The
location should be decided after considering thelocation of servers and bottleneck links in theoperating network.

0
0.5
1
1.5
Simulation Time, t (hour)(a) Bit rate from Center 0 to Center 1.

2
1.5
Unicast2
Unicast1
Multicast
0
0

0.5
1
1.5
Simulation Time, t (hour)(b) Bit rate from Center 1 to Center 0.

2

Bit Rate (Mb/s)

Bit Rate (Mb/s)

0

1

0.5

Fig. 5 Bit rate comparison for the traffic patternchange (Scenario 2).
Multicast00

As mentioned above, the multicast techniquedecreases the traffic load as well as providing
robustness against traffic changes.
The latter

1
2
Simulation Time, t (hour)3

Fig. 6 Bit rate comparison for the temporal traffic
concentration (Scenario 3).

effects.

2
UnicastThe avoidance of congestion is a serious challenge inintroducing broadband IP streaming services.
Multicast meets this challenge and allows these
services to be cost effective.

Bit Rate (Mb/s)

1.5

1

6. References
B

0.5

A& C
0
0

1
2
Simulation Time, t (hour)3(a) Bit rate from Server 0 to Center 0.
2

Bit Rate (Mb/s)

1.5
Unicast
1

0.5
C
A& B

0
0

1
2
Simulation Time, t (hour)(b) Bit rate from Center 0 to Edge 0.

3

Fig. 7 Bit rate comparison for copy node location
schemes A, B, and C (Scenario 4).

5. Conclusion
This paper presented the effectiveness of the multicast
technique in avoiding the traffic congestion
associated with live streaming service. The method
proposed in [1] was evaluated as the multicast
technique. A computer simulation was executed andseveral important results were obtained. Multicast
greatly decreases the traffic volume as well assmoothing the traffic variance caused by several
factors such as an increase in users, contents/server
location changes, and local demand concentration. In
particular, the variance-time plot revealed thatmulticast decreases the traffic burstiness as measured
by self-similarity, which originates from the bursty
requests of users. The simulation also showed thatthe copy function need be added to just a few network
nodes to realize the traffic decrease and smoothing[1] S. Tani, T. Miyazaki, and N. Takahashi,“Adaptive stream multicast based on IP unicast
anddynamic
commercial
attachment
mechanism: an active network implementation,”in Proc. IWAN 2001, Springer LNCS 2207,
pp.116-133, Philadelphia, Oct. 2001.
[2] S. Ohta and K. Iwashita, “Asymmetric optical
path ring,” in Proc. NETWORKS 2000, Toronto,
Oct. 2000.
[3] S. Ohta, “Economical assessment of anasymmetric optical path network,” in Proc. the2001 IEICE General Conf., paper B-7-86,
Kusatsu, March 2001 (in Japanese).
[4] R. Wittmann and M. Zitterbart, Multicast
Communication, Morgan Kaufman, San
Francisco, 1999.
[5] K.C. Almeroth, “The evolution of multicast:from the Mbone to Interdomain Multicast toInternet2 deployment,” IEEE Network, Vol.14, 1,
pp.10-20, Jan./Feb. 2000.
[6] J. Janotti, D.K. Gifford, K.L. Johnson, M.F.
Kaashoek, and J.W. O’Toole Jr., “Overcast:reliable multicasting with an overlay network,”in Proc. USENIX OSDI 2000, San Diego, Oct.
2000.
[7] http://www.opnet.com/.
[8] W. Stallings, High-speed networks – TCP/IP
and ATM design principles, Prentice Hall, New
Jersey, 1998.