p2poverlay ashutosh singh

8/6/2019 P2POverlay Ashutosh Singh

1/53

Maintaining Bi-connectivity inOverlay Multicast Networks

Ashutosh Singh

Thesis Supervisor : Prof. Y. N. Singh

Department of Electrical EngineeringIIT Kanpur


2/53

Outline

Introduction

Motivation for Overlay Multicast Networks

Overlay Tree Characterization Overlay Construction and Optimization Schemes

Reliability Enhancement through Bi-connectivity

Proposed approaches toward Bi-connectivity

2


3/53

Unicast and IP Multicast

Unicast

Sending a packet from one sender to one receiver

Point to point delivery (one host to one client) Multicast:

Sending a packet from one sender to multiplereceivers with a single send operation

Multiple destinations (One Host to Many Clients)

3


4/53

Example : Unicast

1

1

1

1

RR1

C

B

A

D

25

1

1

1

1

R2R1

C

B

A

D

25


5/53

Example : IP Multicast

1

1

1

1

R2R1

C

B

A

D

25

5

1

1

1

1

R2R1

C

B

A

D

25


6/53

IP Multicast

IP Multicast was introduced in Steve Deerings

PhD Dissertation in 1988 and first widescale

testing done in 1992 at IETF meeting

Allows data to be sent to multiple receivers in

an efficient way

A single datagram is transmitted

Replicated at a network router

Forwarded on multiple outgoing links in order

to reach the receivers6


7/53

Overlay Multicast

Involves receivers in the replication and

forwarding of data

Receivers setup and maintain an applicationlevel distribution infrastructure

Sender transmits a copy to small number of

receivers, which then make copies itself and

forward these on to other receivers

7


8/53

Example : Overlay Multicast

A

B D

C27

22

1

1

1

1

R2R1

C

B

zA

D

25

8


9/53

IP Multicast : Issues

Requires routers to maintain per group state Scaling constraints

IP Multicast is a best effort Service Provision of higher layer functionalities (reliability,

congestion control & flow control ) more difficult thanin unicast case

IP Multicast calls for changes at the infrastructurallevel

Slow pace of deployment

9


10/53

Overlay Multicast : Features

End systems participating in a multicast group self-organize in to an overlay using a completelydistributed protocol, on top of which multicast trees

can be constructed End System is an entity that actually takes part in a

self-organizing protocol, could be end host or a proxy

End systems attempt to optimize the efficiency of the

overlay by Adapting to network dynamics

Considering application level performance

10


11/53

Overlay Multicast : Features

Multicast related features (group membership,

multicast routing & packet duplication) are

implemented at end systems

All packets are transmitted as unicast packets

Provision of higher-layer functionalities simplified

by deploying application intelligence at internal

splitting points of overlay tree

11


12/53

Overlay Multicast : Performance

Multiple overlay edges traverse the same physical

link , thus redundant traffic on physical links

Communication between end systems involves

traversing other end systems, increasing latency

Though performance penalties are low both from

application and network perspectives

12


13/53

Overlay Multicast : Architecture

Entity that takes part in self organisation protocol

could be an End Host or Proxy

Peer-to-Peer Architecture:

all functionality is pushed to the end hosts actually

participating

each end host maintains state only for those groups it

is actually participating in completely distributed architecture, small and

medium sized groups

e. g. Audio/video conferencing, virtual class room,

multiparty network games 13


14/53

Overlay Multicast : Architecture

Proxy Based Architecture:

organizations deploy proxies at strategic locations on

the Internet

End hosts attaches to the nearest to receive data

using plain unicast

Overlay is composed of proxies, groups are much

larger

e.g. broadcasting , content distribution

14


15/53

Overlay Tree Construction

Direct-Tree approach : members explicitly select their parents from among the

members they know e. g. YOID, OVERCAST

Relies on an overlay tree for both control and datatransmission

Mesh-First approach : to support multi sourceapplications first constructing a richer connected mesh

then constructing a reverse shortest path spanning tree of

the mesh (each tree routed at corresponding source) e.g.NARADA

Tree topology for data and mesh topology for controlinformation (group management functions)

15


16/53

Overlay Tree Characterization

Underlying network G = (N, E) A node n i N denotes a router An edge ( ni , nj ) E denotes a bidirectional physical link

Overlay network, superimposed on G is a tree o = ( s, D, No, Eo )where s is source host,

D is set of receiver hostsNo N is set of nodes in the underlying network G that are

traversed by overlay links

Eo is the set of overlay links Set of hosts Ho = {s} U D and |HO| = n An overlay link eo = (ds , no, .., nls , dr ) Overlay cost = number of underlying hops traversed by all overlay link eo Eo

= ls ( eo )= stress (i) , for every i

ls (e0) denotes the number of router-to-router hops between no, .., nls for theoverlay link e

o ,first and last hops are ignored

Link stress is the total number of identical copies of a packet over the same underlyinglink

Resource usage = delay (i) x stress (i) , for every i

16

Sonia Fahmy et al., Characterizing OMNs and their costs , 2007 PurdueUniversity


17/53

Overlay Tree Characterization

),(),(),(),(1

0

1

!

!l

i

rliior dddelaydddelaydsdelaydslatency

),(

),()(

r

r

r dsdelay

dslatencydtosRDP !

2),(

4),()2),((),(

2),(

),(

1

0

1

!

!

!

rs

l

i

rlsiisos

rs

r

dsl

ddlddldsl

dsl

dshopsstretch

IP

overlay

17


18/53

Overlay Multicast

Source

Routers and

underlying links

Receivers

18


19/53

Metrics: Examples

Overlay link

Source

Receivers

AB

15 ms 15 ms

10 ms

20 ms

C

Overlay cost = 12

Link stress on A = 2 RDP of B = (15+15+10)/20 = 2

19


20/53

Narada:Design Objectives

Self organizing : Overlay Construction should be in fully distributed fashion

robust to dynamic changes in group membership

Self improving Mechanism to gather network information in scalable fashion

Mechanism to incrementally evolve into a better structure

Adaptive to network dynamics: Must adapt to long term variations in path characteristics

Must be resilient to inaccuracies inherent in the measurement

Efficient : Redundant transmission is kept minimal

20

Chu et al., A case for End System Multicast, 2003


21/53

Mesh-first approach : Narada

Group Management Component : ensures thatthe overlay remains connected

Member join

Member leave and failure

Repairing mesh partition

Overlay optimization component : ensures thequality of overlay over time

Addition of good links

Dropping of poor links

21


22/53

Narada : Group Management Each member maintains an updated list of all other members in the group

Let i receive refresh message from neighbor j at is local time t.

Let < k, skj> be an entry in js refresh message

if i does not have an entry for k, then i inserts the entry < k, skj, t > into its table

else if is entry for k is < k, ski, tki> then

if ski>= skj, i ignores the entry pertaining to k else i updates its entry for k to < k, skj, t >

Member join :

member is able to get a list of group members that contain at least onecurrently active group member (bootstrap mechanism)

Joining member randomly selects a few group members from the list availableto it and sends them request

Repeats the process until it gets a response from some member and joins asits neighbor

Starts exchanging REFRESH messages with neighbors

22


23/53

Narada : Group Management

Member leave and failure : Leaves gracefully:

notifies its neighbors, information is propagated,

continues forwarding packets for some time to minimize transient loss

Abrupt Failure: failure is detected locally and propagated

Each member needs to retain entries for dead members for some time

23

A sample overlay topology

E

F

B A G

C

D


24/53

Narada : Group Management

24

Repairing mesh partitions : Each member maintains a queue of members that it has

stopped receiving updates for more than Tm time

Deleted member is probed and determined to be dead or a link

is added to it A scheduling algorithm periodically and probabilistically deletes

a member from the head of the queue

Period adjusted so that no entry remains in the queue for more

than a bounded period of time

Probability chosen so that in spite of several members

simultaneously attempting to repair, only a small number of

new links are added


25/53

Narada : Optimization

Adding : Every member periodically probes some random member that is not a

neighbor

new link may be added on the perceived gain in utility in doing so

Dropping : cost of a link between i and j in is perception is the number of group

members for which i uses j as next hop. Consensus cost of its link to every neighbor is computed

Link with lowest consensus cost is dropped if below threshold

Comparison of Narada with IP Multicast :

25

Small group

(20 members)

Medium sized group

(128 members)

BW performance

(resources consumed)

Comparable twice

Mean receiver latencies 1.3 1.5 times 2.2 2.8 times


26/53

Narada : Performance Metrics

Latency: measures the end-to-end delay from the source to the receiversas seen by the application

Bandwidth : measures the application level throughput at the receiverand is an indicator of quality of received video

Protocol Overhead: equals to

Resource Usage :

resource usage overlay tree = cost of constituent overlay links

costan overlay link

= cost of constituent physical links

cost a physical link = propagation delay of that link

resource usage IP Multicast = cost of physical links of the native IP Multicast tree

networktheentersthattrafficdataofbytestotal

networktheentersthattrafficdatanonofbytestotal

26


27/53

OMNI Infrastructure

Service providers deploy a set of service nodes (MSNs)

MSNs are organized into an overlay

Degree constrained minimum average latency problem :

Find a directed spanning tree, T of G rooted at the MSN r,satisfying the degree-constraint at each node, such that

i belongs to S ci Lr,i is minimizedWhere S is the set of all MSNs other than source

ci is the number of clients served by MSN i

Lr i

is the overlay latency from root MSN to MSN i

Each MSN i keeps following state information :

Unicast latency between itself and its tree neighbors

Overlay path from root to itself

Si and ^i

27

Suman Banerjee, Construction of an efficient OM infrastructure .. , 2003


28/53

OMNI Infrastructure

23,6,3,0

14,8,6,1,5,3

!!!!!!

!!!!!!

ABCDEF

ABCDEF SSSSSS

28

A

B C

DE

F

Source

OMNI Architecture

MSNs

Clients

Service area ofMSNs


29/53

OMNI Infrastructure

Initialization Phase: Each MSN measures unicast latency between itself and root, sends

join request to root MSN

Root MSN gathers join requests from all MSNs, creates initial treeusing centralized algorithm and distributes it to MSNs

Overlay latency from root to any other MSN I is bounded by 2 lri log N

Transformation Phase : Local Transformation

Child promote

Parent child swap Iso-level-2 swap

Iso- level- 2 transfer

Aniso-level-1-2 swap

Probabilistic Transformation

29


30/53

OMNI Infrastructure

30

Initialization phase

Parent-child swap

Child-promote


31/53

OMNI Infrastructure

31Aniso-level-1-2 swap

Iso-level-2 swap


32/53

Conferencing Application andOverlay Design

Performance requirements: low latencies , high

bandwidth between source and receivers

Gracefully degradable : can tolerate loss through aquality degradation

Session lengths : long-lived, lasting tens of minutes

Group characteristics : dynamic small group

Source transmission patterns :

source transmits data at a fixed rate

Any member can be the source, usually a single source at a

time 32

Chu et al., Enabling conferencing applications on the I-net using OMA 2004


33/53

Conferencing Application:Large Group

Source based tree approach:

efficient for small group, as group size increases, control

overhead increases very rapidly

Single shared tree approach: scalable, but depth of tree will be high due to out degree

bound and hence high latency. Suitable for non-interactive

application (VOD)

As the number of trees increase, Fault toleranceincreases, delay decreases but protocol overhead

increases.

33

Baosong et al.,DualCast: Protocol Design of Multiple shared tree based ALM 2008


34/53

Conferencing Application:Large Group

Multiple shared tree approach (MST):

number of total trees are far less than total number of

sources hence overhead not so large

Tree depth is also not so high hence delay is controlled

Source nodes and listener nodes are treated differently

34

Baosong et al.,DualCast: Protocol Design of Multiple shared tree based ALM 2008


35/53

Problem statement

Construction ofan Overlay Multicast Network for

lecture delivery to a medium sized dynamic group

To build a simulator for Overlay Multicasting Networks

To verify the result of various researchers and hence toverify the simulator built

Analyzing specific characteristics of lecture delivery

application and applying them to get improved

optimization algorithm and node failure detecting and

repairing algorithms for better transmission efficiency,

lower overall latency and higher system stability

35


36/53

Reliability Through Bi-connectivity:Proposed Approaches

Reliability can be achieved by maintaining Bi-

connectivity between any pair ofnodes in the

network

For Mesh-First Protocol: A bi-connected mesh like topologyis created first, on top of that a single or multiple data

delivery trees are built

For Direct-Tree protocol: Two different approaches in each

of which every host gets data feed from two different

paths Connected Leaf-nodes Approach

Child-Grandparent Approach

36


37/53

Approach 1

Each new node connects to two already existing

nodes in the network

In the beginning when first node comes, there is no

network

Second node joins to this first node

Third node connects to the first and second node forming

a triangle

Fourth node connects to any two of three nodes

Fifth node sees nodes 1 and 4 as having least degree and

connects to the first and fourth node

Continuing this way, a bi-connected mesh is formed

37


38/53

Approach 1

38


39/53

Approach 1

39


40/53

Approach 1: The Basic Concept

40


41/53

Approach 1 : Node Failure

41

X

X

XX


42/53

Approach 1 : Average Degreeof Nodes

42

Average degree of network

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 50 100 150 200

number of nodes in the network

AverageD

egree

nodesofnumbertotal

nnodeofree

nodesofreeAverage

N

n

!! 1

deg

deg


43/53

Approach 1 : Average numberof hops required

43

Average steps to find path

0

5

10

15

20

25

30

35

40

0 50 100 150 200

Number of nodes in the network

Averagesteps


44/53

Approach 2:Connected Child Grandparent

Bi-connectivity in a distribution tree is achieved by

connecting all the nodes to their grandparent

In case grandparent is not available, the node is connected

to its sibling

A 4-level complete binary tree is considered as an example

This is a brute-force approach, a better approach

(Connected leaf nodes approach) needs only half the

number of additional links than this approach

44


45/53

Approach 2

45


46/53

Approach 3:Connected Leaf nodes

Bi-connectivity in a distribution tree is achieved by

connecting pairing all leafnodes

Each node pair gets bi-connected, as rings are formed

between any pair of nodes through leaf nodes

A 4-level complete binary tree is considered as an example

For a complete binary tree, the number of additional links

required is (n-1)/2 , where n is the number of nodes in the

network

46


47/53

Approach 3

47


48/53

Connected Leaf Nodes VsChild-Grandparent Approach

48

Additional links required to achieve biconnectivity

0

50

100

150

200

250

300

0 100 200 300

No. of users in the network

N

o.

ofadditionallink

s

required

child- grand parent

approach

leaf node approach


49/53

References

1. Ayman El-Sayed, Vincent Roca, and Laurent Mathy, A surveyofproposalsforanalternativegroupco unicationservice, IEEE Network, special issue onMulticasting: an enabling technology, January/February 2003.

2. Mojtaba Hosseini, Dewan Tanvir Ahmed, Servin Shirmohammadi, and Nicolas D.Georganas, Asurveyofapplication-layermulticastprotocols, IEEECommunications Surveys and Tutorials, 3rd Quarter 2007.

3. Konstantin Andreev, Bruce M. Maggs, Adam Meyerson, and Ramesh K. Sitaraman,

DesigningOverlay MulticastNetworksForStreaming , Symposium onParallelism in Algorithms and Architectures, June7-9, 2003.

4. Sonia Fahmy, and Minseok Kwon,CharacterizingOverlay MulticastNetworksandtheircosts, IEEE/ACM Transaction on Networking, Vol. 15, No. 2, April 2007.

5. Sonia Fahmy, and Minseok Kwon,CharacterizingOverlay MulticastNetworks,11th IEEE International Conference on Network Protocols2003.

6. Suman Banerjee, Seungjoon Lee, Bobby Bhattacharjee, and Aravind Srinivasan,

ResilientMulticastUsingOverlays, IEEE/ACM Transaction on Networking, Vol.14, No. 2, April 2006.

7. Vinay Pai, Kapil Kumar, Karthik Tamilmani, Vinay Sambamurthy, and Alexander E.Mohr,Chainsaw:EliminatingTreesfrom Overlay Multicast , Proceedings ofInternational workshop on Peer-To-Peer Systems (IPTPS) 2005

49


50/53

References8

.Z

haoping Wang, Xuesong Cao, and Ruimin Hu,A

daptedRouting

Algorith

min

the

Overlay Multicast , Proceedings of 2007 International Symposium on IntelligentSignal Processing and Communication Systems Nov.28-Dec.1, 2007.

9. Tin-Man T. Kwan, and Kwan L. Yeung,On Overlay MulticastTree ConstructionandMaintenance, International Conference on Collaborative Computing:Networking, Applications and Worksharing, 2005.

10. Dejan Kostic, Adolfo Rodriguez, Jeannie Albrecht, and Amin Vahdat, Bullet: HighBandwidthDataDissemination Usingan Overlay Mesh, Symposium on OperatingSystems Principles (SOSP) 2003.

11. Yang-hua Chu, Sanjay G. Rao, Srinivasan Seshan, and Hui Zhang, A CaseforEndSystem Multicast , Proceedings of ACM Sigmetrics 2000.

12. Suman Banerjee, Christopher Kommareddy, Koushik Kar, Bobby Bhattacharjee,Samir Khuller,Construction ofanEfficientOverlay MulticastInfrastructurefor

Real-time Applications, IEEE 2003.13. Christophe Diot, Brian Neil Levine, Bryan Lyles, Hassan Kassem, and Doug

Balensiefen, DeploymentIssuesfortheIPMulticastServiceandArchitecture,

IEEE Network 2000.14. Li Xing-feng, Yan Bao-ping, and Luo Wan-ming,Overlay multicastnetworkoptimizationandsimulation Basedon NaradaProtocol ,10th InternationalConference on Advanced Communication Technology (ICACT) 2008.

15. Radia Perlman,AnalgorithmfordistributedComputationofaspanningTreeinanExtendedLAN ,1985 ACM

50


51/53

References

16. Yang-hua Chu, Sanjay G. Rao, Srinivasan Seshan and Hui Zhang,Adapted Enablingconferencingapplicationsontheinternetusinganoverlay Multicastarchitecture,

SIGCOMM 2001

17. Li Lao,Jun-Hong Cui, Mario Gerla, Shigang Chen,Ascalableoverlay MulticastArchitectureforLarge-scaleapplications ,IEEE transaction on parallel and distributed

systems April 2007

18. Jianqun Cui,MoreEfficient Mechanism ofTopology-Aware Overlay Constructionin ALM ,

International conference on Networking, Architecture and Storage 200719. Yang Hongyun,Hu Ruiming, Chen Jun, and Chen Xuhui,AReviewofResilient Approachesto

Peer-to-Peer Overlay MulticastforMediaStreaming ,2008 IEEE

20. Thilmee M. Baduge, Akihito Hiromori, Hirozumi Yamaguchi, Teruo Higashino,A distributed

algorithm forconstructing minimum delayspanningtreesunderbandwidthconstraintson

overlaynetworks,wiley intersciencejournals october 2006

21. Shan Baosong, Liaiang Yuan,Zhou Mi and Lou Yihua, DualCast:ProtocolDesignof

MultipleSharedTrees BasedApplication LayerMulticast ,14th IEEE International

Conference on Parallel and Distributed Systems 2008

22. Changlai Du, Hao Yin, Chuang Lin, Yada Hu, VCNF: A SecureVideo ConferencingSystem

BasedonP2PTechnology,10th IEEE International Conference on High Performance

Computing and Communications 2008

51


52/53

52


53/53

MBone

Mbone was deployment of virtual multicast

network

Unicast encapsulated Multicast packets

received and forwarded

Connectivity through point-to-point IP

encapsulated tunnels

Each tunnel connected 2 endpoints via one

logical links but could cross several routers

Routing decisions made using DVMRP53

p2poverlay ashutosh singh

Documents