- Introduction
- Overall Proposed QoS Mapping Framework in a DiffServ Network
- Video Packet Categorization Based on the Relative Priority Index (RPI)
- QoS Mapping Problem Formulation and Solution
- Experimental Results
- Conclusions
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.2 Overall Proposed QoS Mapping Framework in a DiffServ Network
3.2.1 Overall QoS Mapping Framework
A diagram of the proposed QoS mapping framework is presented in Figure 3.1. In our framework, service differentiation is done in terms of the loss rate and delay performance of network service. (We are assuming that the traffic-conditioning entities of the DiffServ network are taking care of the throughput negotiation.)
)
Figure 3.1. Overall QoS mapping framework based on RPI and network DS levels.
Each video flow of a user application must be classified according to its importance to receive low-delay or low-loss packet delivery service from the network. For example, low delay is more important to a video conference application than to a streaming video application. Moreover, each packet is associated with the RPI, which is composed of two normalized indices, the RLI and the RDI. These indices are described in detail in Section 3.3. RLI and RDI are basically indices that indicate the impact of a data segment’s loss and delay, respectively, on the quality of the application. Therefore, these indices specify the data segment’s importance in terms of receiving good service quality from the network layer.
The packets associated with the RPI are categorized into intermediate DS traffic categories (i.e., traffic aggregates with different source traffic priorities) in a fine-grained manner by the application. We use the term “intermediate DS traffic categories” because these categories may change as the packet enters the DS domain. The marking of codepoints in the packets in accordance with these intermediate DS traffic categories is a “pre-marking” [17] from the viewpoint of the DS domain. We allow the application to do such a pre-marking on the basis of the application’s knowledge of the packet’s content without it knowing the status of the network or SLA between the application’s domain and the DS domain. Then, pre-marked (i.e., RPI-categorized) packets are conveyed into the DiffServ-aware node for QoS mapping, which takes into account the SLA with the DS domain, and in the case of dynamic QoS mapping, also the network status. Such QoS mapping can be implemented at the end-system itself, at a DiffServ boundary node, or at both. Thus, given a video application and the responding DiffServ network, the QoS mapping is accomplished by mapping (i.e., marking) the relative prioritized packets to maximize end-to-end video quality under a given cost constraint. Then, at the DiffServ junction (i.e., a DiffServ boundary node), the packets are classified, conditioned, and re-marked to certain network DS levels by considering the traffic profile based on the SLA and current network status. (The QoS mapping implemented at the DiffServ boundary node can be designed to consider the SLA and global view of all the aggregate traffic coming from multiple applications.) Finally, the packets with DS-level mapping are forwarded toward the destination through a packet-forwarding mechanism, which mainly comprises queue management and a scheduling scheme.
In this chapter, we consider the case in which the DS domain provides proportional DiffServ through its packet-forwarding mechanisms. The desired differentiation in queuing may be realized by adopting multiple queues with several drop curves such as multiple RED and RIO [42], [97]. Furthermore, if different weighting factors are adopted, a modified version of WFQ scheduling can be used to complement queue management to provide the desired loss-rate/delay differentiation.
The above QoS mapping framework can be applied to multimedia rate-adaptive transport mechanisms. The framework can be used with a futuristic differentiated service with a pricing mechanism that charges different prices for different classes. Since a video codec has several options for trading compression efficiency for flexible delay manipulation, error resilience, and network friendliness, the QoS coordination has to provide a simplified QoS mapping process between the video encoder and target network. The purpose of introducing RPI is to abstract and isolate coding details from the network adaptation. By assigning RPI to each packet in an appropriate manner (i.e., keeping the fine granularity as much as possible), the proposed delivery system can accommodate the demand of each packet to achieve the best end-to-end performance in adapting to network fluctuations.
3.2.2 Deployment Issues
A typical DiffServ architecture defines a simple forwarding mechanism at interior network nodes while pushing most of the complexity to network boundaries [17], [98]. The traffic conditioner (composed of the meter, marker, shaper, and dropper) is placed at the boundary of the network. Given this functionality at the boundary, interior nodes use a packet-forwarding mechanism with queue management and scheduling for incoming packets to deliver differentiated services to various packets. This DiffServ architecture can bring benefits to both the end-user and ISP by providing better service quality for CM applications if they are willing to pay more for higher quality. Thus, the design principles for QoS mapping should consider the interests of both the end users and the ISPs. That is, an end-user should benefit from a DiffServ-aware application through having the option of obtaining higher service quality, while an ISP should enjoy the benefit of flexible charging based on the end-user’s preferences. To handle this negotiation, we need to measure the QoS demand of CM applications and the QoS supply of DiffServ networks in terms of pre-defined granularity. With pre-defined granularity, service differentiation can be demanded by marking differently at the end-system to request targeted DS levels. The service level may then be adjusted (i.e., through re-marking) in the DiffServ network and handled (i.e., forwarded) accordingly.
Each DS level is identified by the ToS or DS byte (i.e., the DSCP) defined in the IP header. The DiffServ working group also defines PHBs using the DS byte to specify the required forwarding behavior for packets in accordance with DS levels. Among initial PHBs being standardized are the EF PHB for DiffServ PS [24] and the AF PHB for DiffServ AS [23]. The EF PHB group specifies a forwarding behavior in which packets experience very small losses and queuing delays. EF PHB, based on priority queueing, better suits latency-stringent applications at the cost of a higher price. The AF PHB group specifies a forwarding behavior to preferentially drop best-effort (BE) and/or out-of-profile packets when congestion occurs. By limiting the volume of AF flows and managing the BE traffic appropriately, network nodes can ensure better loss behavior for AF-marked packets. As a result, the DiffServ framework provides DS levels with different losses and delays. For example, one EF queue, four AF queues with three drop preferences, and one BE queue may be defined as depicted on the network side in Figure 3.2. We can draw three equivalent cost lines in Figure 3.2, imagining several pricing model possibilities for the ISP. Line (a) considers only loss rate, while Line (c) depends only on delay. Line (b) relies on both loss rate and delay, and it is flexible. That is, at the same cost, it provides various service combinations such as higher delay with a lower loss rate, and vice versa.
)
Figure 3.2. QoS mapping from source RPI into network DS levels.
Different DS levels are to be provided based on the marking (on the DS byte) of an application packet, and different amounts of loss and delay are expected based on the requested DS level. Thus, it is natural to think of associating a packet with both loss and delay priorities (i.e., RLI/RDI) rather than with loss alone, albeit in a fine-grained manner. For streaming video applications, the RLI association of each packet should reflect the loss impact of each packet on the video quality. For RDI, classification of video streams depends more on application context (e.g., video conferencing or video-on-demand) than on video content within a stream. For example, as shown on the source side of Figure 3.2, the quality request of two video applications, (A) and (B), are clearly distinguishable in terms of RDI depending on application usage, with added variability expressed by RLI.
For delay differentiation within a stream, Tan and Zakhor [99] considered frame-encoding modes. In this case, the highest delay sensitivity is given to the intra-coded frames (I frames), the next priority is assigned to the predicted frames (P frames), and the bi-directional, interpolated frames (B frames) have the lowest priority based on the encoding and decoding order of each frame type. This implies, however, that within a stream, the RLI and RDI attributes of packets are not completely orthogonal, which makes a reasonable classification somewhat difficult (this is discussed further in Section 3.3). Considering the complexity involved in varying RDI for each packet, we believe an appropriately fixed RDI with varying RLI is more than sufficient. Thus, in this work, we assign a fixed RDI for all packets of an application, as shown in Figure 3.2, and try to establish a satisfactory range of DS levels for the given RDI.
Given the RPI of each packet, our goal is to identify the best QoS mapping for video packets with content-aware forwarding under a cost constraint. At the end-system, an RPI is assigned to each packet, and it is then categorized into the kth category among K DS traffic categories. However, it is still up to a specific deploying environment to determine where the QoS mapping will be conducted. If the QoS mapping is conducted at the network adaptation unit of the end-system, an application can take advantage of its content-awareness (i.e., original RPI) to the extreme. Also, it can cover the early stage of DiffServ deployment, since it does not require any additional supporting network node except for prioritized DS levels. However, it lacks knowledge of the dynamics of the network and of the aggregation effect of competing flows, which can impede the efficiency of mapping because of the lack of a proper feedback mechanism. To provide a better fit into the access network scenario shared by multiple DiffServ-aware applications, it might be worthwhile to introduce a special version of a DiffServ boundary node to handle the proposed QoS mapping. With this, we could treat effective QoS mapping between aggregated CM packets and network DS levels (with fluctuating, but bounded service levels) under the TCA in the SLA. By adjusting the QoS mapping dynamically through coordinated interaction with end-systems, we could expect to achieve sophisticated exploitation of the DiffServ advantage.
However, note that in this chapter, we promote the futuristic concept of a proposed QoS mapping framework while deferring the discussion of practical issues such as dynamic QoS mapping and its aggregation effect.3 By focusing on the QoS mapping problem of each single flow, we have intensively investigated the potential of the proposed framework. In particular, we will discuss how to create the required building components, such as the RPI association/categorization, the persistent packet-forwarding mechanism desired, and the practical formulation of QoS mapping. Thus, with several DiffServ network deployment scenarios and corresponding QoS mappings to consider, both network and end-to-end video performances of the proposed mapping framework are evaluated for end-to-end streaming video over simulated DiffServ networks.