Criteria and Constraints

This section provides an overview of different criteria that can be applied to se-lect a bandwidth adaptation mechanism for a given application. We emphasize that this is, by necessity, a qualitative discussion. Many of the techniques that are mentioned in this chapter have only been proposed in a research context and have not been fully tested in a more realistic network environment. Moreover, a quan-titative comparison of the various methods is likely to be very complex, as should be clear given the number of criteria to be considered in general.

4.3.4.1 Media Quality

Clearly, the ultimate criterion to evaluate the performance of a bandwidth adap-tation mechanism should be the resulting subjective media quality at the receiver in the presence of typical bandwidth variations. Some progress has been made in devising objective metrics that can capture the perceptual quality of media under various compression strategies [34,37,68]. These objective metrics are most ad-vanced for the analysis of audio sources, somewhat less so for video applications.

Approaches that can compare meaningfully different methods in the presence of variations in the network behavior (e.g., bandwidth fluctuations, packet losses) are not that readily available.

Service interruptions, such as those that might occur if no bandwidth adaptation is used, are obviously undesirable, and so one could, for example, compare differ-ent techniques in terms of their outage probability (the probability that perceptual quality over a given period of time drops below acceptable levels). A comparison would still be challenging: for example, an end user may deem two configurations with different, but nonnegligible, outage probability to be equally unacceptable.

Quality evaluation is also more complicated once a bandwidth adaptation mechanism is put into place because these mechanisms are dynamic in nature.

Thus, they operate only when the bandwidth falls below certain levels and lead to changes in the media quality (e.g., in the context of video, variations in frame rate, frame resolution, frame quality). In this situation, it is unclear whether users will base their quality assessment on the perceived “average” quality, the worst case quality level, the duration of the worst quality, etc.

Many currently deployed practical media streaming systems generally select one of multiple streams, that is, the one whose bandwidth best matches the band-width available to the end user; in many cases no adaptation is possible within a stream. Thus system designers only have a limited amount of real-life experi-ence with bandwidth adaptation mechanisms. It also follows from this that the impact of various such mechanisms on perceptual media quality is not as well understood.

In summary, while progress has been made toward understanding subjective quality metrics for various types of media, challenges remain in addressing situ-ations where quality adaptsitu-ations (not to mention information losses) take place.

For this reason, and also to facilitate bandwidth adaptation mechanisms, objective quality metrics, such as peak signal-to-noise ratio (PSNR), are often used. For example, authors have proposed optimizing average PSNR (e.g., [29]) or min-imizing the loss in PSNR introduced by bandwidth adaptation, with respect to the PSNR achieved when the media stream transmitted at a given target bit rate (e.g., [16]).

4.3.4.2 End-to-End Delay, Reaction Time, and Latency

As discussed earlier, a longer end-to-end delay facilitates preserving a consistent quality level in the face of bandwidth fluctuations. Roughly speaking, a longer end-to-end delay leads to more multimedia units (e.g., video frames) being stored in the decoder buffer so that the application can absorb short-term variations in bandwidth.

When the end-to-end delay is not long, the reaction time of the adaptation sys-tem to changes in bandwidth becomes important. The syssys-tem has to detect rel-evant variations in network behavior and then trigger the necessary changes in the media stream so as to best match bandwidth availability. Ideally, this should happen sufficiently fast so that the end user does not suffer from negative conse-quences of mismatch between network availability and stream requirements.

Note that this leads to interesting design trade-offs in the context of the adapta-tion architectures discussed earlier. For example, a faster reacadapta-tion may be possible if the sender makes adaptation decisions, but these may suffer from a somewhat worse knowledge of network status at the client.

Long end-to-end delay is a practical solution only for one-way transmission applications. For two-way communications, a long delay will limit the interac-tivity. Even in the case of one-way communications, excessive end-to-end delays

lead to higher initial latencies, which would be undesirable if the user switches multimedia streams frequently.

4.3.4.3 Complexity

An interesting challenge in architecting a bandwidth adaptation mechanism is that several components (client, proxy, and sender) can play a role. Thus, taking into account complexity requires identifying first which of these components is least constrained in terms of complexity.

While it may appear at first obvious that the server will be richer in computation resources, this may not be true in general. In particular, for applications such that each sender is responsible for multiple clients, overall computation power at the sender may be significant, but computation power for each client served may have to be limited in order to ensure scalability.

4.3.4.4 Storage

Storage constraints are unlikely to be of much importance, except for mobile ap-plications. It is also worth mentioning the complexity implications of shared stor-age. While massive storage is often available at a very low cost, there may be significant computation costs involved in managing a large number of streams be-ing produced out of a shared storage device. In this context, bandwidth adaptation tasks (e.g., switching between two pre-encoded versions of a media stream) may add to the complexity of the system.

4.3.4.5 Information Overhead

Consider existing digital video delivery systems (e.g., a digital cable system) and compare them with systems such as those we have discussed. In a digital cable system bandwidth is expected to be reliable and there is minimal interaction be-tween receiver and sender.

Instead, proposed bandwidth adaptation architectures often require auxiliary information to be exchanged between client and sender. Examples of this extra information include estimates of channel state, acknowledgments of reception of information, and rate distortion “preambles.”

4.3.5 Examples

Depending on the type of application, network characteristics, and optimization criteria, it is possible that different bandwidth adaptation architectures may be preferable. This section sketches some examples that allow us to discuss how particular choices of architecture can be made. Note that we are not proposing

a concrete methodology for architecture selection. Moreover, there may be sev-eral architectures that are suitable for a given scenario. Thus, these examples are meant to illustrate possible approaches in the design process, rather than to claim optimality for any of the different approaches.

In the case of one-to-one interactive two-way communication, such as video conferencing, a relatively short end-to-end delay, usually between 150 and 400 ms, is required. Thus it may be preferable for the decision agent and the adap-tation point to be located close to each other so as to avoid excessive delay before adaptation takes place. One possible solution is presented in Table 4.1. When a server receives feedback indicating a channel status change, it estimates the new available channel bandwidth [29] and then makes the corresponding adaptation decision. The adaptation can be as simple as skipping transmission of some of the packets to prevent video freezing or losing connections. More advanced tech-niques can also be applied, such as, for example, adjusting the video codec para-meters to increase or decrease the encoding rate. However, the limited bandwidth and stringent delay requirement in this case may limit the potential performance gains achievable through adaptation.

In the case of one-to-one one-way streaming, a longer initial play-out delay, of up to a few seconds, is likely to be acceptable. A more appropriate solution for this case would then be client-driven streaming, such as the SureStream technol-ogy used in RealSystem [19]. During the streaming session, a client monitors the bandwidth and loss characteristics of its connection and makes decisions based on more accurate and fine grain channel information. Then it instructs the server to take certain actions, for example, switching to different streams, or selectively transmitting only the number of layers in a layered codec that the given link can support, such that the end-to-end distortion can be minimized over the current channel condition.

In the case of Internet broadcast or multicast, the traditional single-server-based delivery system faces several major problems, including service scalabil-ity and traffic load unbalance, as discussed in Section 4.3.2. To address these problems, today’s content delivery networks employ multiple geographically dis-Table 4.1: Examples of bandwidth adaptation architectures for different video communication applications

tributed edge servers to either forward the incoming live content or deliver the on-demand content from their local cached storages to their local clients. It is pos-sible to directly extend the client-driven server-adaptation technique to multicast delivery. However, it may be better if proxy servers can take a more active role in the bandwidth adaptation process, as the bandwidth limitations often occur in the access network, such as a DSL connection. This proxy-based architecture, as shown in Table 4.1, can reduce the reaction time, avoid congestion in the Internet, and provide appropriate qualities for clients with different connections.