HPAM: Hybrid Protocol for Application Level Multicast. Yeo Chai Kiat

Transcription

1 HPAM: Hybrid Protocol for Application Level Multicast Yeo Chai Kiat

2 Scope 1. Introduction 2. Hybrid Protocol for Application Level Multicast (HPAM) 3. Features of HPAM 4. Conclusion

3 1. Introduction Video Streams over Internet The Internet poses a serious challenge to traditional TV and cable TV providers. AccuStream imedia Research reported a total of 18 billion video streams served in It projected the total annual video streams will reach 28 billion in Delivery of live video is a capability that is unique to the Internet.

4 Implications of Live Streaming Live content does not allow the user to revisit the content in future. More demanding on content server performing admission control and delivering a level of Quality of Service (QoS) acceptable to user. Conventionally, overloaded server rejects new requests. Unacceptable since the value of its content is in its liveness Denial of Service! Latency in servicing requests is less tolerable as users would wish to partake in the session as soon as possible so as not to miss any live action. Users are more tolerant of a lower QoS and will continue viewing since they do not wish to miss the action.

5 Mode of Delivery - Unicast Conventional point-to-point unicast protocol from the source to the multiple destinations. Inefficient and non-scaleable. Duplication of data by source to each and every client in the group. Source becomes a hot-spot leading to network congestion and server overload. S 1 R1 18 R2 1 D1 2 2 D3 D2

6 Mode of Delivery IP Multicast Regarded as ideal for multipoint communication as it is inherently bandwidth efficient and scaleable. Reserves a set of addresses to identify groups of receivers. Source only needs to send a single copy of its datagram. Data forwarding is effected along a distribution tree which spans all members of a group. S 1 R1 18 R2 1 D1 2 2 D3 D2

7 Difficult to ensure scaleability and consistency with distributed multicast address allocation as every group needs to dynamically obtain a globally unique address from the limited multicast address space. Problems with IP Multicast Routers need to maintain separate routing state for each multicast group resulting in high complexity and serious scaling constraints at the IP layer. Lack of access control as any arbitrary source can send data to any arbitrary group. Groups entail complicated membership control as well as network management and provisioning.

8 Problems with IP Multicast (cont.) Provides best effort service. More challenging than unicast to provide higher level features such as reliability, flow and congestion control, security. Entails substantial modifications at the infrastructural level given the fairly elaborate control support from the routers, in particular membership management and multicast routing protocols. Absence of a widely accepted, efficient, scaleable and deployable protocol for inter-domain multicast routing (eg. PIM, BGMP, MBGP, MSDP). Hence, not widely deployed by ISPs.

9 Mode of Delivery Application Level Multicast Multicast functionality is moved from routers to end users, i.e. from network layer to application layer. End users are connected via a virtual network with each edge connecting a pair of end users corresponding to a unicast path between them in the physical network. S 1 R1 18 R2 1 D1 2 2 D3 D2

10 Application Level Multicast (cont.) Data is routed via this virtual overlay network to reach all members without any support from the routers beyond regular unicast transport service. Not as bandwidth efficient as IP multicast but more efficient than naïve unicast. Data path between end users tends to incur higher latencies compared to IP multicast as overlay paths are incongruent to the underlying physical network. No need for a global group identifier such as an IP multicast address. Easily deployable. Can leverage on services such as flow control, congestion control, reliable delivery, available to unicast.

11 Objectives Design an application layer multicast protocol to support live video streaming applications. Minimize delay and loss in data delivery. Investigate the effects of single performance metric (i.e. latency, loss) and their combination on the data delivery efficiency of the protocol.

12 2. HPAM Properties Goal: Minimize delay and data loss Topology Design: Topology-Aware Tree, Flat Delivery Type: Best Effort Source Model: Source Specific Use of Proxy: Peer-to-Peer based Algorithm Type: Distributed with Lightweight Central Directory Server

13 Three main entities: HPAM Overview Centralized, lightweight directory server (DS). Overlay data distribution tree comprising end users built on the fly. Protocol control mechanisms (gossips, spirals, updates, RTT tests etc.). Directory Server Source e a, e b c d Local Multicast Network Legend: Unicast Data Paths Control Messages Multicast

14 HPAM Operation New clients join the multicast group by seeking the assistance of DS. DS returns a set of potential parent candidates to new clients. New clients will conduct RTT measurements to select the parent who will provide the best latency to the root or source of the overlay tree (hereinafter referred to as the root-latency) for HPAM. For HPAM-D, the new parent must also satisfy an acceptable loss rate.

15 3. Features of HPAM 1. Hybrid Approach to Overlay Tree Construction, Refinement and Repair. 2. JoinSource&Adopt (JSA) Algorithm for placement of latency-efficient clients just below the root. 3. Gossip and Spiral Mechanisms to improve tree robustness and speed up partition repair. 4. Use of loss rate as a 2 nd metric to improve QoS. 5. Self-improving Overlay Tree: Proactive and Reactive Refinements via Gossip mechanism. 6. Relative Loss Rate based Heuristics for Local Congestion Detection.

16 3.1 Hybrid Approach to Overlay Tree Construction, Refinement and Repair Exploits simplicity and resourcefulness of lightweight, centralized controller, DS. Speeds up distributed tree construction by providing a new client with a list of possible parents. Acts as reliable and fast back-up during recovery from tree partition if distributed algorithm fails. Does not perform routing computation and topology management. Does not stream data. Data distribution still continues even with DS failure. Only glitch is new clients will be prevented from joining the groups. Integrates the robustness and scaleability of distributed clients. Clients are responsible for tree construction, refinement, repair and routing and data distribution.

17 3.2 JoinSource&Adopt (JSA) Algorithm Problem faced by protocols building trees on the fly is that the resulting tree is very much dependent on the order of join of the clients. Latency-inefficient clients hogging Level 1 of the tree (nearest to the root) increases the latency of all clients downstream of the branch. HPAM alleviates the latency degradation by optimizing the latency efficiency of clients at Level 1 using the JSA algorithm.

18 JoinSource&Adopt (JSA) Algorithm (cont.) If new client, m, is less latency-efficient than existing level 1 clients, it will perform the normal join process to a potential parent who can yield the best rootlatency. If m is closer to the root than existing level 1 clients, m will replace the least latency-efficient level 1 client and join the root of the tree. It will then adopt the displaced level 1 client as its child. Latency i, m = ul i, r ul m, r Latency i, m > L hysteresis * ul i, r where i level 1 clients m is the new client ul is unicast latency r is the root L hysteresis > 0

19 3.3 Gossip and Spiral Mechanisms Improve Tree Robustness and Speed up Partition Recovery with 3-layer strategy: - Layer 1: Hot standby spiral node to adopt orphaned client up to 1 slot beyond its capacity. - Layer 2: Ready list in gossip cache as potential parents for orphaned client should spiral node be full or fails. - Layer 3: Issue join request to DS to rejoin session.

20 Spiral Mechanism Phase 1: Spiral node assigned during join. Phase 2: Choose best gossip candidate as spiral node. Source Level 1 Clients C1 C2 C3 Level 2 Clients C4 C5 C6 C7 C8 Level 3 Clients C9 C10 C11 C12 Level 4 Clients C13 Phase 1: Initial spiral connections Phase 2: New spiral connections Unicast data connections

21 Gossip Mechanism Source Failure of C4 partitions the tree into 2 parts. C4 C1 C5 C2 C3 C8 C1 Source C2 C3 X C6 C7 C9 C10 C11 C12 C5 C6 C7 C9 C8 C13 C10 C11 C12 C13 (a) (b) X Failed Client Unicast data connections Gossip flows New tree branch with adopted client

22 Gossip Mechanism (cont.) Initial gossip cache formed from potential parent list returned by DS. Periodic information exchanges between client and gossiper (eg. Root latency, loss rate, level number). Gossip cache ranked in order of client s root latency if it were to use the gossiper as a parent. Gossip cache refreshed via: Removing gossipers who are full, have poor QoS, have left or have failed. Gossipers supplying client with random selection of gossipers from its own gossip cache. Client requesting DS for supply of fresh parent candidates when gossip cache dwindles below 1/3 of full capacity.

23 3.4 Loss Rate as Second Metric (HPAM-D) Allows HPAM to minimize the latency to root together with maintaining a high percentage of clients experiencing satisfactory loss rates. Little overhead as loss rate can be gleaned from the data packets measured. Latency is over loss rate since gossip cache is ranked in order of latency.

24 3.5 Self-Improving Overlay Tree Proactive tree refinement is periodically carried out by individual clients. Tree refinement is effected via a client switching to a parent which will provide it with a better QoS. The gossiper who yields the best QoS gain for the client is chosen to be the new parent. where i gossip cache Latency i = ( uli, r + uli, n ) uln, r QoSGain i = Latency C i C hysteresis hysteresis * ul n, r * ul n, r n is the client ul is unicast latency r is the root C hysteresis > 0

25 Proactive Tree Refinement (cont.) For HPAM-D QoSGain And Eqn i = Latency C hysteresis Loss( i) i C hysteresis * ul L th n, r * ul n, r where i gossip cache n is the client ul is unicast latency r is the root C hysteresis > 0 L th is acceptable loss rate

26 For HPAM-D. Reactive Tree Refinement Reactive tree refinement kicks in when client experiences unsatisfactory loss rate i.e. loss rate > L th Switch to gossiper who satisfies Eqn. 3.4.

27 3.6 Relative Loss Rate based Heuristics for Local Congestion Detection Use of Relative Loss Rate to detect local congestion: RLR client = LossRate client 1 LossRate LossRate parent parent Detection of local congestion can reduce latency and loss rate as well as protocol overheads. Client can switch to alternate parent if the current overlay link between itself and its parent is bad. Reduce unnecessary parent switching since congestion is not between the client and its current parent.

28 Heuristics for Local Congestion Detection Parent Client Action LR LR RLR Case 1 L th L th x None Case 2 L th > L th x Local congestion. Switch parent. Case 3 > L th > L th > L th Likely local congestion. Switch parent. Case 4 > L th > L th L th Minimal local congestion. Wait for parent to switch first. If parent fails to switch, then start to switch parent. x: don t care L th : Acceptable loss rate

29 4. Conclusion HPAM Strength in simplicity Quick in constructing efficient overlay trees Combination of lightweight, centralized DS with distributed tree building, refinement and repair techniques allow a faster join, swifter partition recovery compared to distributed protocols. Responsive to changes in membership dynamics which is achieved at very much lower overheads.

30 HPAM-D Managed to maintain the level of optimality as per HPAM in terms of latency but is also able to maintain a high percentage of acceptable loss rates Achieved with negligible protocol overhead as loss rate can be gleaned from the received data stream Using RLR heuristics allows it to detect local congestion to reduce unnecessary parent switches End result - Reduces protocol overheads - Maintains low loss rate without compromising latency performance

31 HPAM is not as efficient as IP multicast but it presents a simple and easily deployable solution. Summary An application level multicast protocol (HPAM), for efficient live media streaming over the Internet without IP multicast support is proposed. HPAM is able to deliver high QoS to its clients and is responsive to group and environment changes; achieved with reasonable protocol overheads and network stress. HPAM features a hybrid combination of centralized server and distributed tree building, refinement and repair algorithms, gossip, spiral mechanisms, JSA algorithm, use of single and dual metrics, RLR heuristics for local congestion detection.