The multimedia content can be encoded in many different formats, that suit specific needs or capabilities of the network and the listening clients. In some cases (e. g. MPEG-4 for- mats) the highest quality format can be decomposed into N different layers (groups) that are sent over network independently. When native multicast is used, the client subscribes
4.4. CONTENT ORGANIZATION 28 170 180 190 200 210 220 230 time [s] 0 5 10 15 20 25 30
received packets per second
FIGURE4.7: Recovery time for with backup SPT (solid line) and without it (dashed
line) simulated usingcnet-based network simulator.
for the first M ∈ h1; Ni groups only, thus controlling the quality reduction of received con- tent. With native multicast, there is no easy way to prioritize and synchronize the streams, which may lead to unexpected loss of quality (if data in the first layer are lost, the other layers may render useless).
As AEs support also multimedia transcoding (capable of beingactive gateways), an ex- tended approach can be used. The format decomposition or even transcoding to com- pletely different format may be performed by an AE, providing a flexible on demand service–the transcoding occurs only if really needed by some client. Also, the AEs are capable of synchronizing individual streams—they “understand” the decomposition and may re-synchronize individual streams. In case of severe overload, the higher (less impor- tant) stream layers are dropped first (again, AEs know the hierarchy), so the transmission quality is minimally affected.
To formalize our approach, we have designed three layer hierarchy:
• content groups—the highest level, an aggregation of several contents; it can be for in- stance a videoconferencing group (e. g. video and audio streams of individual video- conference participants)
• content—intermediate level, a content (a video stream, format independent) • format—the lowest level, format definition.
A multimedia stream is then characterized by(content_group, content, format)
triplet. The available formats for each content create an oriented graph where the root is the source format and the child nodes define the formats created from their parents. A client can choose the best suitable format, or different formats for different contents within one content group (e. g. a lecturer’s stream with the highest quality).
The information about available content groups, content, and available formats is pub- lished via NIS on AEs and is distributed and shared across the network of AEs.
Chapter 5
Distributed Active Element
Scalability based on networks of active elements as discussed in Chapter 4 is working well in terms of number of clients connected. It is however not sufficient for scalability with respect to bandwidth of each single stream distributed, i. e. it is not suitable for distributing streams whose bandwidth exceeds capacity of each single AE. This is the case e. g. when distributing 1.486 Gbps uncompressed high-definition video using AEs with only Gigabit Ethernet or even Fast Ethernet network interfaces.
In order to improves scalability with respect to the bandwidth of each stream, we intro- duce a concept of distributed active element, suitable for implementing on computer clus- ters with low-latency internal interconnection. Its architecture is based on parallelizing all modules of general AE architecture shown in Figure 4.1 on page 16 including both listener and sender modules, actually creating multiple AE instances. Of course it would be pos- sible to implement distributed AE using simple distribution of modules and exchanging necessary information using some message passing. However, as the cluster environments don’t operate over shared memory, it would require transmission of very significant data volumes between machines in the cluster and thus pessimizing performance. Minimizing synchronization and internal communication overhead allows for additional performance optimizations.
Complete parallelization of AE architecture however introduces problems with send- ing part, which may introduce packet reordering. While packet reordering is largely un- wanted for general router behavior as it may severely tamper performance of lots of ap- plication and especially those based on the most widely used transmission protocol TCP, it is more acceptable for multimedia application that rely on UDP protocol and thus need to handle packet reordering on its own, usually by data buffering1. Furthermore, as the
UDP generally doesn’t use any flow control mechanism based on implicit response of the network (like packet loss, or indirectly packet reordering incorrectly detected as packet loss), packet reordering doesn’t influence performance of the multimedia application and it only imposes additional requirements on buffer sizes and thus indirectly may introduce additional latency. Simple solution to reordering would be to design architecture with all distributed modules except for sender module—this would help for computationally intensive operations on the streams but it wouldn’t help with high-bandwidth streams which exceed capacity of each single cluster node. In this chapter we show, that even when having multiple sending modules with no explicit synchronization, the reordering 1For instance ITU-T G.1010 specification recommends that multimedia application buffer as much as 10 sec-
onds of video to avoid effects due to packet reordering. Although this is clearly not desirable for synchronous interactive applications because of increasing latency of transmission, it stresses the fact that packet reordering effects are well understood by application designers and thus handled by most of multimedia applications to some extent. Actually, because for synchronous applications it is usually unacceptable to use retransmission to replace packet loss especially when it comes to high-bandwidth data flows, most applications implement some scheme to mitigate even packet loss: be it limited redundancy, forward error correction, interleaving or some other mechanism.
5.1. ARCHITECTURE 30