LOnSIiuCIIOn OIun LIHCICnI In-JiCC-buSCd

CCi-IO-CCi 5IiCumIn uIIOim

^On-IuHuan
Department of Computer Science and
Institute of Communication Engineering
National Tsing Hua Universit
Hsin-Chu, Taiwan
Yh-JOu1Zan
Department of Computer Science
National Tsing Hua University
Hsin-Chu, Taiwan
Hong-YiLhangandLhih-5hunNa
Department of Computer Science
National Tsing Hua University
Hsin-Chu, Taiwan
AbstractAlthough application layer multicast (ALM) has
attracted much attention in transmitting multimedia, it has a
serious problem: the multicast tree is fragile and a peer failure
will cause tree partitions. This work proposes the novel
Hierarchical Ring Tree (HRT) architecture for Peer-to-Peer (P2P)
live multimedia streaming by combining the ring-based and tree
based structures. When a peer logs on or off the system, the
topology is recovered rapidly, allowing live multimedia streaming
to deliver smoothly at low latency. This architecture is
constructed and maintained efciently without tree splitting or
merging. The performance of the approach is evaluated over the
PlanetLab network. Experimental results indicate that the HRT
approach achieves a good overlay performance in terms of data
loss rate, end-to-end delay, and efectively reduces the overheads.
Keywords-Applcation Layer Multicast, Peer-to-Peer, Live
Multimedia Streaming
1. INTRODUCTION
P2P overlay multicasting has become increasingly popular
for handling live streaming media on the Internet. The major
challenge, however, is that P2P networks lack performance
guarantees. For example, a peer can be rejected or disconnected
at any time without prior notice; while others can join or re-join
the network. Also, the conventional tree-based scheme exhibits
poor performance of content delivery on a distorted overlay
without repaIrIng it. Such highly unreliable network
architecture is a major problem in media streaming.
The characteristics of an efcient P2P scheme include: First,
the height of the tree must be as small as possible and the
joining procedure must be completed as fast as possible to
shorten end-to-end delay. Second, to reduce the number of
afected peers and maintain media streaming quality in chum
situation, a robust technique must provide fast recovery when
failure occurs. Third, control overhead is another critical issue
concering P2P architecture. When there are excessive control
messages between peers or between source peers and other
peers, this will consumer a large amount of network resources.
System scalability will thus be restricted when there are many
peers.
In this work, the Hierarchical Ring Tree (HRT architecture
is presented as a novel, stable and resilient structure for P2P
multimedia streaming. It supports the effcient construction and
maintenance of a multicast tree with the following features: (1)
75
it needs only a few messages to add or remove a peer; (2) short
recovery time; (3) low infuence on other peers when a peer
joins/leaves the network, and (4) no need of tree splitting or
merging. The multicast tree constructed by HRT algorithm is a
logical topology with a stepwise ring tree structure. As a robust
structure, HRT provides almost seamless data delivery with
distributed rings and backup links when a peer logs out. HT is
also a resilient structure which effciency selects a peer to
replace the previous peer and quickly handles the subsequent
recovery process. Moreover, the structure is scalable [2] as it
takes only a few communication messages to maintain the
topology.
The rest of this paper is as follows. Some related work are
presented in Section II. The proposed HRT approach is
described in Section III. Section IV provides the performance
evaluation of the proposed structure. Finally, some conclusions
are given in Section V.
II. RELATED WORK
Various systems have been designed for P2P live streaming
[8,16], and a streaming overlay with high service quality, short
delay and great scalability has always been the central issue of
design. There are two major solutions for optimizing live
streaming overlays: tree-based [4,5,10,15] and mesh-based [16]
overlays.
The tree-based architecture is simple and easily
implemented. With an overlay spanning tree, its tree-based
architecture allows members to select their parents from the
known members. There are two types of tree-based architecture:
the single-tree architecture, such as NICE [10] and ZIGZAG
[4,5]; and the multiple-tree architecture, such as CoopNet [15].
The single-tree architecture focuses on constructing a highly
efcient scalable multicast spanning tree. The architecture uses
a center that maintains the topology and collects topological
information about trees. Any peer intending to join a group
must frst contact the center to obtain the corresponding group
information and then choose a peer as its parent. The NICE and
ZIGZAG architecture frst organizes peers into different logical
layers. All peers at the Oth layer are divided into diferent
clusters based on their network locations. A leader is selected
from a cluster in layer i to become the member of a cluster in
layer i+ 1. The source server (root) is the leader at the top layer.
As the upstream bandwidth of a peer is ofen restricted, the
resources of some leaf peers, especially bandwidth, in these
systems are underutilized. The multiple-tree architecture
ensures overall resilience and the load balance of the entire
streaming network. The primary goal is to divide the video of a
stream into several sections based on the "layer concept" in the
CoopNet or patching processes. Unfortunately, the leaving or
crash behavior of upper layer nodes causes fequent buffer
underfow, and there is no backup service in the tree-based
architecture. In the mesh-based architecture, such as
CoolstreamingiDONet [16], peers accept media data fom
multiple "parents", each of which provides services for
multiple "children". When selecting neighbors with random
algorithm, start-up delay is unavoidable. Also, a large bufer
space as in CoolstreamingiDONet is usually required in order
to reduce the infuence of autonomous peers.
Real-time implementation, low latency, fast recovery, and
ease of maintenance are the important characteristics [1,11] of
tree reconstruction and maintenance in P2P overlay networks.
Although tree-based topology delivers good real-time data
transmission and is easily constructed, there are a number of
problems. First, once an intermediate peer leaves, its child
peers are unable to receive data; and this does not happen in the
mesh-based architecture. Next, its transmission latency is
higher than that of the tree-based architecture. This is because
it takes a longer time for peers need to exchange a larger
number of messages, including associated packets and the
locations of peers holding the next packets. As a total solution
for these problems, the novel ring-tree-based architecture with
a short delay that is easily reconstructed and higly robust is
proposed.
III. HT SCHEME
A. Data Link Backup Link and DDR Ring
The proposed HRT topology as shown in Fig.l includes a
ring-tree-based structure to support live multimedia streaming.
Data links are used to transfer data. The fnction of the backup
link is to ensure that data are transferred fom the upper levels
to the lower levels as soon as a parent peer leaves. When a peer
leaves, a backup link can rapidly relay data to its children
smoothly and steadily. Additionally, the purpose of a ring is to
provide the linked peer a backup link to forward data to all
peers on the same branch of a single level. A backup link will
Root
Iig. 1. The proposed topolog of 3-1evel HRl.
76
be created afer child peers join a parent peer to form a ring (of
at least two peers). Afer a backup link is initially established,
the connection process will be achieved through the following
steps. First, each parent selects its child peer with the smallest
position number. Next, the selected child peer links to a peer at
the upper level. Finally, the selected peer continuously
exchanges messages with another peer that links a sibling of
the selected peer's parent to confrm that they still exist, and a
backup link is established. For connecting a peer, it is more
likely that a child peer will connect to a sibling rather than to
the grandparent. As each peer has k children, the degree (the
load imposed by the service) of the linked peer in a method that
a backup link is connected to a peer's grandparent is k
2
times
more than in the proposed method. A peer cannot flly support
the extra service load (the factor of k
2
), even when the number
of affected peers in that method is k
2
times the number in the
proposed method, as long as the linked peer with the backup
link leaves.
At least two children of the same parent can form the
simplest ring. Each ring consists of all peers on the same level
in a branch. Peers in the same ring exchange periodically the
"hello (heartbeat)" message (like those exchanged over a
backup link) with their siblings. When the parent peer leaves,
the ring carries data (serving as a data link) from one child peer
P with a backup link to P's neighbors. It therefore has a dual
role: a backup link and a data link. Since the operations of a
ring are distributed among all branches of all levels, such a ring
is called a DDR (DistributedlDecentralized Dual Role) ring.
B. Peer Degree and Height f Multicat Tree
The peer degree and the height of the multicast tree are the
most important factors that infuence QoS. A peer's
transmission load in a multicast tree increases with its degree
because each peer must forward data to its neighboring peers
[13]. Therefore, the degree-constrained, QoS-aware multicast
architecture is essential to implement real-time multicast
services. Streaming services are QoS-sensitive applications
highly associated with network bandwidth, transmission delay
and other performance parameters [3]. In practice, some
multicast trees with high-degree nodes may exhibit a long
delay; while others with low-degree nodes may exhibit a lower
delay [3]. Therefore, degree constraints reduce average latency
[II]. Furthermore, a longer path of a multicast tree is
associated with longer end-to-end delay [6]. For fast
communication, a P2P network must reduce the
communication latency between any two nodes. Accordingly,
an efcient tree-based P2P network has two characteristics.
First, the degree of peers is constant [12]. Second, the height
(path length) of the tree is low [5]. The proposed approach
exploits the characteristics of the hierarchical k-way tree to
keep the height of a multicast tree of N-numbered peers under
10gkN, and keeps each peer degee in a constant value (k+4) [7].
Conversely, each head in the ZIGZAG clusters has many layers.
Therefore, the height of the multicast tree of N-numbered peers
exceeds 10gkN (210gkN + 1) [4,5], and the peer degree of
ZIGZAG is (3k-l) (6k-3), k > 3 [5]. In the presented
architecture, the maximum joining overhead is Lg kN + 3; the
maximum departure overhead is k + 4, and the maximum
controllrecovery overhead is 2 Lg kN + k + 4 [7]. The
2(a)2-IcvcIHlHb11L1.
2(b) 3-|cvcIH/cT_stncturc.
Fig. 2. Examples of peer join in HRI structure.
overhead handling of peer join and departure is smaller than
[4,5].
C Construction ofHRT
In the HRT approach, a new peer that wishes to join a
multicast tree submits a request to the root of the multicast tree.
Subsequently, the request is redirected fom the root to a leaf at
the shortest length. When the parent is found, the new peer
establishes a connection to its parent. The details of the joining
operation in HRT are as follows:
1) Finding a position: When a peer is to join a HT tree,
the request of the peer is started fom the root to a leaf at the
shortest length using the "top-down" strategy. In each level,
the peer joins according to a breadth-frst method.
2) Joining a new peer: Fig. 2(a) displays an example of a
two-level HRT6 structure. Peers join in level 3. The frst k new
peers are positioned such that they have the same parent peer.
The next k peers are positioned in the same manner (Fig. 2(b.
As each child peer joins, it is assigned a position number
under a parent. The position numbers under each parent ranges
1 to k. Peers are assigned position numbers in the order in
which they join.
3) Connecting a DDR ring: At least two children under a
parent can form the simplest DDR ring. Each peer has a
maximum of k descendants. These descendants also form a
DDR ring. When a new peer joins, the peer is connected to a
DDR ring based on its parent's information. (The address
information of a DDR ring is sent to the new peer to allow it to
become a new member of this ring.)
4) Establishing a backup link: The joined peer with the
smallest position number in a ring is selected and linked to a
sibling of its parent. Such a link serves as a backup link when
a parent depars/fails. In the proposed architecture, a backup
link to a sibling of a peer's parent is better than a link to the
peer's grandparent, because each peer has k descendants, the
degree (load imposed by service) of the linked peer when a
backup link is connected to a peer's grandparent is k
2
times in
the proposed method. Furthermore, the number of peers
affected when this peer with the backup link leaves is also k
2
times as that in the proposed method. However, when a parent
has no sibling owing to the departure of multiple peers, the
backup link is connected to the peer's grandparent.
77
J) Updating the state: To manage the topology, a message
regarding state change caused by the joining of a new peer
must be sent to the affected peers fom this newly joined peer
to the root (maximum) in a distributed operation.
D. Departure Mechanism
Once a peer leaves, the data in the upper level must
continue to forward to all child peers. The operations
supporting the leaving HRT are as follows:
1) Enabling the backup link and the DDR ring (which
comprises the children of the departed peer): When peer x
departs, the backup link (between the selected peer of the
descendant ring of peer x and the sibling of peer x) is rapidly
switched to regain data (Fig. 3). To maintain the relay of a
data stream, the backup link and the DDR ring must be
enabled to carry a data stream to the descendants of the
departed peer as a peer fails/departs.
2) Reconnecting a DDR ring (which consists of the
siblings ofthe departed peer): When a peer departs, the right
and lef siblings of that peer rebuild the DDR ring. As shown
in Fig. 3, when peer x departs, its right and lef siblings
immediately rebuild the DDR ring to keep the architecture
stable.
3) Reestablishing a backup link: When the departed peer
has a backup link, a newly selected peer builds a backup link
such that each branch at each level always has a backup link.
This scheme reduces the effect of delay on the ability of
users to receive the delivered stream. Therefore, real-time
multimedia data can be transfered through the data link
8R - :: :B


!

x
*""""*~ .~.

.
tep3:

Reconnecting a
Step I : Cangmg
Step 2:
. DDR rin
to a data Imk and
Reestablls!llg
g
enabling a DDR
a backup link
ri ng
Fig. 3. An example of peer departure in 3-level HRT6 structure.
.

:-': 8

/;

. - _ (

Step 3-J. ccstablishing

a backup Imk
Stc3-2. Chanyny toabacku

'.

Choosiny acci
4(u) Chosnyupccr.
Step 2: Rcconncctny thc ' link and disabling a DDRring
cctand its sibIiny
Step I: Connecting the pccrp and its pareni
and connecting the peerand its children
4(b) RcpIaciny IhcposiIion oIhcucparIcupccr.
Fig. . /D example of peer recovery i 3-level HRT6 structure.
(previous backup link) to the DDR rings formed by the
descendants of peer x; the branch peers of departed peer x
continue to transmit and obtain real-time multimedia data
through this backup link. Accordingly, the delay of messages
received by peers is minimized.
E. Recover Method
Although the DDR ring and backup link can be used as
temporary paths for transmitting streaming data and reduce the
delay caused by a lef peer, a swif recovery method for
stabilizing the whole topology is essential. The details of the
recovery operation are presented below.
1) Choosing a candidate and re-aining: To achieve swif
recovery, the proposed policy replaces a departed peer with a
descendant leaf-peer fom the bottom level of the branch of
the departed peer (Fig. 4(a)). The selected leaf peer (which
was the last to join) has the largest position number in the ring
with a particular parent. This replacement is fast and efcient
as very few peers have to be considered.
2) Building a DDR ring: Peer p is chosen fom the bottom
level of the branch of peer x. Fig. 4(b) shows the replacement
of peer x with peer p, and the corresponding DDR ring and
backup link that are established to preserve the stability of the
architecture.
3) Establishing a backup link and disabling the enabled
backup link and DDR ring: Afer replacement, the enabled
DDR ring and the backup link should be disabled (Fig. 4(b)).
If the departed peer originally has a backup link, the selected
peer will reestablish this backup link to ensure that each
branch on each level of the HRTarchitecture always includes a
backup link.
4) Updating the state: When a chosen leaf peer that
replaces another peer is moved, several peers are needed to
adjust the state on the entire branch. Therefore, all peers on the
branch may be affected. Accordingly, the parent of the leaf
peer must send to the root (maximum) a state-change message
to the affected peers from in the decentralized operation.
78
IV. PERORANCE EVALUATION
The following main metrics of performance are defned.
1) Loss rate: when a peer leaves or fails, some packets
will be lost. The loss rate is the ratio of the total number of
packets lost for all peers to the total number of packets that
should have been received by all peers.
2) End-to-end delay: the sum of the delays associated
with waking up each hop peer and the relaying of a packet to
its next-hop child peers fom the source to the end peer.
The Network Simulator (NS2) [14] was used as the
simulation platform and a GT-ITM Generator [17] was applied
to create a transit-stub graph as the network topology. The
source node was fxed in one stub-domain. First of all, we let k
4. Therefore, each node has at most four children. The
performance of the proposed HRTk architecture was compared
to that of the ZIGZAG approach.
A. Loss Rate
The loss rate is utilized as a metric of service reliability.
When the loss rate is sufciently small, users enjoy high flm
service, even when there is a large amount of leaving peers. In
this scenario, 1000 peers joined the system and 500 peers

1
~7L^\
9 -
8

|u
LvcPoOut
I_. 3. Comparison ofloss rate of HRT4 and Z!LZL
Av0rug Lss Rte Ui
0
08
0
06
C
o
05

04 C
=
0
U?
01
. . . .__. __
10 ZI 3|I 4I 50
|a\c|ccrLun|
_. o. The loss rate of 3upeers departure under HRTj of uupeers
departed subsequently. The constant bit rate (CBR) was used to
simulate media streaming. The packet size of each CBR, or
data stream, was 500 bytes, and the sending interval was 0.01 s
(the media streaming compression rate is 400kbps). Fig.5 plots
the loss rates obtained using the HRT4 mechanism and the
ZIGZAG approach. The proposed HRT limits the loss rate to
under O. 5%. However, for the ZIGZAG approach, when an
associate head departs, the total loss rate increases, because the
associate head must forward data to all peers within its cluster
and to other associate heads in a lower layer (the average loss
rate is 3.5%). Simulation results show that the proposed HRT4
has a lower loss rate than ZIGZAG; thus, the HRT is an
effective and robust P2P system for streaming multimedia data.
To validate the efectiveness of the proposed structure in
real world, some experiments were performed on a PlanetLab
based [9] environment. PlanetLab is one of the real network
test-beds on the Interet. The performance of HRTk under
various network environments (k 3, 4 and 5) are evaluated
with a focus on the following important measures; loss rate
(service reliability) and end-to-end delay (streaming delivery
quality). Three scenarios were examined. A total of 100
PlanetLab peers participated in our experiments. The session
length was 2500 seconds. A source server (root) in our
university delivers video streaming packets to PlanetLab with a
constant bandwidth. The other selected 99 peers were overlay
peers located in different locations of the world. In the absence
Avrug Ls Rte .U
U.
-HR{)
U.8
U.7

t
U.6
C
-
U.
o

U.4
0
U.2
U.I
1U 2 J 4
LavcP rOunt
_. . The loss rale of 3upeers departure under HRT, of uupeers
79
Av0rug0 L KuI0JJJ
0.
0.8
0.7
0.6
0.5

3
0.+
O
0.2
0.1
.1 A
10 20 J 4
LavcPcorOunI
_. . The loss rate of JU peers departure under HRT, of uupeers
of global knowledge of the topology in PlanetLab (and the
Interet), this setup was suitable for testing the proposed
distributed approach in HRTk.
In scenario 1, HRT3 is considered to evaluate the loss rate.
Fig. 6 illustrates the loss rate under 50 peers departure one by
one in HRT3 of 100 peers. The average loss rate was 0.008%.
HRT4 is then considered in scenario 2. Fig.7 depicts that the
average loss rate was 0.0094%. Finally HRT5 is adapted in
scenario 3 and Fig.8 demonstrates the collected average loss
rate of 0.0107%. The experimental results reveal that the loss
rate is relative to the value of k. When one peer possesses more
sub-trees, the peer affects more children peers under the peer
departure. Consequently, the average loss rate of the system is
raised during the children peers not receiving any packets, and
a bigger sub-tree conducts a higher loss rate.
B. End-ta-end Delay
The end-to-end delay is another key metric of overlay
performance. I [4,5], the end-to-end delay was defned as the
number of passing hop peers. We also adopt this defnition but
further provide an evaluation based on the PlanetLab test-bed
environment. Again, HRT3, HRT4, and HRT5 are considered. Fig.
9, 10 and 11 illustrate the average end-to-end delay measured
from the PlanetLab for HRT3, HRT4, and HRT5, respectively. It
A\egeHd+odD|q0.70s
Iu
V
:
D
c
l
0
-HR(3)
J 2J JJ 4 J
La" Peer \
!_. . The end-la-end delay of 50 peers deparure under HRlj of I Upeers
^vcLd-Iodby0b

V

E +
U IU 2U JU 4 b0
\OfLOFf
Fig. 10. The end-la-end delay of 50 peers departure under HRT4 of 100 peers
is interesting to see that for all cases, the measured end-to-end
delay was approximately 0.6 second. The reason to have this
low end-to-end delay is due to with 100 joined peers, the
multicast tree has a height of 3 or 4.
V. CONCLUSION
This study presents the novel HRT architecture for P2P live
multimedia streaming. The ring-tree-based overlay structure
can serve as an infastructure for P2P applications requiring
scalability, high robustness, fast communication, low overhead,
and practicable architectural topolog. The design of the DDR
rings with backup links signifcantly decreases the time
required by a peer to regain data. When one peer leaves, the
DDR ring and backup link quickly change to transmit data and
ensure robustness. The performance of the approach has been
evaluated over the PlanetLab network. Experimental results
indicate that the HRT approach achieves a good overlay
performance in terms of data loss rate, end-to-end delay, and
effectively reduces the related overheads, even when the
number of peers that join/leave is high. This indicates that the
proposed HRT architecture is very suitable for the live
multimedia streaming in multicast on a P2P network.
AvcLd-|odDlq 0.58I75

V
3

'E 4
IK()
10 IS 20 2S 30 35 40 45 0
Lve Pe Lul
Fig. JJ. The end-la-end dela_ of 50 peers departure uder HR1s of 100 peers
80
ACKNOWLEDGMENT
This work was supported by National Science Council
(NSC) of Taiwan under the grant numbers NSC-98-2221-E-
007-060-MY3 and 98-2219-E-007-013.
REFERENCES
[I] A Matrawy, I. Lambadaris, "A Real-Time Video Multicast Architecture
for Assured Forwarding Services," IEEE Transactions on Multimedia,
Vol. 7, No. 4, Aug. 2005, pp.688-699.
[2] B. Gedik, L. Liu, "A Scalable Peer-to-Peer Architecture for Distributed
Information Monitoring Applications," IEEE Transactions on
Computers, Vol. 54, No.6, June 2005, pp.767-782.
[3] B. Ye, M. Guo, D. Chen, and S. Lu, "A Degree-constrained QoS-aware
Routing Algorithm for Application Layer Multicast," lrormation
Sciences, Vol. 177, No. 17, Sep. 2007, pp.3613-3626.
[4] D. A Tran, K. A Hua, and T. Do, "ZIGZAG: An Efficient Peer-to-Peer
Scheme for Media Streaming," In Proc. of IEEE INFOCOM, Mar. 2003,
San Francisco, USA, pp.1283-1292.
[5] D. A Tran, K. A. Hua, and T. Do, "A Peer-to-Peer Architecture for
Media Streaming," IEEE Joural on Selected Areas in Communications
(JSAC), Jan. 2004, pp.121-133.
[6] H.-C. Hsiao and c.-P. He, "A Tree-Based Peer-to-Peer Network with
Quality Guaratees," IEEE Transactions on Parllel and Distributed
Systems, Vol. 19, No. 8, Aug. 2008, pp. 1099-1110.
[7] N. F. Huang, Y. 1. Tzang, H. Y. Chang, C. W. Ho, "Enhancing P2P
Overlay Network Architecture for Live Multimedia Streaming,"
In!ormation Sciences, Vol. 180, No. 17,2010,pp. 3210-3231.
[8] N. F. Huang, Y. 1. Tzang, H. F. Chen, and Y. M. Chu, "Live Multimedia
System Using Peer-to-Peer Architecture for Distance Education," ICWL
2006, LNCS 4181, Sep. 2006, pp.321-335.
[9] PlanetLab website, http://www.planet-lab.org/,2010.
[10] S. Banerjee, B. Bhattacharjee, and C. Kommareddy, "Scalable
Application Layer Multicast," In Proc. of ACM SIGCOMM, Aug. 2002,
Pittsburgh, PA, pp.205-217.
[II] S. Banerjee, C. Kommareddy, K. Kar, B. Bhattacharjee, and S Khuller,
"Construction of an Efficient Overlay Multicast Infrastructure for Real
time Applications," In Proc. of IEEE INFOCOM March 2003, San
Francisco, CA, pp.1521-1531.
[12] S. Liu, Z. S Rui, W. Jiang, 1. Rexford, and M. Chiang, "Performance
Bounds for Peer-Assisted Live Streaming," In Proc. of ACM
SIGMET June 26, 2008, Annapolis, Maryland, USA pp.313-324.
[13] S.-Y. Tseng, Y.-M. Hung, and c.-c. Lin, "Genetic Algorithm for Delay
and Degree-contrained Multimedia Broadcasting on Overlay Networks,"
Computer Communications, 2006, pp.3625-3632.
[14] The Network Simulator NS2 http://www.isi.edu/nsnamlns/.201O.
[15] V. N. Padmanabham, H. J. Wang, P. A Chou, and K. Sripanidkulchai,
"Distributing Streaming Media Content Using Cooperative networking,"
In Proc. of ACM NOSSDAV, May 2002, pp.I77-186.
[16] X. Zhang, 1. Liu, B. Li, and T.-S. P. Yum, "CooIStreaming/DONet: A
Data-driven Overlay Network for Live Media Streaming," In Proc. of
IEEE INFOCOM, Miami, USA, March 2005, Vol. 3. pp.21 02-2 I 11.
[17] Zegura E.W., Calvert K.L., and Bhattacharjee S , How to Model an
Internetwork, In Proc. of IEEE INFOCOM 24-28 March 1996, San
Francisco, CA, USA, pp.594-602.