Architectural overview of the proposed overlay network. 

Context in source publication

Context 1

... fluid operation. As another example, packet loss has severe consequences for video streaming services since it will rapidly degrade playback at receiver-side due to the introduction of visual artifacts. Complicating matters even further is the fact that, due to the recent popularization of mobile computing, service providers are increasingly targeting not only fixed but also mobile customers. Since fixed and mobile devices as well as networks have largely divergent capabilities, a highly heterogeneous usage environment is created, which in turn results in growing service dependability as well as adaptation requirements. Unfortunately, the current generation of networks is not always capable of guaranteeing that the requirements im- posed by multimedia services are satisfied. For instance, the Internet only provides best-effort routing, meaning no guarantees are given regarding the throughput, packet loss and delay that will be experienced by network packets. The access part of a client’s network connection can also cause severe problems, mainly due to its limited bandwidth capacity. In particular, compared to the core of the network, the so-called last mile is usually much less capacitated. As a result, insufficient last mile bandwidth may be available to support all services which a client is currently using (or even to receive all content that is being exchanged as part of a single multimedia service). This will likely give rise to congestion and hence also an increase in packet loss and delay in case adequate techniques for the adaptation of network traffic are lacking. Based on these observations, we believe current networks are often unable to provide users of multimedia services with an acceptable usage experience or, more for- mally, Quality of Experience (QoE). In our previous work we therefore proposed an overlay platform which supports full end-to-end user QoE optimization by employing a two- tier approach [4]. On the one hand, the proposed architecture enhances data dissemination in the network core by providing an overlay routing service which ensures re- silience to possible issues like failing or congested network links. On the other hand, proxy servers deployed close to end-users provide functionality to intelligently apportion bandwidth among network flows on the last mile and in addition act as a multimedia service provision platform since they are also capable of applying processing on multimedia network flows. In this paper, we present a novel transcoding service for the proxy components of our proposed overlay architecture which enables them to dynamically adapt the bit rate of H.264/AVC-encoded video bitstreams. Given the complexity of the H.264/AVC specification, cascading a full decode and subsequent re-encode step would limit the application possibilities of the transcoder to off-line scenarios. The transcoding service therefore operates entirely in the compressed domain to enable real-time video transformation. A secondary contribution of this paper is an illustration of how the capabilities of the proxy component’s bandwidth management functionality and the novel H.264/AVC transcoding service can be bundled to produce highly dynamic and flexible bandwidth management results. As will be illustrated using representative experimental results, the outcome of this collaboration is an even further optimization of the QoE provided to the user. The outline of the remainder of this paper is as follows. In section 2 the full architecture of the proposed overlay network is described. Section 3 harbors a thorough evalua- tion of our platform and demonstrates its ability to improve user QoE. In section 4 a brief overview of related work is presented. Finally, conclusions are drawn in section 5. A schematic representation of the proposed overlay network is depicted in figure 1. The end-to-end infrastructure consists of three main components: overlay servers, overlay access components and NIProxy instances. The overlay servers (OSs) are located in several Au- tonomous Systems in the Internet and sustain connectivity between each other. To do this, they maintain overlay routing tables that map target OS IP addresses to the next hop OS IP address. When an overlay packet arrives at an overlay server, it consults its routing table to determine the next overlay hop IP address and sends the packet to the next OS. This process is repeated until the target overlay server is reached. The overlay packets contain an overlay header with information on the target overlay server, the overlay access component that a packet needs to be sent to and a field for the type of QoS the packet expects. This header is inserted between the UDP header and the packet payload. If the final overlay server receives a packet, it will forward it to the access component which is responsible for further handling it (see next paragraph). To construct the routing tables, the OSs maintain an overlay topology that contains information on the connectivity between pairs of overlay servers. This information is obtained by performing active monitoring and the results of this monitoring are exchanged between the servers. While the overlay servers maintain a resilient overlay routing network, extra components are required to give end- users access to this service, since we cannot assume all end- users deploy overlay servers themselves. Therefore, we de- signed and implemented an overlay network access component (AC). These components are deployed on or close to the end-device and are responsible for determining when traffic is actually sent to the overlay servers. The rationale behind this is that it is not always necessary to use the overlay resources. More specifically, when there is no problem on the direct path between source and destination, the overlay network should not be used. The AC therefore monitors the quality of the connection. In case a problem with QoS is detected or if the AC notices that the connectivity to the destination is lost, it will send the packets to the nearest overlay server, which will subsequently forward it to an AC close to the target node. In this way, the connectivity between source and sink is maintained, while access to the overlay network remains transparent for the service itself. For a more de- tailed overview of the overlay routing network, the reader is referred to [4]. The overlay network also encompasses Network Intelligence Proxy (NIProxy) instances. These components are deployed at the edge of the network and aim to improve user QoE by intelligently managing content delivery to clients over the last mile of their network connection [12]. As its name implies, the NIProxy attempts to accomplish this ob- jective by incorporating different types of awareness or context in the transportation network. Based on this contextual knowledge, the NIProxy performs last mile QoE optimization in two complementary ways, namely through automatic client downstream bandwidth management as well as multimedia service provisioning. The NIProxy is a context-aware proxy server whose contextual information is at the moment twofold and comprises both network- and application-related knowledge [12]. The NIProxy’s network awareness encompasses information regarding the state of the transportation network and, in particular, the current access channel conditions. Its application awareness on the other hand consists of knowledge of the application(s) clients are currently running and can hence vary depending on the kind of application(s) under consideration. In contrast to the network context, which the NIProxy collects through active network probing, the application awareness needs to be provided by the client software. To facilitate this process and to reduce the amount of modification required to the client software, a generic and hence reusable support library is provided which enables developers to provide the NIProxy with context pertaining to their application with minimal effort. The importance or significance assigned by the client to different network flows (or types of flows, e.g. audio or video) is an example of knowledge which could contribute to the NIProxy’s application awareness. The first QoE-improving mechanism supported by the NIProxy is automatic and dynamic client downstream bandwidth management [13]. In particular, the NIProxy is capable of orchestrating the last mile bandwidth consumption of networked applications. Generally speaking, based on its network awareness the NIProxy prevents over-encumbrance of the client’s access network connection, while its application awareness is exploited to create an intelligent alloca- tion of the downstream bandwidth that is actually available. From an implementational point of view, the NIProxy’s bandwidth management mechanism operates by constructing and maintaining a stream hierarchy , a tree-like structure that is composed of both internal and leaf nodes. The internal hierarchy nodes implement a certain bandwidth distribution strategy, whereas the leaf nodes always correspond to an actual network flow. Different types of internal stream hierarchy nodes are available, each having distinct characteristics and capabilities. The WeightStream internal node, for instance, apportions bandwidth among its children in two consecutive phases. More specifically, in the initial phase, each child ...