This paper presents a video streaming system (or live video delivery) which combine centralized control and distributed control to achieve better performance.
1 What does exist live video delivery system look like?
Live video delivery is challenging nowadays but exist solutions for it have drawbacks. Authors list 3 types of solutions:
Traffic engineering: Collecting traffic information in the whole Internet and calculate the best strategy of forwarding requests.
Drawbacks: even state-of-art systems work on traffic aggregates at coarse timescales. It is difficult to control the traffic in real-time.
Overlay multicast system: individual stream optimization. Each video channel individually computes the distribution tree with the highest quality.
Drawbacks: Overlook issues that arise with the many concurrent, independent, high-bandwidth streams in today’s environment.
Video-specific CDN system: Client-side analytics to pick the best CDN for a given client at a given time but ignore the actual data delivery.
Drawbacks: Some evidences show that a centralized video controller algorithm could greatly improve QoE. But CDN cannot do centralized control.
2 What does a “good” live video delivery system should be look like?
- Enables proactive control over cost and quality at fine-grained timescales.
- Scales to today’s largest CDNs and their workloads.
- Achieves real-time responsiveness to minimize join time and respond to failures.
- Meets these goals despite wide-area network delays and failures.
3 So what do authors do to solve the problem?
Present an improvement of CDN system (the 3rd type I listed above) ——VDN. VDN use hybrid control: consists of a centralized control and a distributed control. Centralized control is used for improving QoE greatly. Distributed control is used for avoiding the problem of timescale. It can take advantages of the 1st method (traffic engineering) and the 3rd method (CDN system).
4 Hybrid Control
Centralized controller collects information in the whole Internet, and calculate the best forwarding strategy, then send each node’s strategy to the corresponding node. When receiving strategy, node records it in its FIB. (refresh every 1 minutes)
When receiving request, if FIB hits the request, forward it according to FIB. If misses, or link changes, or link, node, controller fails, node forwards the request according to its distributed controller.
4.1 Centralized controller
Centralized controller runs an integer program to determine the distribution tree for every requested video.
4.2 Distributed controller
d(v, b) denotes the distance to video v with bit-rate b.
If a node is subscribed to (v, b), d(v, b) of this node is 0. Subscribe means this node is receiving (v, b) now. Because this paper focuses on live video delivery, a node doesn’t cache past videos.
Then nodes use distance-vector method to calculate d(v, b) for all v and all b.
When a node need to do distributed controller for a request, it randomly pick a upstream node that has a min-hop path to (v, b) with enough capacity to support delivery.
5 Some thought
- This method is a good solution for live video delivery. But in VoD scenario, it can not work well since it is difficult to form a distribution tree in VoD. Apparently, solve the video delivery problem in VoD is quite more difficult then solve the problem in live video delivery. Then can we present a solution for VoD? (although I think it will be a hard work)
- Although this paper present a integer program to solve the traffic engineering problem, the bit-rate of each client is completely decided by client itself. Client has no knowledge of the network topology. So can we further improve the performance by including the bit-rate choosing problem into the integer program?