A Simple and Efficent Packet Marker System for ... - Semantic Scholar

5 downloads 14773 Views 375KB Size Report
of network service is appropriate for conventional Internet applications, such as ... domain to check the conformance of the incoming packets. To the best of our ...
A Simple and Efficent Packet Marker System for Enhanced MPEG Video Delivery over DiffServ Networks Chih-Heng Ke1, Ce-Kuen Shieh1, Wen-Shyang Hwang2, Artur Ziviani3 1

EE Department, National Cheng Kung University, Taiwan R.O.C. {smallko, shieh}@ee.ncku.edu.tw 2 EE Department, National Kaohsiung University of Applied Sciences, Taiwan R.O.C. [email protected] 3 National Laboratory for Scientific Computing (LNCC), Brazil [email protected] the network edge. Within the core of a network, packets are forwarded according to a Per-Hop Behavior (PHB) that determines the treatment to be received by packets sharing the same behavior aggregate. Since the core routers are not required to maintain per-flow states, they can achieve a superior scalability.

ABSTRACT - We propose a Two Markers System (TMS) to improve the delivery quality of MPEG video transmission. TMS places marker modules at both the video source and the edge of a DiffServ network to act at different levels of the video stream. The source marking modules act at the application level to set an importance indicator in the IP header of the MPEG frame packet by evaluating the contribution of the packet to the expected picture quality to be perceived by an end user. Meanwhile, at the edge of the DiffServ network, we propose the Enhanced Token Bucket Three Color Marker (ETBTCM) to perform packet marking at the network level in accordance with the pre-assigned importance of each video frame packet. We use authentic MPEG4 video traffic traces to compare the performance of the proposed TMS system with those of legacy packet markers. Results show that TMS outperforms the legacy traffic markers in terms of the quality of the delivered MPEG video stream while improving the use of network resources.

The DiffServ model involves two basic PHBs, namely the Expedited Forwarding (EF) [4] and the Assured Forwarding (AF) [5]. The EF PHB is used to support services requiring low delays, low jitter, and low loss rates, while the AF PHB supports more flexible services, which impose requirements in throughput, but have no particular delay or jitter requirements. The AF PHB group is divided into four independently forwarded classes. Within each AF class, IP packets are marked with one of three drop precedence levels (denoted by three colors), namely green, yellow, and red, where green has the lowest drop probability and red the highest. When traffic congestion occurs, packets with red marks are dropped first, followed by yellow and then green packets if network congestion persists.

I. INTRODUCTION

Historically, the Internet has always offered a best-effort delivery service, in which all packets are assigned equal priority throughout the network. This type of network service is appropriate for conventional Internet applications, such as e-mail, file transfers, and web-applications, which can adapt well to inconsistent network service levels. However, with the increasing tendency for data transmissions to comprise an amalgamation of various contents, using the standard best-effort mechanism to execute their transmission becomes a less satisfactory experience for the end user. Therefore, the IETF (Internet Engineering Task Force) [1] has defined two service models for network Quality of Service (QoS), namely the Integrated Services (IntServ) model [2] and the Differentiated Services (DiffServ) model [3]. The IntServ architecture provides service discrimination through the explicit allocation and scheduling of resources in the network. Nevertheless, this model is complex and suffers scalability problems. Consequently, the DiffServ model has attracted an increasing interest as a means of providing scalab1e network QoS. Using a simple model, DiffServ categorizes traffic into several different behavior aggregates as it enters

MPEG video transmission over DiffServ networks has been discussed in several previous studies [6-12], which proposed various QoS mappings for streamed MPEG video at the video server prior to transmission depending on the contribution made by each frame type to the perceived picture quality. Standard MPEG encoders generate three distinct types of frames, namely I, P, and B frames. The I frame is encoded in Intra mode, and is essential for the prediction coding of other frames. If part of an I frame is lost, then all frames in the group of pictures (GoP) including this particular frame are impaired. The P frame is encoded in prediction mode, while the B frame is encoded in double prediction mode. As with the I frame, the P frame is also important. If part of a P frame is lost, the impairment propagates the particular P frame, previous B frames, and the following frames in the GoP that includes this P frame. Conversely, if part of a B frame is lost, the impairment propagates solely within that frame. Therefore, in [6], [7], [10], [11], and [12], the delivered quality of the MPEG video stream is enhanced by marking the I frame packets as green, the P frame packets as yellow, and the B frame

542

Copyright © 2004, ATNAC 2004, Australia ISBN 0-646-44190-6

proposed Two Packet Markers system. Section IV describes the simulation model utilized to compare the performance of the proposed marker system with that of two legacy packet marking algorithms, introduces the evaluation metrics, and presents the obtained results. Finally, Section V presents some brief conclusions.

packets as red. In [8] and [9], the video frame packets are mapped to different AF classes, i.e. the I frame packets are mapped to the AF1 class, the P frame packets are mapped to the AF2 class, and the B frame packets are mapped to the AF3 class. However, the first problem associated with these MPEG video source QoS mappings is that there is no policing algorithm involved at the edge of the DiffServ domain to check the conformance of the incoming packets. To the best of our knowledge, there is no attempt to design a traffic conditioner for MPEG video. If legacy packet markers such as Single Rate Three Color Marker (SRTCM) [13] or Two Rate Three Color Marker (TRTCM) [14] are applied at the ingress to the DiffServ domain, the limitation of no protection from being dropped for important data will render a poor video quality delivery due to the hierarchical structure of MPEG video. Even though less important frame packets may be successfully received, these packets will become useless unless their more important associated data are also received. For example, a 3% packet loss percentage could translate into a 30% frame error probability [15]. The second problem is that aggressive sources will seize more network resource than well-behaved ones by marking all frame packets with the lowest drop probability. Consequently, aggressive sources can unfairly receive better delivery quality of video transmission. In this paper, we propose the Two Markers System (TMS), an enhanced marking scheme for MPEG video transmission over DiffServ networks. The aim of this scheme is to overcome the limitations of legacy packet markers in multimedia traffic applications like those using MPEG video streams. The legacy packet markers make no distinction between important and less important data at the edge of a DiffServ domain, and hence may fail to appropriately mark packets to optimize the delivery quality of an MPEG video stream. The proposed TMS scheme places marking modules at both the sources and edge of the Diffserv network. The source marking modules evaluate the contribution of each MPEG frame packet to the perceived picture quality, and then set the importance indicator in the IP header accordingly. Meanwhile, at the edge of the Diffserv network, the Enhanced Token Bucket Three Color Marker (ETBTCM) is implemented to conduct packet marking against the traffic profile in accordance with the assigned importance of each MPEG video frame packet. When the network is busy and there are insufficient tokens in the bucket, less important frame packets are marked with a higher drop probability than packets of greater importance. As a consequence, in the event of network congestion, less important frame packets are dropped before important ones. Also, by means of counter-based control method, the aggressive sources can not seize more bandwidth than well-behaved ones.

II. BACKGROUND The packet marker is one of the fundamental building blocks of a traffic conditioner and plays a major role in determining the resource allocations over DiffServ networks. A simple example of a packet marker is the leaky bucket marker, which is commonly used to measure the traffic against the traffic profile and to mark the packets accordingly as in or out of profile. When a packet arrives at a leaky bucket, the number of tokens in the bucket is examined. If there are insufficient tokens for the packet to pass, the packet is considered as out of profile. Otherwise, the packet is marked as in-profile. To ensure a fair allocation of excess bandwidth within an AF class, the Single Rate Three Color Marker (SRTCM) [13] and Two Rate Three Color Marker (TRTCM) [14] schemes have been proposed. The SRTCM is used when only burst size matters, while the TRTCM is used when peak rate needs to be enforced. The SRTCM, which contains two token buckets, i.e. Tc and Te, meters an IP packet stream and marks its packets as green, yellow, or red. Marking decisions are performed based on a Committed Information Rate (CIR) and two associated burst sizes, namely a Committed Burst Size (CBS) and an Excess Burst Size (EBS). A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise. Moreover, the packet marker can operate in two different modes: color-blind or color-aware. In the color-blind mode, the packet marker assumes that the packet stream is uncolored. In the color aware mode, the packet maker assumes that some preceding entity has pre-colored the incoming packet stream so that each packet is either green, yellow, or red. The pseudo code of the color-aware SRTCM is described as follows: when a packet arrives at time T token_bytes =

CIR * ( T – pkt_arrival );

if ( c_tk + token_bytes = 0 ) e_tk = e_tk – pkt_size;

p_tk = p_tk – pkt_size;

mark the packet as yellow

mark the packet as yellow endif

else else

mark the packet as red else

/* the packet is pre-colored as green or not pre-colored */

endif

if ( p_tk – pkt_size < 0)

/* the packet is pre-colored as red */

mark the packet as red

mark the packet as red

else if

endif

( c_tk – pkt_size < 0 )

p_tk = p_tk – pkt_size; In this pseudo code, pkt_size is the size of the arrival packet, pkt_arrival is the arrival time of the previous packet, c_tk is the token counter for bucket Tc, and e_tk is the token counter for bucket Te.

mark the packet as yellow else p_tk = p_tk – pkt_size; c_tk = c_tk – pkt_size;

The TRTCM scheme also has two token buckets, i.e. Tc and Tp, which include four configurable parameters, namely a Peak Information Rate (PIR), its associated peak burst size (PBS), a Committed Information Rate (CIR), and its associated Committed Burst Size (CBS). A packet is marked as red if it exceeds the PIR. Otherwise, it is marked as either yellow or green, depending on whether or not it exceeds the CIR.

mark the packet as green endif endif In this pseudo code, p_tk is the token counter for bucket Tp.

The pseudo code of the color-aware TRTCM is described as follows:

III. TWO MARKERS SYSTEM

when a packet arrives at time T token_bytes =

This section introduces the Two Markers System (TMS), an enhanced marking scheme for MPEG video transmission over DiffServ networks that is composed of two marker modules. The first marker, denoted as the application-level source marker, is located at the source of the network and determines whether or not the importance indicator in the IP header of a MPEG frame should be set

CIR * ( T – pkt_arrival );

if ( c_tk + token_bytes =0) counter - = pkt_size; mark the packet as yellow else counter += pkt_szie; mark the packet red endif else /* the significance bit is not set */ counter = counter + 2* pkt_size; mark the packet as red endif endif IV. SIMULATION RESULTS The current simulations were performed using the NS2 [17] simulator and Nortel’s DiffServ module, modified to incorporate the proposed TMS scheme. A. The scenario The performance evaluations considered two distinct reference scenarios. In the first scenario (Fig. 2a), a single video source generates packets based on a public available MPEG-4 frame trace file [16] to a remote video destination. We used the Jurassic Park I movie sequence, encoded with high quality MPEG-4 encoding, which has a mean bit rate of 0.77 Mbps and a peak rate of 3.3 Mbps. Each frame was fragmented into packets of 1000 bytes. The total number of frame packets sent by the video source was 389834, comprising 57632 I frame type packets, 111667 P frame type packets, and 220535 B frame type packets. During data transmission, background traffic was generated using a varying number of FTP sources to send TCP packets to their respective destinations. Each TCP packet comprises 1500 bytes. The ETBTCM and the TRTCM and SRTCM schemes were all implemented on the edge router (E1) for performance comparison purposes. In accordance with [14] and [18], the corresponding parameters were set as follows: ETBTCM CIR and CBS parameters of 770 Kbps and 1000 bytes, respectively, TRTCM CIR, CBS, PIR, and PBS

(a) Scenario 1

(b) Scenario 2 Fig. 2. Simulation Scenarios

546

Copyright © 2004, ATNAC 2004, Australia ISBN 0-646-44190-6

ETBTCM is a far superior 87.03%. Fig. 4 indicates that a significant amount of network resource is wasted when TRTCM or SRTCM is used. Since ETBTCM improves the decodable frame percentage by protecting the significant frame packets, it avoids the waste of network resources in delivering information that will become useless at the receiver.

B. Evaluation metrics The performances of the various marking schemes were evaluated by considering the integrity of the received video frames and the network resources wasted on the delivery of useless information. This study adopted two evaluation metrics, namely the fraction of decodable frames and the useless data received [12]. The fraction of decodable frames reports the number of decodable frames over the total number of transmitted frames. A frame is considered to be decodable if at least a fraction dt (decodable threshold) of the data in each frame is received. However, a frame is only considered decodable if and only if all of the frames upon which it depends are also decodable. Therefore, when dt = 0.75, 25% of the data from a frame can be lost without causing that frame to be considered as undecodable. The useless data received evaluation metric reports the fraction of the data received which is useless to the decoder. The decoder may have useless data from partial received frames or from frames that can not be decoded because they depend on other undecodable frames.

Decodable Frames (%)

SRTCM, dt=0.75

SRTCM, dt=1.0

ETBTCM, dt=0.75

ETBTCM, dt=1.0 100 90 80 70 60 50 40 30 20 10 0 0

1

2

3

4

5

6

7

8

9

10

Number of TCP Background Flows

(a) ETBTCM vs. SRTCM

Decodable Frames (%)

ETBTCM, dt=1.0

C. Results This section presents the simulation results and compares the relative performances of the ETBTCM, TRTCM, and STRTCM schemes.

ETBTCM, dt=0.75

TRTCM, dt=1.0

TRTCM, dt=0.75

100 90 80 70 60 50 40 30 20 10 0 0

1

2

3

4

5

6

7

8

9

10

Number of TCP Background Flows

(b)ETBTCM vs. TRTCM Fig. 3. The fraction of decodable frames

C.1 Scenario 1 Figure 3 presents the simulation results for the fraction of decodable frames and the useless data received for various numbers of TCP background flows. As shown in Fig. 3, compared to ETBTCM, as the number of TCP flows increases, the percentage of decodable frames is significantly affected when either TRTCM or SRTCM are adopted, especially in the case of dt=1.0. This behavior is caused by the indiscriminate packet marking of these two schemes. Hence, when network congestion occurs, the downgraded I or P frame packets may be dropped by the WRED queue management mechanism. The loss of these I or P frame packets may subsequently cause other frames to become undecodable. The performance of ETBTCM is clearly superior. This scheme provides a smoother degradation in the delivered quality even under heavy load conditions. In the case of a single TCP background flow, the number of received I frame packets for the TRTCM, SRTCM, and ETBTCM schemes are 52049, 51833, and 57497 respectively, the number of received P frame packets are 99263, 99170, and 111371 respectively, and the number of received B frame packets are 195787, 197733, and 181561 respectively. Clearly then, when TRTCM or SRTCM is employed, the number of lost I or P frame packets is significant. For the case of dt = 1.0, the fraction of decodable frames for the TRTCM and SRTCM schemes is just 61.96% and 63.22%, respectively, while that of

SRTCM, dt=0.75

SRTCM, dt=1.0

ETBTCM, dt=0.75

ETBTCM, dt=1.0

U seless D ata Received

100 80 60 40 20 0 0

1

2

3

4

5

6

7

8

9

10

Number of TCP Background Flows

(a) ETBTCM vs. SRTCM ETBTCM, dt=1.0

ETBTCM, dt=0.75

TRTCM, dt=1.0

TRTCM, dt=0.75

Useless Data Received

100 80 60 40 20 0 0

1

2

3

4

5

6

7

8

9

Number of TCP Background Flows

(b)ETBTCM vs. TRTCM Fig. 4. The useless data received

547

Copyright © 2004, ATNAC 2004, Australia ISBN 0-646-44190-6

10

C.2 Scenario 2

[5] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, “Assured forwarding PHB group,” RFC 2579, IETF, June 1999. [6] A. Ziviani, J. F. Rezende, O. C. M. B. Duarte, and S. Fdida, “Improving the Delivery Quality of MPEG Video Streams by Using Differentiated Services,” 2nd European Conference on Universal Multiservice Networks - ECUMN 2002., pp. 107-115, April 2002 [7] J. M. H. Magalhaes and P. R. Guardieiro, “A New QoS Mapping for Streamed MPEG Video over a DiffServ Domain,” Communications, Circuits and Systems and West Sino Expositions, IEEE 2002 International Conference on , vol. 1, pp. 675-679 , June 2002. [8] X. Zhu, M. Chen, and Y. Yu, “Video Transmission Based On DiffServ Over IP Networks,” ICCT’03, vol. 2, pp.1754-1757, April 2003. [9] M. Chen, G. Wei, and X. Zhu, “An IP DiffServ Framework For Real-time Video Transmission,” ICCT’03, vol. 2, pp. 1723-1726, April 2003. [10] T. Ahmed, G. Buridant, and A. Mehaoua, “Encapsulation and Marking of MPEG-4 Video over IP Differentiated Services,” ISCC’01, pp. 346-352, July 2001 [11] T. Ahmed, G. Buridant, and A. Mehaoua, “Implementing MPEG-4 Video On Demand Over IP Differentiated Services,” GLOBECOM’01, vol. 4, pp. 2489-2493, 2001 [12] A. Ziviani, B. E. Wolfinger, J. F. Rezende, O. C. M. B. Duarte, and S. Fdida, “Joint Adoption of QoS Schemes for MPEG Streams,” Multimedia Tools and Applications Journal, to appear. [13] J. Heinanen, and R. Guerin, “A Single Rate Three Color marker,” RFC 2697, September 1999 [14] J. Heinanen, and R. Guerin, “A Two Rate Three Color Marker,” RFC 2698, September 1999. [15] J. M. Boyce, and R. D. Gaglianello, “Packet Loss Effects on MPEG Video Sent over the Public Internet,” In Proc. of the ACM Multimedia, September 1998. [16] F.H. P. Fitzek, and M. Reisslein, “MPEG-4 and H.263 Video Traces for Network Performance Evaluation,” IEEE Network, vol. 15, no. 6, pp. 40-54, November 2001. [17] K. Fall, and K. Varadhan, “The NS Manual- Notes and Documentation,” Tech. Rep., The VINT Project, April 2001. [18] H. Kim, C. Yoo, and W. Y. Jung, “Simulation Study on the Effect of the trTCM Parameters,” Telecommunications’03, vol. 2, pp. 1482-1488, February 2003.

Table 2 summaries the simulation results for the fraction of decodable frames and the useless data received of two experiments. The result indicates when one wants to set the significance bit of all frame packets, i.e. flow 1 in experiment 2, the fraction of decodable frames was worse than that of well-behaved source, i.e. flow 2 in experiment 2. TABLE II. EVALUATION METRICS WHEN TWO VIDEO SEQUENCES COEXIST

Experiment 1 Experiment 2

Fraction of Decodable Frames

Useless Data Received

dt = 1.0

dt=1.0

dt=0.75

dt=0.75

Flow 1

82.87%

85.15%

10.33%

6.89%

Flow 2

82.78%

85.12%

10.35%

6.86%

Flow 1

68.82%

74.64%

34.98%

27.69%

Flow 2

81.82%

84.19%

11.24%

7.47%

V. CONCLUSIONS This paper has proposed a Two Markers System (TMS), a simple yet efficient packet marker system to improve the delivery quality of MPEG video transmissions. Through an extensive simulation study, we compare the performance of TMS to that of the legacy packet markers for MPEG video transmission, namely SRTCM and TRTCM, in a DiffServ network. Simulation results show that the TMS packet marker outperforms both SRTCM and TRTCM in terms of the delivered MPEG video quality while reducing the waste of network resources. The improvement in delivered quality is obtained by giving preference to more important frame packets of the video stream when the traffic flow is measured as out of profile. Therefore, in the event of network congestion, less important frame packets are dropped before more important ones. As a consequence, TMS provides a smoother degradation in the delivery of quality as compared to TRTCM and SRTCM even under heavy load conditions. Also, by means of counter-based control method, the aggressive sources can not unfairly receive better delivery quality of video transmission than well-behaved ones. REFERENCES [1] “IETF home page, ”http://www.ietf.org/” [2] R. Braden, L.Zhang, S. Berson, S. Herzong, and S. Jamin, “Resource Reservation Protocol (RSVP)---Version 1 functional specification,” RFC 2205, Sept. 1997. [3] Y. Bernet, J. Binder, S. Blake, M. Carlson, B. E. Carpenter, S. Keshav, E. Davies, B. Ohlman, and D. Berma, “A framework for differentiated services,” Internet Draft, Feb. 1999. [4] V. Jacobson, K. Nichols, and K. Poduri, “An Expedited Forwarding PHB,” RFC 2598, IETF, June 1999.

548

Copyright © 2004, ATNAC 2004, Australia ISBN 0-646-44190-6