RTCWEB G. Mandyam Internet-Draft Qualcomm Innovation Center Intended status: Informational M. Luby Expires: August 2, 2013 Qualcomm Technologies Inc. T. Stockhammer Nomor Research C. Foisy Qualcomm Technologies Inc. January 29, 2013 Forward Error Correction for WebRTC using FEC FRAME draft-mandyam-rtcweb-fecframe-00 Abstract WebRTC provides a solution for peer-to-peer streaming between web applications by leveraging a Real-Time Protocol (RTP) stream between two clients. This RTP stream is expected to be sent over an UDP (Universal Datagram Protocol) connection, which by definition has no built-in reliability. Recently the FEC FRAME Working Group of the IETF has come up with a framework and technical recommendations for applying forward error correction (FEC) to unreliable streams. This framework can be applied to WebRTC with minimal changes to the specification. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 2, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Mandyam, et al. Expires August 2, 2013 [Page 1] Internet-Draft FECFRAME4WebRTC January 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Block Code Introduction . . . . . . . . . . . . . . . . . 3 2. FEC FRAME Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Latency Mitigation . . . . . . . . . . . . . . . . . . . . . . 6 4. Session Description Protocol Impacts . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Mandyam, et al. Expires August 2, 2013 [Page 2] Internet-Draft FECFRAME4WebRTC January 2013 1. Introduction Forward Error Correction (FEC) is a well-known technique for improving the reliability of packet transmission over networks that do not provide guaranteed packet delivery by adding repair packets to the original packets. The IETF has defined a "building block" approach to the specification of FEC to streaming protocols, based on RFC 5052 [RFC5052] and RFC 6363 [RFC6363]. Borrowing from the terminology of RFC 5052 [RFC5052], the FEC can be applied to any payload of a CDP (content delivery protocol). Since WebRTC defines RTP as its target CDP for media streaming, it stands to reason that the IETF building block framework is readily applicable to WebRTC. 1.1. Block Code Introduction Detailed understanding of all the different types of FEC is beyond the scope of this document. Note that FEC in its most fundamental description involves the encoding of a message derived from an alphabet into a representation that is also derived from the same alphabet. Moreover, FEC encoding results in redundancy, i.e. the addition of information to the message that can help in retrieving the original message in the presence of loss of parts of the transmission. If the message is composed of k individual entries from the alphabet and the FEC encoding results in a new collection of entries (also referred to as a codeword) of length n, then the FEC code is said to be of rate k/n or is sometimes said to be a (k,n) code. FEC's that operate on individual messages without dependency on other messages in a given sequence are sometimes referred to as block codes. As another way of visualizing this, assume that a message to be sent over a communications channel is derived from a grouping of symbols derived from an alphabet (e.g. a binary alphabet can be represented by the set {0,1}), and can be represented as a collection of words {m_0, m_1, ..., m_(k-1)}. Then the resultant codeword generated by applying the FEC can be represented as a collection of words derived from the same alphabet {c_0, c_1, ..., c_(n-1)}. If all n of the words of this codeword are sent over a communications link and at most n-k of the words of the codeword are lost, then ideally an FEC code can completely recover the original message. The block code can be represented in terms of a generator matrix G (of binary entries) acting upon a message vector m. Mandyam, et al. Expires August 2, 2013 [Page 3] Internet-Draft FECFRAME4WebRTC January 2013 G = |g_(0,0) g_(0,1) ... g_(0,n-1) |, m =|m_0 m_1 ... m_(k-1)| |g_(1,0) g_(1,1) ... g_(1,n-1) | | ... | |g_(k-1,0) g_(k-1,1) ... g_(k-1,n-1)| Generator Matrix and Message Vector Figure 1 A codeword c is generated by a matrix-vector multiplication of G with m. Some of the words of the codeword c, each word sent in a separate packet together with a word identifier, may be lost and not arrive at the receiver. The receiver can determined which words are received in packets from the word identifiers included in the packets. Based on the word identifiers, the FEC decoder can recover the original message. If the block code in question is systematic, then a subset of the generated codeword is the original message itself. Such codes allow for a clean separation of the codeword into source symbols and redundancy symbols. In this case, then generator matrix can be represented as G = |g_(0,0) g_(0,1) ... g_(0,n-k-1) 1 0 0 ... 0| |g_(1,0) g_(1,1) ... g_(1,n-k-1) 0 1 0 ... 0| | ... ... | |g_(k-1,0) g_(k-1,1) ... g_(k-1,n-k-1)0 0 0 ... 1| Generator Matrix for Systematic Code Figure 2 A more detailed overview of block codes, their derivation, and theoretical analysis can be found in textbooks such as [Wicker]. 2. FEC FRAME Overview The building block approach of RFC 6363 [RFC6363] allows for a straightforward application of a preferred block code to streaming protocols such as RTP. The chosen block code must satisfy the requirements of RFC 5052 [RFC5052]. A valid FEC encoding scheme will have an IANA-assigned FEC Encoding ID. Since the building block approach to applying block codes to streaming protocols has been standardized by the IETF, it is not necessary to discuss the Mandyam, et al. Expires August 2, 2013 [Page 4] Internet-Draft FECFRAME4WebRTC January 2013 specified approach in this document. However, a simple mapping between the Framework Architecture of RFC 6363 [RFC6363] is reproduced here to provide context. + - - - - - - - - - - - - - - - - - - - - - - - -+ | +--------------------------------------------+ | | Application Layer | | +--------------------------------------------+ | | | | + -- -- -- -- -- -- -- -- -- -- --+ | | | RTP (Optional) | | | | | |- Configuration/ +- -- -- -- -- -- -- -- -- -- -- -+ | Coordination | | | | | ADU flows | | | v | +--------------------------------------------+ +------------+ | | FEC Framework (This document) |<--->| FEC Scheme | +--------------------------------------------+ +------------+ | | | | Source | Repair | | | | | +-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+ | | RTP Layer | | RTP Processing | | | | (Optional) | +-- -- -- |- -- -+ | | | +-- -- -- -- -- -- -- |--+ | | | | RTP (De)multiplexing | | | +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ | | | +--------------------------------------------+ | | Transport Layer (e.g., UDP) | | +--------------------------------------------+ | | | +--------------------------------------------+ | | IP | | +--------------------------------------------+ | | Content Delivery Protocol | + - - - - - - - - - - - - - - - - - - - - - - - + FEC Framework Architecture Figure 3 With respect to the above figure, the application layer would essentially be a logical collection of the user agent along with the Mandyam, et al. Expires August 2, 2013 [Page 5] Internet-Draft FECFRAME4WebRTC January 2013 WebRTC-enabled web application, and the application data unit (ADU) flows could be the RTP packets provided by the user agent implementation of WebRTC. Note that it is also allowed in the specification to multiplex additional RTP-encapsulated redundancy packets onto UDP, which is useful for providing additional resiliency for multicast traffic. After application of block encoding, the encoded blocks can be identified by an FEC Source ID which is appended to the block of data. It is not required if there are other means to indicate to the receiver a unique identifier for the encoded data block. It should be noted that the use of FEC does not come without its own costs. For instance, the selection of the block size (ADU size) has a direct impact on latency as the transmission of the stream must be delayed while the payload is formed for FEC encoding. This is important due to the fact that many block coding schemes tend to be more effective with larger block sizes. Moreover, encoding and decoding latency are applicable (although advancement in processor speed has made this less of an issue). Finally, the amount of redundancy affects the overall throughput. The larger the amount of redundancy, the less likelihood that random losses will result in the receiver being unable to decode data. However, greater redundancy (i.e. a smaller k/n ratio) has a direct impact on the amount of application data that can be sent over a fixed time interval. 3. Latency Mitigation While FEC encoding provides resiliency in the face of packet loss, it also introduces latency. Assume a system where the source rate for a stream is R bits/second, and the number of bits to be encoded using a k/n code is B. In order to encode B bits to produce the necessary redundancy, which is in the amount given by B(n-k)/k, it is necessary for the sender to buffer a block of B information bits. Therefore, one would assume that the sender would have to delay transmission by at least the time it takes to generate one block of information bits from the source, i.e. B/R. However, note that the in most block codes, the first part of the codeword sent is the actual source information bits. Therefore it is conceivable that transmission from the sender to receiver could commence while the source bits are being buffered at the sender-side encoder. Assume that the rate of the code is k/n = 1/2, i.e. the number of redundancy bits is equal to the number of source bits when encoding a block of data. The sender, as one latency mitigation strategy, could delay transmission of the encoded data (source and redundancy bits) by half the duration of a source block, B/(2R), and then send at twice the source data rate (2R). After the entire block of Mandyam, et al. Expires August 2, 2013 [Page 6] Internet-Draft FECFRAME4WebRTC January 2013 information bits B has been buffered at the sender, then the sender can transmit the remaining code bits at 2R. This results in an overall latency of B(n-k)/(2k), or half of the time it takes for the source to generate B bits of data. time(s) 0 B/(2R) B/R 3B/(2R) ... +--------------+--------------+--------------+ | Delay data | Send source | Send redun- | Sender | transmission | bits at 2R | dancy at 2R | +--------------+--------------+--------------+ ^ Generate Redundancy +--------------+--------------+--------------+ | Wait for data| Rcv. source |Rcv. redundan-| Receiver | | bits at 2R | cy at 2R | +--------------+--------------+--------------+ ^ Decode and send to renderer Latency Mitigation Strategy Timeline for Rate 1/2 Block Code Figure 4 4. Session Description Protocol Impacts The implications for SDP at the time of the writing of this document are not fully known as there is still debate as to the semantics of SDP for WebRTC. A proposal for SDP usage in WebRTC was described in [I-D.nandakumar-rtcweb-sdp]. In addition, the SDP elements required for FEC are described in RFC 6364 [RFC6364]. Leveraging the example of Section 5.1 in [I-D.nandakumar-rtcweb-sdp], a 2-way video and audio session offer/answer exchange can be depicted for two sample endpoints (Alice and Bob) with the video stream being protected by FEC: Alice->Bob: Offer(Audio:G.711,AMR-WB Video:H.264 FEC-encoding:Reed- Solomon,LDPC Staircase) Bob->Alice: Answer(Audio:G.711,AMR-WB Video:H.264 FEC-encoding:Reed- Solomon) Alice->Bob: Two-way AMR-WB Audio, H.264 Video, Reed-Solomon FEC- Encoding Mandyam, et al. Expires August 2, 2013 [Page 7] Internet-Draft FECFRAME4WebRTC January 2013 +------------------------------------------+------------------------+ | SDP Contents | Notes | +------------------------------------------+------------------------+ | v=0 | Protocol Version | | o=alice 20518 0 IN IP4 0.0.0.0 | Session Origin | | s=FEC for WebRTC | Session Name | | t=0 0 | Time session is active | | a=ice-ufrag:074c6550 | Session Level ICE param| | a=ice-pwd:a28a397a4c3f31747d1ee3474af08a | Session Level ICE param| | 068 | | | a=fingerprint:sha-1 | Session Level DTLS | | 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:7 | Fingerprint for SRTP | | 0:9d:1f:66:79:a8:07 | | | a=group:FEC-FR S1 R1 | FEC group source/repair| | | | | m=audio 54609 RTP/SAVPF 0 109 98 | | | c= IN IP4 24.23.204.141 | Connection Data | | a=rtpmap:0 PCMU/8000 | G.711 8kbps | | a=rtpmap:109 AMR-WB/16000/2 | 2-chan AMR-WB 16 kbps | | a=fmtp:99 interleaving=30 | | | a=maxptime:100 | | | a=sendrecv | Can send/rcv audio | | a=mid:S0 | | | a=rtcp-mux | Can mux RTP/RTCP | | b=AS:256 | Bandwidth | | b=RS:0 | RTCP Bandwdith | | b=RR:0 | RTCP Bandwidth | | | | | a=candidate:0 1 UDP 2113667327 | Host ICE Candidate | | 192.168.1.4 54609 typ host | for audio | | a=candidate:1 1 UDP 694302207 | Server Reflexive ICE | | 24.23.204.141 54609 typ srflx raddr | Candidate for the | | 192.168.1.4 rport 54609 | above host candidate | | a=rtcp-fb:109 nack | NACK RTCP feedback | | | | | m=video 62537 RTP/SAVPF 99 120 | | | c= IN IP4 24.23.204.141 | Connection data-source | | a=rtpmap:99 H264/90000 | | | a=fmtp:99 | | | profile-level-id=4d0028;packetization-mo | | | de=1 | | | a=fec-source-flow: id=0 | Source flow for FEC | | a=mid:S1 | | | a=sendrecv | Can send/rcv video | | a=rtcp-mux | Can mux RTP/RTCP | | m=application 30000 UDP/FEC | | | c= IN IP4 24.23.204.141 | Connection data-repair | | a=fec-repair-flow: encoding-id=2; | Reed-Solomon code | Mandyam, et al. Expires August 2, 2013 [Page 8] Internet-Draft FECFRAME4WebRTC January 2013 | fssi=E:1400,S:0,m:8 | support | | a=fec-repair-flow: encoding-id=3; | LDPC Staircase support | | fssi=seed:1234,E:1400,S:0,n1m3:0 | | | a=repair-window:200ms | Time duration of source| | | and repair blocks | | a=mid:R1 | | | | | | a=candidate:0 1 UDP 2113667327 | Host ICE Candidate | | 192.168.1.4 62537 typ host | for video | | a=candidate:1 1 UDP 1694302207 | Server Reflexive ICE | | 24.23.204.141 62537 typ srflx raddr | Candidate for the | | 192.168.1.4 rport 62537 | above host candidate | +------------------------------------------+------------------------+ SDP Offer (Alice to Bob) Figure 5 +------------------------------------------+------------------------+ | SDP Contents | Notes | +------------------------------------------+------------------------+ | v=0 | Protocol Version | | o=bob 16833 0 IN IP4 0.0.0.0 | Session Origin | | s=FEC for WebRTC | Session Name | | t=0 0 | Time session is active | | a=ice-ufrag:c300d85b | Session Level ICE param| | a=ice-pwd:de4e99bd291c325921d5d47efbabd9 | Session Level ICE param| | a2 | | | a=fingerprint:sha-1 | Session Level DTLS | | 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:7 | Fingerprint for SRTP | | 0:9d:1f:66:79:a8:07 | | | a=group:FEC-FR S1 R1 | FEC group source/repair| | | | | m=audio 49203 RTP/SAVPF 109 | | | c= IN IP4 98.248.92.77 | Connection Data | | a=rtpmap:109 AMR-WB/16000/2 | 2-chan AMR-WB 16 kbps | | a=fmtp:99 interleaving=30 | | | a=maxptime:100 | | | a=sendrecv | Can send/rcv audio | | a=mid:S0 | | | a=rtcp-mux | Can mux RTP/RTCP | | b=AS:256 | Bandwidth | | b=RS:0 | RTCP Bandwdith | | b=RR:0 | RTCP Bandwidth | | | | Mandyam, et al. Expires August 2, 2013 [Page 9] Internet-Draft FECFRAME4WebRTC January 2013 | a=candidate:0 1 UDP 2113667327 | Host ICE Candidate | | 192.168.1.7 49203 typ host | for audio | | a=candidate:1 1 UDP 694302207 | Server Reflexive ICE | | 98.248.92.77 49203 typ srflx raddr | Candidate for the | | 192.168.1.7 rport 49203 | above host candidate | | a=rtcp-fb:109 nack | NACK RTCP feedback | | | | | m=video 63130 RTP/SAVPF 99 | | | c= IN IP4 98.248.92.771 | Connection data-source | | a=rtpmap:99 H264/90000 | | | a=fmtp:99 | | | profile-level-id=4d0028;packetization-mo | | | de=1 | | | a=fec-source-flow: id=0 | Source flow for FEC | | a=mid:S1 | | | a=sendrecv | Can send/rcv video | | a=rtcp-mux | Can mux RTP/RTCP | | m=application 30000 UDP/FEC | | | c= IN IP4 98.248.92.771 | Connection data-repair | | a=fec-repair-flow: encoding-id=2; | Reed-Solomon code | | fssi=E:1400,S:0,m:8 | support | | a=repair-window:200ms | Time duration of source| | | and repair blocks | | a=mid:R1 | | | | | | a=candidate:0 1 UDP 2113667327 | Host ICE Candidate | | 192.168.1.7 63130 typ host | for video | | a=candidate:1 1 UDP 1694302207 | Server Reflexive ICE | | 98.248.92.77 63130 typ srflx raddr | Candidate for the | | 192.168.1.7 rport 63130 | above host candidate | +------------------------------------------+------------------------+ SDP Answer (Bob to Alice) Figure 6 5. Discussion The use of FEC in WebRTC should not require a significant standards change, as the FEC Framework approved by the IETF already specifies the use of FEC for streaming protocols. There certainly exists tradeoffs between the benefits of FEC at smaller block sizes, and the latency incurred due to larger block sizes. However, these tradeoffs should be considered by WebRTC implementers and not as part of the standardization effort for WebRTC. An item that can be considered is whether a specific FEC scheme should be designated as mandatory-to- Mandyam, et al. Expires August 2, 2013 [Page 10] Internet-Draft FECFRAME4WebRTC January 2013 implement, so as to provide a level of interoperability among WebRTC clients. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations Security considerations are TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007. [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011. [RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011. 8.2. Informative References [I-D.nandakumar-rtcweb-sdp] Nandakumar, S. and C. Jennings, "SDP for the WebRTC", draft-nandakumar-rtcweb-sdp-00 (work in progress), October 2012. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-09 (work in progress), March 2008. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Mandyam, et al. Expires August 2, 2013 [Page 11] Internet-Draft FECFRAME4WebRTC January 2013 Text on Security Considerations", BCP 72, RFC 3552, July 2003. [Wicker] Wicker, S., "Error Control Systems", Upper Saddle River, NJ: Prentice-Hall Inc., 1995. Appendix A. Additional Stuff This becomes an Appendix. Authors' Addresses Giridhar Mandyam Qualcomm Innovation Center 5775 Morehouse Drive San Diego, California 92121 USA Phone: +1 858 651 7200 Email: mandyam@quicinc.com Mike Luby Qualcomm Technologies Inc. 2030 Addison Street Berkeley, California 94704 USA Phone: +1 510 725 3502 Email: luby@qti.qualcomm.com Thomas Stockhammer Nomor Research Brecherspitzstrasse 8 Munich 81541 Germany Phone: +49 8997898002 Email: stockhammer@nomor.de Mandyam, et al. Expires August 2, 2013 [Page 12] Internet-Draft FECFRAME4WebRTC January 2013 Christian Foisy Qualcomm Technologies Inc. Phone: +1 450 510 3202 Email: cfoisy@qti.qualcomm.com Mandyam, et al. Expires August 2, 2013 [Page 13]