idnits 2.17.1 draft-ietf-rmcat-cc-codec-interactions-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 18, 2016) is 2960 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) == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC5450' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC5506' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC5761' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 524, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-alvestrand-rmcat-remb (ref. 'I-D.alvestrand-rmcat-remb') == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-14 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-27 ** Downref: Normative reference to an Informational draft: draft-ietf-rmcat-cc-requirements (ref. 'I-D.ietf-rmcat-cc-requirements') ** Downref: Normative reference to an Experimental draft: draft-welzl-rmcat-coupled-cc (ref. 'I-D.welzl-rmcat-coupled-cc') ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Zanaty 3 Internet-Draft Cisco 4 Intended status: Standards Track V. Singh 5 Expires: September 19, 2016 Aalto University 6 S. Nandakumar 7 Cisco 8 Z. Sarkar 9 Ericsson AB 10 March 18, 2016 12 Congestion Control and Codec interactions in RTP Applications 13 draft-ietf-rmcat-cc-codec-interactions-02 15 Abstract 17 Interactive real-time media applications that use the Real-time 18 Transport Protocol (RTP) over the User Datagram Protocol (UDP) must 19 use congestion control techniques above the UDP layer since it 20 provides none. This memo describes the interactions and conceptual 21 interfaces necessary between the application components that relate 22 to congestion control, specifically the media codec control layer, 23 and the components dedicated to congestion control functions. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 19, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 3 61 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5 63 5. Codec - CC Interactions . . . . . . . . . . . . . . . . . . . 6 64 5.1. Mandatory Interactions . . . . . . . . . . . . . . . . . 6 65 5.1.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . 6 66 5.2. Optional Interactions . . . . . . . . . . . . . . . . . . 7 67 5.2.1. Media Elasticity . . . . . . . . . . . . . . . . . . 7 68 5.2.2. Startup Ramp . . . . . . . . . . . . . . . . . . . . 7 69 5.2.3. Delay Tolerance . . . . . . . . . . . . . . . . . . . 8 70 5.2.4. Loss Tolerance . . . . . . . . . . . . . . . . . . . 8 71 5.2.5. Forward Error Correction . . . . . . . . . . . . . . 8 72 5.2.6. Probing for Available Bandwidth . . . . . . . . . . . 8 73 5.2.7. Throughput Sensitivity . . . . . . . . . . . . . . . 9 74 5.2.8. Rate Stability . . . . . . . . . . . . . . . . . . . 9 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Interactive real-time media applications most commonly use RTP 85 [RFC3550] over UDP [RFC0768]. Since UDP provides no form of 86 congestion control, which is essential for any application deployed 87 on the Internet, these RTP applications have historically implemented 88 one of the following options at the application layer to address 89 their congestion control requirements. 91 o For media with relatively low packet rates and bit rates, such as 92 many speech codecs, some applications use a simple form of 93 congestion control that stops transmission permanently or 94 temporarily after observing significant packet loss over a 95 significant period of time, similar to the RTP circuit breakers 96 [I-D.ietf-avtcore-rtp-circuit-breakers]. 98 o Some applications have no explicit congestion control, despite the 99 clear requirements in RTP and its profiles AVP [RFC3551] and AVPF 100 [RFC4585], under the expectation that users will terminate media 101 flows that are significantly impaired by congestion (in essence, 102 human circuit breakers). 104 o For media with substantially higher packet rates and bit rates, 105 such as many video codecs, various non-standard congestion control 106 techniques are often used to adapt transmission rate based on 107 receiver feedback. 109 o Some experimental applications use standardized techniques such as 110 TCP-Friendly Rate Control (TFRC) [RFC5348]. However, for various 111 reasons, these have not been widely deployed. 113 The RTP Media Congestion Avoidance Techniques (RMCAT) working group 114 was chartered to standardize appropriate and effective congestion 115 control for RTP applications. It is expected such applications will 116 migrate from the above historical solutions to the RMCAT solution(s). 118 The RMCAT requirements [I-D.ietf-rmcat-cc-requirements] include low 119 delay, reasonably high throughput, fast reaction to capacity changes 120 including routing or interface changes, stability without over- 121 reaction or oscillation, fair bandwidth sharing with other instances 122 of itself and TCP flows, sharing information across multiple flows 123 when possible [I-D.welzl-rmcat-coupled-cc], and performing as well or 124 better in networks which support Active Queue Management (AQM), 125 Explicit Congestion Notification (ECN), or Differentiated Services 126 Code Points (DSCP). 128 In order to meet these requirements, interactions are necessary 129 between the application's congestion controller, the RTP layer, media 130 codecs, other components, and the underlying UDP/IP network stack. 131 This memo attempts to present a conceptual model of the various 132 interfaces based on a simplified application decomposition. This 133 memo discusses interactions between the congestion control and codec 134 control layer in a typical RTP Application. 136 Note that RTP can also operate over other transports with integrated 137 congestion control such as TCP [RFC5681] and DCCP [RFC4340], but that 138 is beyond the scope of RMCAT and this memo. 140 2. Key Words for Requirements 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Conceptual Model 148 It is useful to decompose an RTP application into several components 149 to facilitate understanding and discussion of where congestion 150 control functions operate, and how they interface with the other 151 components. The conceptual model in Figure 1 consists of the 152 following components. 154 +----------------------------+ 155 | +-----Config-----+ | 156 | | | | | 157 | | Codec | | 158 | | | | | | | 159 | APP +---RTP | RTCP---+ | 160 | | | | | | 161 | | | | | | 162 | +---Congestion-------|---Shared 163 | Control | State 164 +----------------------------+ 165 | 166 +----------------------------+ 167 | Network UDP | 168 | Stack | | 169 | IP | 170 +----------------------------+ 172 Figure 1 174 o APP: Application containing one or more RTP streams and the 175 corresponding media codecs and congestion controllers. For 176 example, a WebRTC browser. 178 o Config: Configuration specified by the application that provides 179 the media and transport parameters, RTP and RTCP parameters and 180 extensions, and congestion control parameters. For example, a 181 WebRTC Javascript application may use the 'constraints' API to 182 affect the media configuration, and SDP applications may negotiate 183 the media and transport parameters with the remote peer. This 184 determines the initial static configuration negotiated in session 185 establishment. The dynamic state may differ due to congestion or 186 other factors, but still must conform to limits established in the 187 config. 189 o Codec: Media encoder/decoder or other source/sink for the RTP 190 payload. The codec may be, for example, a simple monaural audio 191 format, a complex scalable video codec with several dependent 192 layers, or a source/sink with no live encoding/decoding such as a 193 mixer which selectively switches and forwards streams rather than 194 mixes media. 196 o RTP: Standard RTP stack functions, including media packetization / 197 de-packetization and header processing, but excluding existing 198 extensions and possible new extensions specific to congestion 199 control (CC) such as absolute timestamps or relative transmission 200 time offsets in RTP header extensions. RTCP: Standard RTCP 201 functions, including sender reports, receiver reports, extended 202 reports, circuit breakers [I-D.ietf-avtcore-rtp-circuit-breakers], 203 feedback messages such as NACK [RFC4585] and codec control 204 messages such as TMMBR [RFC5104], but excluding existing 205 extensions and possible new extensions specific to congestion 206 control (CC) such as REMB [I-D.alvestrand-rmcat-remb] (for 207 receiver-side CC), ACK (for sender-side CC), absolute and/or 208 relative timestamps (for sender-side or receiver-side CC), etc. 210 o Congestion Control: All functions directly responsible for 211 congestion control, including possible new RTP/RTCP extensions, 212 send rate computation (for sender-side CC), receive rate 213 computation (for receiver-side CC), other statistics, and control 214 of the UDP sockets including packet scheduling for traffic 215 shaping/pacing. 217 o Shared State: Storage and exchange of congestion control state for 218 multiple flows within the application and beyond it. 220 o Network Stack: The platform's underlying network functions, 221 usually part of the Operating System (OS), containing the UDP 222 socket interface and other network functions such as ECN, DSCP, 223 physical interface events, interface-level traffic shaping and 224 packet scheduling, etc. This is usually part of the Operating 225 System, often within the kernel; however, user-space network 226 stacks and components are also possible. 228 4. Implementation Model 230 There are advantages and drawbacks to implementing congestion control 231 in the application layer. It avoids platform dependencies and allows 232 for rapid experimentation, evolution and optimization for each 233 application. However, it also puts the burden on all applications, 234 which raises the risks of improper or divergent implementations. One 235 motivation of this memo is to mitigate such risks by giving proper 236 guidance on how the application components relating to congestion 237 control should interact. 239 Another drawback of congestion control in the application layer is 240 that any decomposition, including the one presented in Figure 1, is 241 purely conceptual and illustrative, since implementations have 242 differing designs and decompositions. Conversely, this can be viewed 243 as an advantage to distribute congestion control functions wherever 244 expedient without rigid interfaces. For example, they may be 245 distributed within the RTP/RTCP stack itself, so the separate 246 components in Figure 1 are combined into a single RTP+RTCP+CC 247 component as shown in Figure 2. 249 +----------------------------+ 250 | +-----Config | 251 | | | | 252 | | Codec | 253 | APP | | | 254 | +---RTP+RTCP+CC------|---Shared 255 +----------------------------+ State 256 | 257 +----------------------------+ 258 | Network UDP | 259 | Stack | | 260 | IP | 261 +----------------------------+ 263 Figure 2 265 5. Codec - CC Interactions 267 The following subsections identify the necessary interactions between 268 the Codec and congestion control (CC) layer interfaces that needs to 269 be considered important. 271 5.1. Mandatory Interactions 273 5.1.1. Allowed Rate 275 Allowed Rate (from CC to Codec): The max transmit rate allowed over 276 the next time interval. The time interval may be specified or may 277 use a default. The rate may be specified in bytes or packets or 278 both. The rate must never exceed permanent limits established in 279 session signaling such as the SDP bandwidth attribute [RFC4566] nor 280 temporary limits in RTCP such as TMMBR [RFC5104] or REMB 281 [I-D.alvestrand-rmcat-remb]. This is the most important interface 282 among all components, and is always required in any RMCAT solution. 283 In the simplest possible solution, it may be the only CC interface 284 required. 286 5.2. Optional Interactions 288 This section identifies certain advanced interactions that if 289 implemented by an RMCAT solution shall provide more granular control 290 over the congestion control state and the encoder behavior. As of 291 today, these interactions are optional to implement and future 292 evaluations of the existing/upcoming codecs might result in 293 considering some or all of these as Mandatory interactions. 295 5.2.1. Media Elasticity 297 Media Elasticity (from Codec to CC): Many live media encoders are 298 highly elastic, often able to achieve any target bit rate within a 299 wide range, by adapting the media quality. For example, a video 300 encoder may support any bit rate within a range of a few tens or 301 hundreds of kbps up to several Mbps, with rate changes registering as 302 fast as the next video frame, although there may be limitations in 303 the frequency of changes. Other encoders may be less elastic, 304 supporting a narrower rate range, coarser granularity of rate steps, 305 slower reaction to rate changes, etc. Other media, particularly some 306 audio codecs, may be fully inelastic with a single fixed rate. CC 307 can beneficially use codec elasticity, if provided, to plan Allowed 308 Rate changes, especially when there are multiple flows sharing CC 309 state and bandwidth. 311 5.2.2. Startup Ramp 313 Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an 314 important moment in a conversation. Rapid rate adaptation during 315 startup is therefore important. The codec should minimize its 316 startup media rate as much as possible without adversely impacting 317 the user experience, and support a strategy for rapid rate ramp. The 318 CC should allow the highest startup media rate as possible without 319 adversely impacting network conditions, and also support rapid rate 320 ramp until stabilizing on the available bandwidth. Startup can be 321 viewed as a negotiation between the codec and the CC. The 322 specification of the ramp may take a number of forms depending on the 323 interface to the codec; for example, a percentage bit rate increase 324 per RTT (or other time interval), or an increased transmit window (in 325 number of packets and/or octets allowed outstanding) are all 326 potential forms. The codec requests a startup rate and ramp, and the 327 CC responds with the allowable parameters which may be lower/slower. 328 The RMCAT requirements also include the possibility of bandwidth 329 history to further accelerate or even eliminate startup ramp time. 330 While this acceleration or elimination in ramp time is beneficial to 331 the session user experience when bandwidth is sufficient, it can be 332 detrimental if significant congestion results (the user experience of 333 this session and all other sessions traversing the point of 334 congestion may unnecessarily degrade). Therefore, it is recommended 335 that use of potentially stale congestion state for acceleration or 336 elimination in ramp up be limited to topologies or deployments 337 believed to have sufficient bandwidth margin or those in which the 338 potential transient congestion risk is acceptable. Note that startup 339 can often commence before user interaction or conversation to reduce 340 the chance of clipped media. 342 5.2.3. Delay Tolerance 344 Delay Tolerance (from Codec to CC): An ideal CC will always minimize 345 delay and target zero. However, real solutions often need a real 346 non-zero delay tolerance. The codec should provide an absolute delay 347 tolerance, perhaps expressed as an impairment factor to mix with 348 other metrics. 350 5.2.4. Loss Tolerance 352 Loss Tolerance (from Codec to CC): An ideal CC will always minimize 353 packet loss and target zero. However, real solutions often need a 354 real non-zero loss tolerance. The codec should provide an absolute 355 loss tolerance, perhaps expressed as an impairment factor to mix with 356 other metrics. Note this is unrecoverable post-repair loss after 357 retransmission or forward error correction. 359 5.2.5. Forward Error Correction 361 Forward Error Correction (FEC): Simple FEC schemes like XOR Parity 362 codes [RFC5109] may not handle consecutive or burst loss well. More 363 complex FEC schemes like Reed-Solomon [RFC6865] or Raptor [RFC6330] 364 codes are more effective at handling bursty loss. The sensitivity to 365 packet loss therefore depends on the media (source) encoding as well 366 as the FEC (channel) encoding, and this sensitivity may differ for 367 different loss patterns like random, periodic, or consecutive loss. 368 Expressing this sensitivity to the congestion controller may help it 369 choose the right balance between optimizing for throughput versus low 370 loss. 372 5.2.6. Probing for Available Bandwidth 374 FEC can also be used to probe for additional available bandwidth, if 375 the application desires a higher target rate than the current rate. 376 FEC is preferable to synthetic probes since any contribution to 377 congestion by the FEC probe will not impact the post-repair loss rate 378 of the source media flow while synthetic probes may adversely affect 379 the loss rate. Note that any use of FEC or retransmission must 380 ensure that the total flow of all packets including FEC, 381 retransmission and original media never exceeds the Allowed Rate. 383 5.2.7. Throughput Sensitivity 385 Throughput Sensitivity (from Codec to CC): An ideal CC will always 386 maximize throughput. However, real solutions often need a trade-off 387 between throughput and other metrics such as delay or loss. The 388 codec should provide throughput sensitivity, perhaps expressed as an 389 impairment factor (for low throughputs) to mix with other metrics. 391 5.2.8. Rate Stability 393 Rate Stability (from Codec to CC): The CC algorithm must strike a 394 balance between rate stability and fast reaction to changes in 395 available bandwidth. The codec should provide its preference for 396 rate stability versus fast and frequent reaction to rate changes, 397 perhaps expressed as an impairment factor (for high rate variance 398 over short timescales) to mix with other metrics. 400 6. Acknowledgements 402 The RMCAT design team discussions contributed to this memo. The 403 authors would also like to thank Michael Ramalho for reviewing and 404 suggesting text improvements. 406 7. IANA Considerations 408 This memo includes no request to IANA. 410 8. References 412 8.1. Normative References 414 [I-D.alvestrand-rmcat-remb] 415 Alvestrand, H., "RTCP message for Receiver Estimated 416 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 417 progress), October 2013. 419 [I-D.ietf-avtcore-rtp-circuit-breakers] 420 Perkins, C. and V. Varun, "Multimedia Congestion Control: 421 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 422 avtcore-rtp-circuit-breakers-14 (work in progress), March 423 2016. 425 [I-D.ietf-mmusic-sdp-bundle-negotiation] 426 Holmberg, C., Alvestrand, H., and C. Jennings, 427 "Negotiating Media Multiplexing Using the Session 428 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 429 negotiation-27 (work in progress), February 2016. 431 [I-D.ietf-rmcat-cc-requirements] 432 Jesup, R. and Z. Sarker, "Congestion Control Requirements 433 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 434 requirements-09 (work in progress), December 2014. 436 [I-D.welzl-rmcat-coupled-cc] 437 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 438 control for RTP media", draft-welzl-rmcat-coupled-cc-05 439 (work in progress), June 2015. 441 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 442 10.17487/RFC0768, August 1980, 443 . 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 447 RFC2119, March 1997, 448 . 450 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 451 Jacobson, "RTP: A Transport Protocol for Real-Time 452 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 453 July 2003, . 455 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 456 Video Conferences with Minimal Control", STD 65, RFC 3551, 457 DOI 10.17487/RFC3551, July 2003, 458 . 460 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 461 Congestion Control Protocol (DCCP)", RFC 4340, DOI 462 10.17487/RFC4340, March 2006, 463 . 465 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 466 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 467 July 2006, . 469 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 470 "Extended RTP Profile for Real-time Transport Control 471 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 472 10.17487/RFC4585, July 2006, 473 . 475 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 476 "Codec Control Messages in the RTP Audio-Visual Profile 477 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 478 February 2008, . 480 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 481 Correction", RFC 5109, DOI 10.17487/RFC5109, December 482 2007, . 484 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 485 Friendly Rate Control (TFRC): Protocol Specification", RFC 486 5348, DOI 10.17487/RFC5348, September 2008, 487 . 489 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 490 RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, 491 . 493 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 494 Real-Time Transport Control Protocol (RTCP): Opportunities 495 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 496 2009, . 498 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 499 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 500 . 502 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 503 Control Packets on a Single Port", RFC 5761, DOI 10.17487/ 504 RFC5761, April 2010, 505 . 507 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 508 and L. Minder, "RaptorQ Forward Error Correction Scheme 509 for Object Delivery", RFC 6330, DOI 10.17487/RFC6330, 510 August 2011, . 512 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 513 Matsuzono, "Simple Reed-Solomon Forward Error Correction 514 (FEC) Scheme for FECFRAME", RFC 6865, DOI 10.17487/ 515 RFC6865, February 2013, 516 . 518 8.2. Informative References 520 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 521 RFC2818, May 2000, 522 . 524 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 525 Text on Security Considerations", BCP 72, RFC 3552, DOI 526 10.17487/RFC3552, July 2003, 527 . 529 Authors' Addresses 531 Mo Zanaty 532 Cisco 534 Email: mzanaty@cisco.com 536 Varun Singh 537 Aalto University 539 Email: varun@comnet.tkk.fi 541 Suhas Nandakumar 542 Cisco 544 Email: snandaku@cisco.com 546 Zaheduzzaman Sarker 547 Ericsson AB 549 Email: zaheduzzaman.sarker@ericsson.com