In this chapter, we first take an overview of a one-to-many streaming system and address the situation of rendezvous nodes such as proxy relay servers to bring up the need of an efficient relay data path. A survey and comparison of relay data path solution are presented to point out the overhead of current relay data path solutions.
2.1. Overview of One-to-Many Streaming Systems
According to the deployment policy, three kinds of one-to-many streaming systems exist: 1) peer-to-peer, 2) proxy-based and 3) hybrid. A peer-to-peer system benefits from the low cost of deployment. A media provider multicasts its media stream with the assistance of the overlay network formed by peers. Nevertheless, the system is unstable because of the high variation of peers. Proxy-based systems such as traditional content delivery networks (CDNs) use dedicated proxy relay servers to provide more bandwidth and stability than a peer-to-peer system. However, it suffers high deployment costs. For a CDN service provider, a hybrid solution using proxy relay servers and super peers as the backbone could reach the balance and is a realistic solution.
Figure 1 shows the topology of a hybrid one-to-many streaming system with two streaming sessions. Once a peer wants to publish or subscribe a streaming session, it connects to the proxy relay server which services the designated domain it belongs to.
If a media provider and its media consumers are not in the same designated domain, an inter-proxy-relay connection is setup to forward media streams. With stability and enough outbound bandwidth, a peer can become a super peer to alleviate the loads of proxy relay servers.
In such a system, proxy relay servers are responsible to a large amount of fan-out burdens and service a large number of streaming sessions simultaneously, while super
5
peers usually have limited computing power due to the hardware capability or system policies. For these nodes, an efficient streaming relay data path can enhance the single-node performance to provide large service capability while the bandwidth is sufficient or to reduce the computing power requirement under the same relay loads.
2.2. Relay Data Path Solutions
A relay data path continuously forwards media streams from the source to the sink(s). The media streams passing through different data access interfaces incur different kinds of overheads. In summary, relay data paths can be classified into three kinds of solutions as: solutions with socket API, solutions on IP layer hooks and solutions on top of I/O subsystems.
Solutions with Socket API
Solutions with socket API relay media streams in the user space through the socket interface. After the incoming media streams go through the network stack, they are stored in the receiving queue of the source socket within the kernel space. The
Figure 1: One-to-many streaming system topology with two streaming sessions.
6
relay mechanism copies media streams to the user space buffer and then passes them to the sending queue of the sink sockets inside the kernel space for further delivery.
Because media streams are copied across the user-kernel boundary, this kind of solutions incurs a large amount of system calls and memory copies. Icecast [11] and DSS [12] are the solutions using the socket API to implement one-to-many streaming relay. The former is capable of TCP streaming whereas the latter considers UDP streaming.
Solutions on IP Layer Hooks
An in-kernel relay data path can prevent the overheads of copying data across the user-kernel boundary. To build an in-kernel relay data path, IP layer hooks such as hooks provided by netfilter [17] in linux-based systems allow kernel modules to register callback functions within the IP layer. Relaying media streams on IP layer hooks prevents media streams from copied across the user-kernel boundary. Because the media streams are not passed through the whole network stack, the tasks of transport layer, especially TCP, should be handled by the relay solution. Therefore the maintenance cost is high when the transport layer protocol evolves. TCPSP [15] and Media Proxy [16] both build relay mechanisms on IP layer hooks with the header-altering method, supporting only one-to-one relay scheme.
Solutions on top of I/O subsystems
Another kind of in-kernel relay data path solution is to build relay mechanisms on top of I/O subsystems. This kind of solutions not only prevents the overheads of copying data across the user-kernel boundary but also suffers less maintenance overheads when the transport layer protocol evolves. KStreams [13] makes a data abstraction layer on top of I/O subsystems. By the data abstraction layer, KStreams can relay media streams between different kinds of I/O subsystems and supports one-to-many relay schemes. However, the memory copy from the source to the sinks
7
is still needed.
Summary
According to the data access interface, a relay data path suffers different kinds of overheads. Table 1 shows a comparison among different relay data path solutions.
In-kernel relay data paths such as the solutions on IP layer hooks and the solutions on top of I/O subsystems do not suffer the crossing user-kernel overheads and perform better than the solutions with socket API. Because of the lack of transport layer protocol handling, the solutions on IP layer hooks need to handle transport layer protocol by themselves. Hence the additional maintenance overheads are caused.
Although the solutions on top of I/O subsystems are better than the other solutions, they still need in-kernel memory copies to sinks. The memory copy degrades the performance of relay, especially in the one-to-many relay scheme.
Table 1: Relay data path solutions.
Data access
interface Solution Relay scheme Protocol Cons/Overheads
Socket API
8