idnits 2.17.1 draft-lai-tsvwg-normalizer-00.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 (February 8, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 2697 ** Downref: Normative reference to an Informational RFC: RFC 2698 ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Downref: Normative reference to an Informational RFC: RFC 3260 ** Downref: Normative reference to an Informational RFC: RFC 4594 Summary: 6 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: Standards Track S. Yang 5 Expires: August 12, 2013 T. Eckert 6 F. Yip 7 Cisco Systems 8 February 8, 2013 10 Normalization Marker for AF PHB Group in DiffServ 11 draft-lai-tsvwg-normalizer-00 13 Abstract 15 This memo describes a Normalization Marker (NM) at DiffServ (DS) 16 nodes to normalize the distribution of DS codepoint (DSCP) markings 17 for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is 18 useful for traffic conditioning with Active Queue Management (AQM) 19 when the AF PHB group is deployed for multimedia service classes that 20 carry video packets with advanced codec technologies. Using NM can 21 offer an incentive that is however missing in today's ecosystem of 22 practical deployment, i.e., when congestion occurs in the AF PHB 23 group, the network should allow a video codec to benefit from its 24 effort of generating finer layers of intra-flow precedence (IFP) with 25 discardable packets in a more balanced distribution. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 12, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. Video Packets in Structure . . . . . . . . . . . . . . . . 6 64 2.2. Intra-Flow Precedence (IFP) . . . . . . . . . . . . . . . 8 65 2.3. Mapping IFP to AF Markings . . . . . . . . . . . . . . . . 9 66 3. Normalization Marker (NM) . . . . . . . . . . . . . . . . . . 11 67 3.1. Color-Aware vs. Color-Blind Mode . . . . . . . . . . . . . 12 68 3.2. Distribution Meter . . . . . . . . . . . . . . . . . . . . 12 69 3.3. Normalizer . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Assured Forwarding (AF) Per-Hop Behavior (PHB) groups are described 81 in [RFC2597] (with terminology clarified in [RFC3260]) for DiffServ 82 (DS) multimedia service classes such as realtime video conferencing 83 and on-demand streaming. Four AF PHB groups have been defined in 84 [RFC4594] with DS codepoint (DSCP): AF1x, AF2x, AF3x and AF4x where 85 x=1, 2 or 3 for drop precedence in each independent AF PHB group. 86 The DS nodes that support an AF PHB group must set configuration of 87 Active Queue Management (AQM) properly w.r.t. those DSCP markings. 88 For example, for AF4x PHB group which includes AF41, AF42 and AF43 89 markings, an AQM implementation by Weighted Random Early Detection 90 (WRED) should be configured with some drop probabilities and queue 91 thresholds such that the packet loss rate of AF41 <= AF42 <= AF43 on 92 congestion of the queue. 94 For an AF PHB group, a DS boundary node or host in the DS domain 95 should use a marking algorithm that properly assigns AF markings of 96 drop precedence to all packets w.r.t. the traffic profiles and 97 Service Level Agreements (SLA). For example, [RFC2697] and [RFC2698] 98 use a token-bucket mechanism for metering each stream of packets and 99 respectively define "srTCM" and "trTCM" markers, to mark packets by 100 the data rate and burst size limit in traffic profiles. Those rate- 101 control markers can be useful at DS boundary nodes for traffic 102 conditioning [RFC2475] and to support IntServ/RSVP traffic over DS 103 regions [RFC2988]. Multiple markers may be applied to the same 104 stream, either on the same or multiple DS nodes along the path. For 105 example, srTCM and trTCM can operate in a so-called "color-aware" 106 mode such that for each incoming packet that already carries an AF 107 marking, the local srTCM/trTCM either keeps the same or lowers the 108 drop precedence of that packet by metering. 110 However, modern video codec technologies are being advanced not only 111 in coding efficiency (i.e. better compression ratio) but also in two 112 key areas for transport on IP networks: (1) encoder rate-control and 113 dynamic adaptation; (2) ability to generate discardable packets in 114 multiple layers to tolerate packet losses in the network without 115 significant degradation of video quality observed at the decoder. 116 For (1), the encoder dynamically limits its output rate of packets 117 into the AF PHB group, i.e., the encoder's host is the first DS node 118 equiped with srTCM/trTCM if it marks packets in that behavior. The 119 next DS node is the first-hop router which may add extra srTCM/trTCM 120 to enforce the traffic conditioning or policing from the network's 121 perspective. Thus, we consider this an incentive for (1) because an 122 encoder using a self rate-control is less likely to see packet losses 123 by the network. Unfortunately, an incentive for (2) is arguably 124 missing today. 126 To see the missing incentive for (2), consider the following example 127 where 2 video flows A and B with rate control are sent in AF4x PHB 128 group. Each sends 5Mbps on average with some burstiness, but still 129 complies with the rate and burst limit in its traffic profile. 130 However, A and B generate packets with AF4x markings in different 131 distributions of precentage: 133 Flow A 135 80% or 4Mbps in AF41 137 20% or 1Mbps in AF42 139 0% or 0Mbps in AF43 141 Flow B 143 40% or 2Mbps in AF41 145 40% or 2Mbps in AF42 147 20% or 1Mbps in AF43 149 Flow B at above is likely using a more advanced video technology to 150 generate multiple layers of discardable video packets, and thus, its 151 distribution of AF4x markings looks finer and more balanced. That 152 is, flow B acts more friendly to other flows in this AF4x PHB group. 154 Thus, we argue that the ecosystem in practical deployment should 155 offer an incentive for flows to behave similarly to what flow B is 156 doing above, i.e., on congestion, the AF4x PHB group should try to 157 drop packets in the same amount from each flow, while a flow with 158 finer layers of discardable packets and/or in a more balanced 159 distribution should be able to benefit from its own efforts and see 160 good results in video quality preservation. 162 Unfortunately, this incentive is still missing today. Suppose that 163 congestion occurs in the AF4x WRED queue where A and B compete for 164 bandwidth and there is no other flow, for simplicity. B's packet 165 loss rate is very likely to become higher than A's, despite B's 166 effort of acting friendly: 168 o If the queue drops 1Mbps in total, 170 A sees 0% or 0Mbps loss; 172 B sees 20% or 1Mbps loss (all its AF43 are lost). 174 o If the queue drops 4Mbps in total, 176 A sees 20% or 1Mbps loss (all its AF42 are lost); 178 B sees 60% or 3Mbps loss (all its AF42 and AF43 are lost). 180 Thus, to create the missing incentive at above, we propose a new 181 "Normalization Marker" (NM) and describe it in this memo. NM can be 182 deployed on DS boundary nodes for traffic conditioning in practical 183 deployment with AF PHB groups for multimedia service classes. In 184 summary, if NM is applied to a DS boundary node for an AF PHB group, 185 it re-assigns the AF markings of all packets per flow such that the 186 distributions of the AF markings are similar in all flows, i.e., it 187 "normalizes" the distributions of AF markings in all flows. It also 188 attempts to maintain the original orders of the intra-flow drop 189 precedence carried by the input AF markings, as linearly as possible. 190 After the AF-marking distributions are normalized, all those flows 191 should see very similar packet loss rates at AQM for this AF PHB 192 group on congestion of the queue. Then, a codec implementation may 193 have better video quality preservation on network congestion if it 194 employs a more advanced video technology to generate discardable 195 packets with finer markings of drop precedence in a more balanced 196 distribution. 198 +------------+ 199 | Runtime | 200 | Statistics | 201 | V 202 +-------+ +--------+ 203 | | | | 204 AF-Marked | Distr.| | Norm | AF-Marked 205 Packet Stream ===>| Meter |===>| Marker |===> Packet Stream 206 | | | | 207 +-------+ +--------+ 209 Normalization Marker (NM) with AF PHB Group 211 Figure 1 213 Note that the use of NM is not necessarily limited to video service 214 classes, but could be extended to wherever AF PHB groups can be used, 215 or to any other PHB groups that require a similar incentive NM can 216 provide. 218 2. Background 220 2.1. Video Packets in Structure 222 Modern video codec technologies such as ITU-T H.264/MPEG-4 AVC [H264] 223 typically generate a stream of encoded video packets with internal 224 structure of data dependency for decoding. This has been designed 225 for at least 3 fundamental reasons: 227 o Coding Efficiency: An encoder improves its coding efficiency 228 typically by reducing spatial and temporal redundancy of the 229 input. For video, spatial redundancy is reduced by intra-frame 230 motion prediction and compensation, while temporal redundancy 231 refers to inter-frame since a video stream is composed of a 232 sequence of frames or pictures in the temporal order. With motion 233 prediction, a frame can be encoded by referencing some pixels of 234 the picture data that will be decoded earlier either in the same 235 (intra) or another (inter) frame so that it can use significantly 236 fewer bits to encode this frame. The frame where the pixels are 237 referenced by any other frame is thus called a referenced frame in 238 the video stream; for example, Instantaneous Decoding Refresh 239 (IDR) in H.264 or Intra (I) frames are typically referenced by 240 subsequential frames, while Predictive (P) frames may be 241 referenced at the encoder's choice, by the Group of Picture (GOP) 242 profile, and/or by some proprietary algorithm in the codec 243 implementation. 245 o Lossy Network: To use network transport that may lose packets, the 246 encoder may choose to generate a stream with two or more layers 247 each of which the packets are marked with some layer identifier 248 (ID). The network can simply use the layer ID to determine the 249 drop precedence of each packet in the video stream. 251 * Layers in Hierarchy of Dependency: If these layers are coded in 252 hierarchy of dependency, the packets in an "enhancement" layer 253 will depend on 1 or more "base" layers to get decoded without 254 errors, while packets in a base layer without dependency can be 255 independently decoded without errors. 257 + If some enhancement layer packets are lost, the decoding 258 errors in that picture frame will not stay or cascade to 259 other frames given that no others depend on those lost data. 260 This nice property allows the network to safely drop packets 261 in some enhancement layers, if needed, without badly 262 impacting the video quality at decoder. 264 + If some base layer packets are lost, the impact can be 265 severe since these decoding errors will stay in buffer and 266 cascade to all other picture pixels that depend on the lost 267 data to decode in the current and/or a later frame. This 268 impact can last tens of seconds as the video quality 269 continues getting worse, resulting in unpleasant user 270 experiences, until the decoder receives the next IDR or I 271 frame, either on-demand or periodically, to remove those 272 errors. 274 For example, H.264 Annex G defines Scalable Video Coding (SVC) 275 using a 3-dimensional (i.e. spatical, temporal and quality) 276 hierarchy of layer dependency at the encoder's choice, but for 277 simplicity, it also defines a scalar number called Priority ID 278 (PID) in its header so the network could instead use PID, if 279 set by the encoder, to determine drop precedence in the stream. 281 * Layers NOT in Hierarchy of Dependency: Sometimes the encoder 282 will generate multiple layers without any dependency between 283 those layers. These mechanisms usually enlarge the amount of 284 encoded video data for vairous purposes. For example, 286 + Forward Error Correction (FEC) may be used at the encoder to 287 generate extra FEC packets, so that the decoder can tolerate 288 certain amounts of packet losses. 290 + Simulcast (i.e. simultaneous multicast) by an encoder will 291 actually generate multiple layers each of which can be 292 transmitted and decoded independently, in parallel by IP or 293 application multicast. Each layer carries video in a 294 different resolution and/or quality. The decoder can choose 295 1 or more of those layers to receive according to the 296 required, available or detected bandwidth, packet losses, 297 delays, jitter etc. in its network service. 299 With FEC and/or Simulcast, the encoder can still mark the 300 packets with different drop precedence in those layers to 301 better protect the more important data for video quality at 302 decoding when congestion occurs. 304 o In-Band Signaling: An encoded video stream usually carries in-band 305 control messages that are most critical for adequate encoder and 306 decoder behaviors. For example, 308 * H.264 Annex D defines Supplemental Enhancement Information 309 (SEI), which could also carry proprietary codec parameters. 310 These in-band control signals should be given the highest drop 311 precedence. 313 * Real Time Control Protocol (RTCP) carries in-band control 314 messages for Real Time Protocol (RTP) [RFC3550], which is 315 mostly used for realtime multimedia transmission on IP 316 networks. RTCP messages are defined as RTP packets with 317 special payload types in the RTP stream. RTCP packets should 318 be given the highest drop precedence but should receive the 319 same delay/jitter as regular RTP packets in the same stream. 321 2.2. Intra-Flow Precedence (IFP) 323 For abstraction, we define "Intra-Flow Precedence" (IFP) to represent 324 the drop precedence in one individual flow that may carry a video 325 stream of IP packets in multimedia networks. Here is a summary of 326 IFP characteristics: 328 o IFPs are drop precedence levels that are only significant within 329 each individual flow. 331 o IFPs are integer numbers that can be numerically compared if 332 needed. 0 represents the highest precedence. The larger numerical 333 value an IFP is, the lower precedence it represents. 335 o The number of IFP levels in each flow is not necessarily the same. 337 o IFPs between any 2 flows should NOT be compared to determine drop 338 precedence between their packets in a queue. 340 o IFPs may be assigned by the original encoder of the stream and 341 carried in some bits field of all packets in the stream. 343 o IFPs may be assigned or re-assigned by a middle box or router if 344 it is capable of understanding the stream packet format and codec 345 symantics. 347 For example, an H.264 AVC flow may have the following IFP assignments 348 at the video encoder's choice. 350 IFP = 0 for in-band signals 352 IFP = 1 for IDR frames 354 IFP = 2 for referenced P (rP) frames 356 IFP = 3 for non-referenced P (nrP) frames and others 358 IFP assignements as well as their distribution can vary a lot among 359 different encoder implementations and codec profiles. For example, 360 some encoders may generate both long-term and short-term referenced P 361 frames, where a long-term referenced P frame should have higher drop 362 precedence. In case of H.264 SVC, the IFP assignments could simply 363 be the same as the PID assignments if set by the encoder properly, or 364 be calculated based on the SVC layer ID that has 3 tuples for the 365 spatial, temporal and quality dimensions, respectively. 367 2.3. Mapping IFP to AF Markings 369 When a flow is sent in an AF PHB group, the number of its IFP levels 370 is not necessarily equal to the number of the AF markings. In fact, 371 since each of the currently defined AF PHB groups has only 3 AF 372 markings, it is likely that an encoder or DS node needs to apply an 373 n-to-1 mapping from IFPs to AF markings in practice. 375 The mapping decision is made usually by the encoder, but can also be 376 made by another DS node if necessary and if the DS node is able to 377 understand the encoded video packets, which may require Deep Packet 378 Inspection (DPI), e.g. to read in RTP payload and parse the H.264 379 headers [RFC6184], or in a proprietary bits field in the IP payload, 380 to retrieve or calculate the IFP of each packet in a flow before 381 locally mapping the IFP to an AF marking. 383 This n-to-1 mapping can be arbitrary but should be appropriate. 384 Consider 2 IFPs, say x and y, where x and y are mapped to AF markings 385 AF(x) and AF(y), respectively. Then, the mapping should ideally obey 386 the following criteria to keep linearity from IFPs to AF markings. 388 If x < y, AF(x) <= AF(y); 390 If x > y, AF(x) >= AF(y). 392 Although the above two do NOT imply that if x = y, AF(x) = AF(y), it 393 is usually so in practical implementation as it is straightforward. 394 Then, if the encoder algorithm generates a lot of packets with the 395 same IFP, all those packets will be assigned the same AF marking, 396 possibly resulting in an unbalanced distribution of AF markings in 397 the AF PHB group. Thus, an encoder with advanced technologies should 398 make good efforts to generate packets with a finer and more balanced 399 IFP distribution in the first place. 401 For example, if AF4x PHB group is used to send an H.264 AVC flow with 402 the IFP assignments in the example of Section 2.2, one possible IFP- 403 to-AF4x mapping is: 405 AF(0) = AF41 407 AF(1) = AF41 408 AF(2) = AF42 410 AF(3) = AF43 412 This mapping actually results in the following AF markings: 414 AF41 for in-band signals and IDR frames 416 AF42 for referenced P (rP) frames 418 AF43 for non-referenced P (nrP) frames and others 420 Now, consider two encoders that generate flow A and B, respectively, 421 both using this mapping, but with different IFP distributions as 422 follows. 424 Flow A 426 5% in IFP=0 for in-band signals 428 75% in IFP=1 for IDR frames 430 20% in IFP=2 for rP frames 432 Flow B 434 5% in IFP=0 for in-band signals 436 35% in IFP=1 for IDR frames 438 40% in IFP=2 for rP frames 440 20% in IFP=3 for nrP frames 442 Thus, 444 Flow A 446 80% in AF41 448 20% in AF42 450 0% in AF43 452 Flow B 454 40% in AF41 455 40% in AF42 457 20% in AF43 459 This results in exactly the two AF marking distribtions that we have 460 previously used in Section 1. 462 Note that in terms of encoded data size, an IDR frame is typically 10 463 times larger than a P frame on average. Assume that flow B's coding 464 efficiency has rP twice as large as nrP. Then, flow A and B might be 465 sending frames periodically in patterns by Group of Picture (GOP) as 466 follows: 468 Flow A: IDR, rP, rP, rP 470 Flow B: IDR, rP, nrP, rP, nrP, rP, nrP, rP, nrP 472 If so, it shows that flow B's encoder is making efforts to generate 473 discardable packets with more layers in a more balanced distribution, 474 which is desirable. 476 3. Normalization Marker (NM) 478 Referring to Figure 2, NM has 3 major components: IFP reconstructor, 479 IFP distribution meter, and normalizer. NM may operate in either 480 "color-aware" (CA) or "color-blind" (CB) mode. 482 +---------------+ +--------------+ +------------+ 483 | | | | | | 484 | IFP | | IFP | | | 485 ===>| Reconstructor |===>| Distribution |===>| Normalizer |===> 486 | in CA or CB | | Meter | | | 487 | | | | | | 488 +---------------+ +--------------+ +------------+ 490 Normalization Marker (NM) Architecture 492 Figure 2 494 The packets arrive at the IFP reconstructor which determines the IFP 495 of each packet depending on whether NM is in CA or CB mode. This is 496 fed into the IFP distribution meter that keeps a runtime statistics. 497 Then, by the runtime statistics and the IFP of the very packet, the 498 normalizer writes a proper AF-marking in that packet. 500 3.1. Color-Aware vs. Color-Blind Mode 502 When NM operates in "color-aware" (CA) mode, it reads the incoming 503 AF-markings that are carried in the packets as the drop precedence. 504 This CA mode should be supported in all NM implementations. 506 When NM operates in "color-blind" (CB) mode, which is optionally 507 supported, it reads certain bits field(s) other than the AF-markings 508 in the packets to determine the actual drop precedence of that 509 packet. This implies that NM may need DPI in the packets, e.g. 510 parsing into H.264 AVC header in each RTP packets, or alternatively 511 use some method where the drop precedence is carried from the encoder 512 in a customized bits field other than the AF-marking in each packet. 514 In comparison, CB is more complex than CA in implementation. 515 However, CB could probabily produce better normalization results 516 because the AF-markings are actually outcomes of an n-to-1 mapping 517 from IFPs, as previoulsy mentioned in Section 2.3, which can reduce 518 granularity, e.g. for IFPs x and y, if x > y at encoder, it is 519 possible that AF(x) = AF(y) when NM sees those packets in CA mode. 520 On the contrary, NM in CB mode may reconstruct IFPs x > y for those 521 packets by local DPI. 523 Note that NM in CB mode may fail to determine the IFP of a packet for 524 various reasons at runtime. If so, NM should randomly assign an IFP 525 to each of those packets with an even distribution over the IFPs. 526 The failure could be due to payload encryption that prevents DPI. 527 Another reason may be that the NM does not support the codec used for 528 encoding those packets in the flow. For example, an NM might only 529 support H.264 AVC but is unable to parse packets in H.264 Annex G 530 (SVC), so it fails to determine the IFPs of packets in an H.264 SVC 531 flow. 533 3.2. Distribution Meter 535 The IFP distribution meter keeps a runtime statistics of the IFPs per 536 flow so that the normalizer will be able to assign a proper AF- 537 marking for each packet. The types of statistics to collect at 538 runtime depend on the NM algorithm in the implementation. 540 For example, an NM implementation may keep a counter of packets per 541 IFP in a flow since the beginning of the flow's lifetime. Another 542 implementation may choose to keep only the running average of the 543 packet counter per IFP. An even simpler implementation may choose to 544 keep only the running average of IFPs of all packets per flow. 546 3.3. Normalizer 548 The normalizer should reference the runtime statistics kept by the 549 IFP distribution meter, and adaptively map the IFP of the very packet 550 to an AF marking, such that the resulting AF-marking distributions 551 for all flows are similar or even identical to a target distribution. 553 The target distribution of an NM can be simply an even distribution 554 over all possible AF-markings in the AF PHB group. However, in a 555 more complex NM implementation, it may allow configuration for other 556 target distributions as appropriate with the AQM configuration. 558 4. Acknowledgements 560 The authors would like to thank many colleagues for comments and 561 support of this work, with a special thank to Shuai Dai, who helped 562 in the NM prototyping and testing with actual video encoders. 564 5. IANA Considerations 566 This memo includes no request to IANA. 568 6. Security Considerations 570 This memo has no security consideration at the time of writing. 572 7. References 574 7.1. Normative References 576 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 577 and W. Weiss, "An Architecture for Differentiated 578 Services", RFC 2475, December 1998. 580 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 581 "Assured Forwarding PHB Group", RFC 2597, June 1999. 583 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 584 Marker", RFC 2697, September 1999. 586 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 587 Marker", RFC 2698, September 1999. 589 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 590 Timer", RFC 2988, November 2000. 592 [RFC3260] Grossman, D., "New Terminology and Clarifications for 593 Diffserv", RFC 3260, April 2002. 595 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 596 Guidelines for DiffServ Service Classes", RFC 4594, 597 August 2006. 599 7.2. Informative References 601 [H264] ITU-T Recommendation H.264, "Advanced video coding for 602 generic audiovisual services", March 2010. 604 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 605 Jacobson, "RTP: A Transport Protocol for Real-Time 606 Applications", STD 64, RFC 3550, July 2003. 608 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 609 Payload Format for H.264 Video", RFC 6184, May 2011. 611 Authors' Addresses 613 Cheng-Jia Lai 614 Cisco Systems 615 170 West Tasman Drive 616 San Jose, CA 95134 617 US 619 Phone: +1 408 853 6076 620 Email: chelai@cisco.com 622 Wenyi Wang 623 Cisco Systems 624 170 West Tasman Drive 625 San Jose, CA 95134 626 US 628 Phone: +1 408 853 6178 629 Email: wenywang@cisco.com 630 Stan Yang 631 Cisco Systems 632 170 West Tasman Drive 633 San Jose, CA 95134 634 US 636 Phone: +1 408 527 5338 637 Email: stanyang@cisco.com 639 Toerless Eckert 640 Cisco Systems 641 170 West Tasman Drive 642 San Jose, CA 95134 643 US 645 Phone: +1 408 902 2043 646 Email: eckert@cisco.com 648 Fred Yip 649 Cisco Systems 650 San Diego, CA 651 US 653 Phone: +1 408 527 6521 654 Email: fyip@cisco.com