idnits 2.17.1 draft-lai-tsvwg-normalizer-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2013) is 3944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lai 3 Internet-Draft W. Wang 4 Intended status: Informational S. Yang 5 Expires: January 7, 2014 T. Eckert 6 F. Yip 7 Cisco Systems 8 July 6, 2013 10 Normalization Marker for AF PHB Group in DiffServ 11 draft-lai-tsvwg-normalizer-02 13 Abstract 15 In DiffServ, preferential dropping of packets in AF PHB groups has 16 long been considered beneficial, typically for video flows with 17 discardable packets. Unfortunately, the ecosystem of bandwidth 18 contention at congestion is very likely to discourage those video 19 endpoints from generating packets with lower precedence markings, 20 i.e. they would lose more packets if doing so. Thus, to offer an 21 incentive for more collaborative and mutually beneficial behaviors of 22 video endpoints in AF PHB groups, we propose a Normalization Marker 23 (NM) for traffic conditioning at network edges. Deployment of NM 24 will encourage the video endpoints to generate finer layers of intra- 25 flow precedence (IFP) with discardable packets in more balanced 26 distributions. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 7, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Video Packets in Structure . . . . . . . . . . . . . . . . 6 65 2.2. Intra-Flow Precedence (IFP) . . . . . . . . . . . . . . . 8 66 2.3. Mapping IFP to AF Markings . . . . . . . . . . . . . . . . 9 67 3. Normalization Marker (NM) . . . . . . . . . . . . . . . . . . 11 68 3.1. Color-Aware vs. Color-Blind Mode . . . . . . . . . . . . . 12 69 3.2. Distribution Meter . . . . . . . . . . . . . . . . . . . . 12 70 3.3. Normalizer . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 Assured Forwarding (AF) Per-Hop Behavior (PHB) groups are described 82 in [RFC2597] (with terminology clarified in [RFC3260]) for DiffServ 83 (DS) multimedia service classes such as realtime video conferencing 84 and on-demand streaming. Four AF PHB groups have been defined in 85 [RFC4594] with DS codepoint (DSCP): AF1x, AF2x, AF3x and AF4x where 86 x=1, 2 or 3 for drop precedence in each independent AF PHB group. 87 The DS nodes that support an AF PHB group must set configuration of 88 Active Queue Management (AQM) properly w.r.t. those DSCP markings. 89 For example, for AF4x PHB group which includes AF41, AF42 and AF43 90 markings, an AQM implementation by Weighted Random Early Detection 91 (WRED) should be configured with some drop probabilities and queue 92 thresholds such that the packet loss rate of AF41 <= AF42 <= AF43 on 93 congestion of the queue. 95 For an AF PHB group, a DS boundary node or host in the DS domain 96 should use a marking algorithm that properly assigns AF markings of 97 drop precedence to all packets w.r.t. the traffic profiles and 98 Service Level Agreements (SLA). For example, [RFC2697] and [RFC2698] 99 use a token-bucket mechanism for metering each stream of packets and 100 respectively define "srTCM" and "trTCM" markers, to mark packets by 101 the data rate and burst size limit in traffic profiles. Those rate- 102 control markers can be useful at DS boundary nodes for traffic 103 conditioning [RFC2475] and to support IntServ/RSVP traffic over DS 104 regions [RFC2998]. Multiple markers may be applied to the same 105 stream, either on the same or multiple DS nodes along the path. For 106 example, srTCM and trTCM can operate in a so-called "color-aware" 107 mode such that for each incoming packet that already carries an AF 108 marking, the local srTCM/trTCM either keeps the same or lowers the 109 drop precedence of that packet by metering. 111 However, modern video codec technologies are being advanced not only 112 in coding efficiency (i.e. better compression ratio) but also in two 113 key areas for transport on IP networks: (1) encoder rate-control and 114 dynamic adaptation; (2) ability to generate discardable packets in 115 multiple layers to tolerate packet losses in the network without 116 significant degradation of video quality observed at the decoder. 117 For (1), the encoder dynamically limits its output rate of packets 118 into the AF PHB group, i.e., the encoder's host is the first DS node 119 equiped with srTCM/trTCM if it marks packets in that behavior. The 120 next DS node is the first-hop router which may add extra srTCM/trTCM 121 to enforce the traffic conditioning or policing from the network's 122 perspective. Thus, we consider this an incentive for (1) because an 123 encoder using a self rate-control is less likely to see packet losses 124 by the network. Unfortunately, an incentive for (2) is arguably 125 missing today. 127 To see the missing incentive for (2), consider the following example 128 where 2 video flows A and B with rate control are sent in AF4x PHB 129 group. Each sends 5Mbps on average with some burstiness, but still 130 complies with the rate and burst limit in its traffic profile. 131 However, A and B generate packets with AF4x markings in different 132 distributions of precentage: 134 Flow A 136 80% or 4Mbps in AF41 138 20% or 1Mbps in AF42 140 0% or 0Mbps in AF43 142 Flow B 144 40% or 2Mbps in AF41 146 40% or 2Mbps in AF42 148 20% or 1Mbps in AF43 150 Flow B at above is likely using a more advanced video technology to 151 generate multiple layers of discardable video packets, and thus, its 152 distribution of AF4x markings looks finer and more balanced. That 153 is, flow B acts more friendly to other flows in this AF4x PHB group. 155 Thus, we argue that the ecosystem in practical deployment should 156 offer an incentive for flows to behave similarly to what flow B is 157 doing above, i.e., on congestion, the AF4x PHB group should try to 158 drop packets in the same amount from each flow, while a flow with 159 finer layers of discardable packets and/or in a more balanced 160 distribution should be able to benefit from its own efforts and see 161 good results in video quality preservation. 163 Unfortunately, this incentive is still missing today. Suppose that 164 congestion occurs in the AF4x WRED queue where A and B compete for 165 bandwidth and there is no other flow, for simplicity. B's packet 166 loss rate is very likely to become higher than A's, despite B's 167 effort of acting friendly: 169 o If the queue drops 1Mbps in total, 171 A sees 0% or 0Mbps loss; 173 B sees 20% or 1Mbps loss (all its AF43 are lost). 175 o If the queue drops 4Mbps in total, 177 A sees 20% or 1Mbps loss (all its AF42 are lost); 179 B sees 60% or 3Mbps loss (all its AF42 and AF43 are lost). 181 Thus, to create the missing incentive at above, we propose a new 182 "Normalization Marker" (NM) and describe it in this memo. NM can be 183 deployed on DS boundary nodes for traffic conditioning in practical 184 deployment with AF PHB groups for multimedia service classes. In 185 summary, if NM is applied to a DS boundary node for an AF PHB group, 186 it re-assigns the AF markings of all packets per flow such that the 187 distributions of the AF markings are similar in all flows, i.e., it 188 "normalizes" the distributions of AF markings in all flows. It also 189 attempts to maintain the original orders of the intra-flow drop 190 precedence carried by the input AF markings, as linearly as possible. 191 After the AF-marking distributions are normalized, all those flows 192 should see very similar packet loss rates at AQM for this AF PHB 193 group on congestion of the queue. Then, a codec implementation may 194 have better video quality preservation on network congestion if it 195 employs a more advanced video technology to generate discardable 196 packets with finer markings of drop precedence in a more balanced 197 distribution. 199 +------------+ 200 | Runtime | 201 | Statistics | 202 | V 203 +-------+ +--------+ 204 | | | | 205 AF-Marked | Distr.| | Norm | AF-Marked 206 Packet Stream ===>| Meter |===>| Marker |===> Packet Stream 207 | | | | 208 +-------+ +--------+ 210 Normalization Marker (NM) with AF PHB Group 212 Figure 1 214 Note that the use of NM is not necessarily limited to video service 215 classes, but could be extended to wherever AF PHB groups can be used, 216 or to any other PHB groups that require a similar incentive NM can 217 provide. 219 2. Background 221 2.1. Video Packets in Structure 223 Modern video codec technologies such as ITU-T H.264/MPEG-4 AVC [H264] 224 typically generate a stream of encoded video packets with internal 225 structure of data dependency for decoding. This has been designed 226 for at least 3 fundamental reasons: 228 o Coding Efficiency: An encoder improves its coding efficiency 229 typically by reducing spatial and temporal redundancy of the 230 input. For video, spatial redundancy is reduced by intra-frame 231 motion prediction and compensation, while temporal redundancy 232 refers to inter-frame since a video stream is composed of a 233 sequence of frames or pictures in the temporal order. With motion 234 prediction, a frame can be encoded by referencing some pixels of 235 the picture data that will be decoded earlier either in the same 236 (intra) or another (inter) frame so that it can use significantly 237 fewer bits to encode this frame. The frame where the pixels are 238 referenced by any other frame is thus called a referenced frame in 239 the video stream; for example, Instantaneous Decoding Refresh 240 (IDR) in H.264 or Intra (I) frames are typically referenced by 241 subsequential frames, while Predictive (P) frames may be 242 referenced at the encoder's choice, by the Group of Picture (GOP) 243 profile, and/or by some proprietary algorithm in the codec 244 implementation. 246 o Lossy Network: To use network transport that may lose packets, the 247 encoder may choose to generate a stream with two or more layers 248 each of which the packets are marked with some layer identifier 249 (ID). The network can simply use the layer ID to determine the 250 drop precedence of each packet in the video stream. 252 * Layers in Hierarchy of Dependency: If these layers are coded in 253 hierarchy of dependency, the packets in an "enhancement" layer 254 will depend on 1 or more "base" layers to get decoded without 255 errors, while packets in a base layer without dependency can be 256 independently decoded without errors. 258 + If some enhancement layer packets are lost, the decoding 259 errors in that picture frame will not stay or cascade to 260 other frames given that no others depend on those lost data. 261 This nice property allows the network to safely drop packets 262 in some enhancement layers, if needed, without badly 263 impacting the video quality at decoder. 265 + If some base layer packets are lost, the impact can be 266 severe since these decoding errors will stay in buffer and 267 cascade to all other picture pixels that depend on the lost 268 data to decode in the current and/or a later frame. This 269 impact can last tens of seconds as the video quality 270 continues getting worse, resulting in unpleasant user 271 experiences, until the decoder receives the next IDR or I 272 frame, either on-demand or periodically, to remove those 273 errors. 275 For example, H.264 Annex G defines Scalable Video Coding (SVC) 276 using a 3-dimensional (i.e. spatical, temporal and quality) 277 hierarchy of layer dependency at the encoder's choice, but for 278 simplicity, it also defines a scalar number called Priority ID 279 (PID) in its header so the network could instead use PID, if 280 set by the encoder, to determine drop precedence in the stream. 282 * Layers NOT in Hierarchy of Dependency: Sometimes the encoder 283 will generate multiple layers without any dependency between 284 those layers. These mechanisms usually enlarge the amount of 285 encoded video data for vairous purposes. For example, 287 + Forward Error Correction (FEC) may be used at the encoder to 288 generate extra FEC packets, so that the decoder can tolerate 289 certain amounts of packet losses. 291 + Simulcast (i.e. simultaneous multicast) by an encoder will 292 actually generate multiple layers each of which can be 293 transmitted and decoded independently, in parallel by IP or 294 application multicast. Each layer carries video in a 295 different resolution and/or quality. The decoder can choose 296 1 or more of those layers to receive according to the 297 required, available or detected bandwidth, packet losses, 298 delays, jitter etc. in its network service. 300 With FEC and/or Simulcast, the encoder can still mark the 301 packets with different drop precedence in those layers to 302 better protect the more important data for video quality at 303 decoding when congestion occurs. 305 o In-Band Signaling: An encoded video stream usually carries in-band 306 control messages that are most critical for adequate encoder and 307 decoder behaviors. For example, 309 * H.264 Annex D defines Supplemental Enhancement Information 310 (SEI), which could also carry proprietary codec parameters. 311 These in-band control signals should be given the highest drop 312 precedence. 314 * Real Time Control Protocol (RTCP) carries in-band control 315 messages for Real Time Protocol (RTP) [RFC3550], which is 316 mostly used for realtime multimedia transmission on IP 317 networks. RTCP messages are defined as RTP packets with 318 special payload types in the RTP stream. RTCP packets should 319 be given the highest drop precedence but should receive the 320 same delay/jitter as regular RTP packets in the same stream. 322 2.2. Intra-Flow Precedence (IFP) 324 For abstraction, we define "Intra-Flow Precedence" (IFP) to represent 325 the drop precedence in one individual flow that may carry a video 326 stream of IP packets in multimedia networks. Here is a summary of 327 IFP characteristics: 329 o IFPs are drop precedence levels that are only significant within 330 each individual flow. 332 o IFPs are integer numbers that can be numerically compared if 333 needed. 0 represents the highest precedence. The larger numerical 334 value an IFP is, the lower precedence it represents. 336 o The number of IFP levels in each flow is not necessarily the same. 338 o IFPs between any 2 flows should NOT be compared to determine drop 339 precedence between their packets in a queue. 341 o IFPs may be assigned by the original encoder of the stream and 342 carried in some bits field of all packets in the stream. 344 o IFPs may be assigned or re-assigned by a middle box or router if 345 it is capable of understanding the stream packet format and codec 346 symantics. 348 For example, an H.264 AVC flow may have the following IFP assignments 349 at the video encoder's choice. 351 IFP = 0 for in-band signals 353 IFP = 1 for IDR frames 355 IFP = 2 for referenced P (rP) frames 357 IFP = 3 for non-referenced P (nrP) frames and others 359 IFP assignements as well as their distribution can vary a lot among 360 different encoder implementations and codec profiles. For example, 361 some encoders may generate both long-term and short-term referenced P 362 frames, where a long-term referenced P frame should have higher drop 363 precedence. In case of H.264 SVC, the IFP assignments could simply 364 be the same as the PID assignments if set by the encoder properly, or 365 be calculated based on the SVC layer ID that has 3 tuples for the 366 spatial, temporal and quality dimensions, respectively. 368 2.3. Mapping IFP to AF Markings 370 When a flow is sent in an AF PHB group, the number of its IFP levels 371 is not necessarily equal to the number of the AF markings. In fact, 372 since each of the currently defined AF PHB groups has only 3 AF 373 markings, it is likely that an encoder or DS node needs to apply an 374 n-to-1 mapping from IFPs to AF markings in practice. 376 The mapping decision is made usually by the encoder, but can also be 377 made by another DS node if necessary and if the DS node is able to 378 understand the encoded video packets, which may require Deep Packet 379 Inspection (DPI), e.g. to read in RTP payload and parse the H.264 380 headers [RFC6184], or in a proprietary bits field in the IP payload, 381 to retrieve or calculate the IFP of each packet in a flow before 382 locally mapping the IFP to an AF marking. 384 This n-to-1 mapping can be arbitrary but should be appropriate. 385 Consider 2 IFPs, say x and y, where x and y are mapped to AF markings 386 AF(x) and AF(y), respectively. Then, the mapping should ideally obey 387 the following criteria to keep linearity from IFPs to AF markings. 389 If x < y, AF(x) <= AF(y); 391 If x > y, AF(x) >= AF(y). 393 Although the above two do NOT imply that if x = y, AF(x) = AF(y), it 394 is usually so in practical implementation as it is straightforward. 395 Then, if the encoder algorithm generates a lot of packets with the 396 same IFP, all those packets will be assigned the same AF marking, 397 possibly resulting in an unbalanced distribution of AF markings in 398 the AF PHB group. Thus, an encoder with advanced technologies should 399 make good efforts to generate packets with a finer and more balanced 400 IFP distribution in the first place. 402 For example, if AF4x PHB group is used to send an H.264 AVC flow with 403 the IFP assignments in the example of Section 2.2, one possible IFP- 404 to-AF4x mapping is: 406 AF(0) = AF41 408 AF(1) = AF41 409 AF(2) = AF42 411 AF(3) = AF43 413 This mapping actually results in the following AF markings: 415 AF41 for in-band signals and IDR frames 417 AF42 for referenced P (rP) frames 419 AF43 for non-referenced P (nrP) frames and others 421 Now, consider two encoders that generate flow A and B, respectively, 422 both using this mapping, but with different IFP distributions as 423 follows. 425 Flow A 427 5% in IFP=0 for in-band signals 429 75% in IFP=1 for IDR frames 431 20% in IFP=2 for rP frames 433 Flow B 435 5% in IFP=0 for in-band signals 437 35% in IFP=1 for IDR frames 439 40% in IFP=2 for rP frames 441 20% in IFP=3 for nrP frames 443 Thus, 445 Flow A 447 80% in AF41 449 20% in AF42 451 0% in AF43 453 Flow B 455 40% in AF41 456 40% in AF42 458 20% in AF43 460 This results in exactly the two AF marking distribtions that we have 461 previously used in Section 1. 463 Note that in terms of encoded data size, an IDR frame is typically 10 464 times larger than a P frame on average. Assume that flow B's coding 465 efficiency has rP twice as large as nrP. Then, flow A and B might be 466 sending frames periodically in patterns by Group of Picture (GOP) as 467 follows: 469 Flow A: IDR, rP, rP, rP 471 Flow B: IDR, rP, nrP, rP, nrP, rP, nrP, rP, nrP 473 If so, it shows that flow B's encoder is making efforts to generate 474 discardable packets with more layers in a more balanced distribution, 475 which is desirable. 477 3. Normalization Marker (NM) 479 Referring to Figure 2, NM has 3 major components: IFP reconstructor, 480 IFP distribution meter, and normalizer. NM may operate in either 481 "color-aware" (CA) or "color-blind" (CB) mode. 483 +---------------+ +--------------+ +------------+ 484 | | | | | | 485 | IFP | | IFP | | | 486 ===>| Reconstructor |===>| Distribution |===>| Normalizer |===> 487 | in CA or CB | | Meter | | | 488 | | | | | | 489 +---------------+ +--------------+ +------------+ 491 Normalization Marker (NM) Architecture 493 Figure 2 495 The packets arrive at the IFP reconstructor which determines the IFP 496 of each packet depending on whether NM is in CA or CB mode. This is 497 fed into the IFP distribution meter that keeps a runtime statistics. 498 Then, by the runtime statistics and the IFP of the very packet, the 499 normalizer writes a proper AF-marking in that packet. 501 3.1. Color-Aware vs. Color-Blind Mode 503 When NM operates in "color-aware" (CA) mode, it reads the incoming 504 AF-markings that are carried in the packets as the drop precedence. 505 This CA mode should be supported in all NM implementations. 507 When NM operates in "color-blind" (CB) mode, which is optionally 508 supported, it reads certain bits field(s) other than the AF-markings 509 in the packets to determine the actual drop precedence of that 510 packet. This implies that NM may need DPI in the packets, e.g. 511 parsing into H.264 AVC header in each RTP packets, or alternatively 512 use some method where the drop precedence is carried from the encoder 513 in a customized bits field other than the AF-marking in each packet. 515 In comparison, CB is more complex than CA in implementation. 516 However, CB could probabily produce better normalization results 517 because the AF-markings are actually outcomes of an n-to-1 mapping 518 from IFPs, as previoulsy mentioned in Section 2.3, which can reduce 519 granularity, e.g. for IFPs x and y, if x > y at encoder, it is 520 possible that AF(x) = AF(y) when NM sees those packets in CA mode. 521 On the contrary, NM in CB mode may reconstruct IFPs x > y for those 522 packets by local DPI. 524 Note that NM in CB mode may fail to determine the IFP of a packet for 525 various reasons at runtime. If so, NM should randomly assign an IFP 526 to each of those packets with an even distribution over the IFPs. 527 The failure could be due to payload encryption that prevents DPI. 528 Another reason may be that the NM does not support the codec used for 529 encoding those packets in the flow. For example, an NM might only 530 support H.264 AVC but is unable to parse packets in H.264 Annex G 531 (SVC), so it fails to determine the IFPs of packets in an H.264 SVC 532 flow. 534 3.2. Distribution Meter 536 The IFP distribution meter keeps a runtime statistics of the IFPs per 537 flow so that the normalizer will be able to assign a proper AF- 538 marking for each packet. The types of statistics to collect at 539 runtime depend on the NM algorithm in the implementation. 541 For example, an NM implementation may keep a counter of packets per 542 IFP in a flow since the beginning of the flow's lifetime. Another 543 implementation may choose to keep only the running average of the 544 packet counter per IFP. An even simpler implementation may choose to 545 keep only the running average of IFPs of all packets per flow. 547 3.3. Normalizer 549 The normalizer should reference the runtime statistics kept by the 550 IFP distribution meter, and adaptively map the IFP of the very packet 551 to an AF marking, such that the resulting AF-marking distributions 552 for all flows are similar or even identical to a target distribution. 554 The target distribution of an NM can be simply an even distribution 555 over all possible AF-markings in the AF PHB group. However, in a 556 more complex NM implementation, it may allow configuration for other 557 target distributions as appropriate with the AQM configuration. 559 4. Acknowledgements 561 The authors would like to thank many colleagues for comments and 562 supports, and thank Shuai Dai for testing NM with actual H.264 video 563 endpoints. 565 5. IANA Considerations 567 This memo includes no request to IANA. 569 6. Security Considerations 571 This memo has no security consideration at the time of writing. 573 7. References 575 7.1. Normative References 577 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 578 and W. Weiss, "An Architecture for Differentiated 579 Services", RFC 2475, December 1998. 581 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 582 "Assured Forwarding PHB Group", RFC 2597, June 1999. 584 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 585 Marker", RFC 2697, September 1999. 587 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 588 Marker", RFC 2698, September 1999. 590 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 591 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 592 Felstaine, "A Framework for Integrated Services Operation 593 over Diffserv Networks", RFC 2998, November 2000. 595 [RFC3260] Grossman, D., "New Terminology and Clarifications for 596 Diffserv", RFC 3260, April 2002. 598 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 599 Guidelines for DiffServ Service Classes", RFC 4594, 600 August 2006. 602 7.2. Informative References 604 [H264] ITU-T Recommendation H.264, "Advanced video coding for 605 generic audiovisual services", March 2010. 607 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 608 Jacobson, "RTP: A Transport Protocol for Real-Time 609 Applications", STD 64, RFC 3550, July 2003. 611 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 612 Payload Format for H.264 Video", RFC 6184, May 2011. 614 Authors' Addresses 616 Cheng-Jia Lai 617 Cisco Systems 618 170 West Tasman Drive 619 San Jose, CA 95134 620 US 622 Email: chelai@cisco.com 624 Wenyi Wang 625 Cisco Systems 626 170 West Tasman Drive 627 San Jose, CA 95134 628 US 630 Email: wenywang@cisco.com 631 Stan Yang 632 Cisco Systems 633 170 West Tasman Drive 634 San Jose, CA 95134 635 US 637 Email: stanyang@cisco.com 639 Toerless Eckert 640 Cisco Systems 641 170 West Tasman Drive 642 San Jose, CA 95134 643 US 645 Email: eckert@cisco.com 647 Fred Yip 648 Cisco Systems 649 San Diego, CA 650 US 652 Email: fyip@cisco.com