idnits 2.17.1 draft-cbran-rtcweb-data-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When sending a datagram, a single byte with the value 62 MUST be prepended to the data to be sent. The data is then sent over the UDP or a DTLS flow that has been set up by ICE. The receiver MUST send an acknowledgement for each packets it receives. This acknowledgment is a UDP or DTLS datagram containing a single byte with the value of 63. The packet loss rate is computed by comparing the number of packet sent to the of acknowledgements received within the past 2 seconds. The packet loss rate and amount of data sent is used with the TFRC-SP algorithm to compute a maximum safe bandwidth. The sender MUST not exceed this bandwidth. If an application requests the browser, or other RTC-Web client application, to send a packet that would exceed the bandwidth, the RTC-Web client application MUST signal an error to the requesting application and drop the packet. -- The document date (July 4, 2011) is 4679 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) -- No information found for draft-ekr-security-considerations-for-rtc-web - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ekr-security-considerations-for-rtc-web' ** Downref: Normative reference to an Experimental RFC: RFC 4828 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bran 3 Internet-Draft C. Jennings 4 Intended status: Standards Track Cisco 5 Expires: January 5, 2012 July 4, 2011 7 RTC-Web Non-Media Data Transport Requirements 8 draft-cbran-rtcweb-data-00 10 Abstract 12 This document outlines a protocol and requirements for RTC-Web client 13 application to transmit real-time, non-media data. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may not be modified, 19 and derivative works of it may not be created, and it may not be 20 published except as an Internet-Draft. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 5, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Non-Media Data Transport Requirements . . . . . . . . . . . . . 3 54 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 This specification will focus on the transport of real-time non-media 65 data requirements for RTC-Web client applications. An example of 66 real-time non-media data, would be a characters screen position 67 within an multiplayer HTML5 video game. 69 The non-media data transport requirements fit into a series of 70 specifications have been created to address RTC-Web negotiation and 71 signaling protocols, security requirements, media transmission and 72 use cases. More information on the RTC-Web can be found here: 74 [TODO put links to supporting drafts here] 76 2. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 3. Non-Media Data Transport Requirements 84 The RTC-WEB will enable for rich voice and video communications from 85 client applications, such as a web browser. One of the natural 86 extensions of the RTC-WEB and the work emerging from the HTML5 87 community is video games. Video games have a similar stringent real- 88 time requirement for exchanging non-media data types such as a 89 player's screen position. 91 The question of how best to handle non-media data types has been 92 raised. There have been proposals to address this problem. Common 93 to all proposals is how the data transport session is set up, using 94 ICE [RFC5245] in a similar manner to that of RTP [RFC3550]. The 95 proposals vary from once the session is set up; one proposal is just 96 to use a thin shim on top of UDP or DTLS to de-multiplex the packets 97 from other packets such as RTP on the same connection. Another 98 proposal is DTLS over DCCP over UDP with some appropriate congestion 99 control scheme chosen for DCCP. Lastly there has been a proposal to 100 define a data codec to carry the data in RTP. 102 Of all the solutions proposed to date there have been issues with 103 implementation maturity and availability, congestion control, high 104 overhead and NAT traversal. The solution outlined within this 105 specification proposes a lightweight, simple to implement approach 106 for RTC-Web client applications to transmit real-time non-media data. 108 4. Solution Overview 110 Each application datagram is send with a single byte header to help 111 with de-multiplexing issues. The combined datagraph and header are 112 sent either over UDP or DTLS to the receiver. The receiver sends an 113 acknowledgment for every packet it receives. The sender computes a 114 packet loss rate based upon the number of packets sent, and number of 115 acknowledgements it has received inside of given time window. The 116 browser, or other RTC-Web client application implementation, then 117 enforces a maximum bandwidth usage using the TFRC-SP[RFC4828]. 119 Practically this can be implemented with a simple lookup table such 120 as Table 1 in [RFC4828] that limits the data rate. A JavaScript 121 application running in the browser can implement more complex 122 fragmentation, reliability, and congestion control algorithms, but it 123 is the browser, or other RTC-Web client application, that is 124 responsible for enforcing the basic congestion safety with the 125 TFRC-SP algorithm. 127 5. Specification 129 When sending a datagram, a single byte with the value 62 MUST be 130 prepended to the data to be sent. The data is then sent over the UDP 131 or a DTLS flow that has been set up by ICE. The receiver MUST send 132 an acknowledgement for each packets it receives. This acknowledgment 133 is a UDP or DTLS datagram containing a single byte with the value of 134 63. The packet loss rate is computed by comparing the number of 135 packet sent to the of acknowledgements received within the past 2 136 seconds. The packet loss rate and amount of data sent is used with 137 the TFRC-SP algorithm to compute a maximum safe bandwidth. The 138 sender MUST not exceed this bandwidth. If an application requests 139 the browser, or other RTC-Web client application, to send a packet 140 that would exceed the bandwidth, the RTC-Web client application MUST 141 signal an error to the requesting application and drop the packet. 143 6. IANA Considerations 145 This document makes no request of IANA. 147 Note to RFC Editor: this section may be removed on publication as an 148 RFC. 150 7. Security Considerations 152 Because there are a number of security issues, considerations and 153 requirements for RTC-WEB client applications there is a draft that 154 specifically addresses the RTC-WEB application security 155 considerations. This draft defers it's security considerations and 156 requirements to the security considerations for RTC-Web draft 157 [I-D.ekr-security-considerations-for-rtc-web]. 159 8. Acknowledgements 161 You too can see your name here, just send us comments. 163 9. Normative References 165 [I-D.ekr-security-considerations-for-rtc-web] 166 Rescorla, E., "Security Considerations for RTC-Web", 167 May 2011. 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, March 1997. 172 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 173 Jacobson, "RTP: A Transport Protocol for Real-Time 174 Applications", STD 64, RFC 3550, July 2003. 176 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 177 (TFRC): The Small-Packet (SP) Variant", RFC 4828, 178 April 2007. 180 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 181 (ICE): A Protocol for Network Address Translator (NAT) 182 Traversal for Offer/Answer Protocols", RFC 5245, 183 April 2010. 185 Authors' Addresses 187 Cary Bran 188 Cisco 189 170 West Tasman Drive 190 San Jose, CA 95134 191 USA 193 Phone: +1 206 256-3502 194 Email: cbran@cisco.com 195 Cullen Jennings 196 Cisco 197 170 West Tasman Drive 198 San Jose, CA 95134 199 USA 201 Phone: +1 408 421-9990 202 Email: fluffy@cisco.com