idnits 2.17.1 draft-thomson-rtcweb-data-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 18, 2013) is 4056 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: 'RFC4566' is defined on line 360, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-05 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB M. Thomson 3 Internet-Draft Microsoft 4 Intended status: Standards Track February 18, 2013 5 Expires: August 22, 2013 7 Data Channels for RTCWEB 8 draft-thomson-rtcweb-data-00 10 Abstract 12 RTCWEB have selected SCTP over DTLS over UDP with ICE for peer-to- 13 peer data channels. There is some debate over the best way to 14 negotiate channels. This proposal is a nose-to-tail description of 15 an alternative to existing proposals. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 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 August 22, 2013. 34 Copyright Notice 36 Copyright (c) 2013 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3 54 3. (In)consistent Properties . . . . . . . . . . . . . . . . . . . 5 55 3.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Dealing with Mismatched Properties . . . . . . . . . . . . 5 57 4. Available Data Channel Properties . . . . . . . . . . . . . . . 6 58 5. SDP Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Payload Protocol Identifiers . . . . . . . . . . . . . . . . . 8 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 RTCWEB [I-D.ietf-rtcweb-overview] has defined the use of the Stream 71 Control Transmission Protocol (SCTP) [RFC4960] over Datagram 72 Transport Layer Security (DTLS) [RFC6347] over UDP with Interactive 73 Connectivity Establishment (ICE) [RFC5245] for peer-to-peer data 74 channels. 76 This document describes a proposal for how this protocol stack is 77 used. The proposal attempts to reconcile the following basic 78 requirements: 80 o the ability to have data channels used interchangeably with 81 websockets, after establishment 83 o the ability to use as many SCTP features as possible 85 Like other proposals, this proposal uses an API that is largely 86 interchangeable with the WebSockets API [REF:TBD]. Of course, that 87 alone is insufficient because the way that data channels are created 88 is completely different to websockets [RFC6455]. Only the general 89 usage of the API follows the WebSockets API, channel establishment 90 requires a very different process. 92 Furthermore, not every application will care for compatibility with 93 the WebSockets API. For those applications, additional properties 94 are exposed to enable valuable SCTP features. 96 In these aspects, all data channel proposals are the same. The 97 details differ. For example, this one doesn't need an in-band 98 protocol. It even avoids the need for negotiation, except where it 99 is needed. If not for the fact that the WebSockets API designers - 100 in their infinite wisdom - decided to distinguish text from binary, 101 it wouldn't even need to use a PPID to identify textual messages. 103 1.1. Terminology 105 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 106 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 107 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 108 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 109 levels for compliant implementations. 111 2. Overview of Operation 113 A data channel is a bidirectional communication medium between WebRTC 114 peers. 116 Every data channel is bound to a specific SCTP stream number. The 117 same SCTP stream identifier is used for both directions of the data 118 channel. Though SCTP streams are unidirectional, and this concept 119 doesn't hold any particular meaning for SCTP, this simplification 120 ensures that channels can be created with minimal overhead. 122 Each data channel has a set of properties that governs how it sends 123 messages. Unlike other SCTP APIs where properties like reliability 124 settings are set on a per-message basis, this API places these 125 properties on the data channel. This allows the API to behave 126 exactly like the WebSockets API when sending messages. Details of 127 the available data channel properties are included in Section 4. 129 There are three ways that a data channel can be created. All three 130 result in an object representing the data channel being provided to 131 the application. Each differs in the manner of delivery and how 132 properties are selected for the data channel. 134 1. The application can request the creation of a new data channel 135 directly. The browser selects appropriate properties for the 136 channel, using any values provided by the application and 137 providing defaults for others. 139 This triggers a notification to the application that indicates 140 that it needs to renegotiate the session. 142 2. Offer/answer negotiation can trigger the creation of a new data 143 channel. In this case, the session description provided in an 144 offer or answer describes the properties of the channel. 146 3. Messages can arrive on an SCTP stream that does not have a data 147 channel allocated. If messages arrive on a stream, the browser 148 provides default values for all stream properties. 150 Channel creation can fail if there are an insufficient number of 151 available SCTP streams. This is based on either a local 152 unwillingness to receive more streams, or based on knowledge of the 153 unwillingness of the peer to receive more streams. 155 Creation can also fail if the application specifies a stream ID that 156 is already in use. These should trigger the appropriate error 157 mechanisms (exceptions or something). 159 Channels are closed by sending a RE-CONFIG chunk that includes 160 Incoming and Outgoing SSN Reset Request parameters, as defined in 161 [RFC6525]. Closing a channel doesn't permit the sending of a code 162 and message as exposed in the WebSockets API, any values that are 163 provided by the application are discarded. 165 3. (In)consistent Properties 167 The creation of the first data channel will require offer/answer 168 negotiation. This is necessary to ensure that the SCTP association 169 is created, including ICE, the DTLS handshake, plus any 170 authentication that might be required. 172 Once an SCTP association is live, data channels can be used to 173 exchange messages immediately after they are created. The drawback 174 is that messages arrive at the peer without any information about 175 what properties the sender attaches to the corresponding data 176 channel. 178 How much property consistency matters to the application will depend 179 on the application. If the application is performing SS7 signaling 180 using M3UA [RFC4666], this is unlikely to matter, but some 181 applications could rely on having consistent data channel properties. 183 3.1. Negotiation 185 The safest (and slowest) way to establish new channels with 186 consistent properties is to negotiate them. This is performed using 187 an offer/answer exchange. The application is able to choose where 188 and when this negotiation occurs. If there is an existing data 189 channel, then this provides a low latency path for performing this 190 negotiation. 192 The negotiation includes a description for every SCTP stream that a 193 peer is sending that includes all of the data channel properties (see 194 Section 4), so that the receiver can create a data channel with the 195 same properties. The browser creates a data channel with the 196 described properties and provides that to the application. If the 197 data channel description appears in an offer, the answer describes 198 the data channel that is used on the same stream number. 200 An offer or answer that includes a description for a data channel 201 that already exists, then the properties of that data channel are not 202 modified. An answer MUST include the properties of the existent data 203 channel, not the channel that the offer describes. 205 3.2. Dealing with Mismatched Properties 207 An application that chooses to send on data channels prior to 208 negotiation will cause the receiving peer to create a data channel 209 with a default configuration. Applications can handle this in a 210 number of ways: 212 o The application on the receiving peer can create data channels in 213 the same order as the sender to ensure consistent properties. 214 This is possible because stream identifiers are assigned in the 215 same way by both peers. 217 o The application on the receiving peer might apply application- 218 specific default values for all non-negotiated channels. 220 o The application on the receiving peer might not care about having 221 consistent data channel properties. Note that data channel 222 properties only apply to the sending of messages. 224 Note: It is possible to provide an application with information about 225 the values that are in use by a peer. This would in most cases be 226 possible after negotiation, though some properties are revealed when 227 new messages arrive. Of course, this is a lot of effort after the 228 application has already effectively declared that it doesn't care. 229 Given that the application could exchange this information using the 230 data channel(s) it has convenient, adding new APIs seem of very low 231 value. 233 [[Irrelevant API Note: Adding a data channel triggers a notification 234 to the application that it should renegotiate the session. Normally, 235 the 'negotiation needed' state is cleared when the negotiation 236 commences (or completes?). If the application decides to send 237 packets, then the damage is done and there is no point negotiating. 238 That being the case, a data channel could removed from the set of 239 unnegotiated things upon sending a packet. Negotiation from this 240 point isn't going to change anything.]] 242 4. Available Data Channel Properties 244 The following properties are exposed to the application. All of 245 these properties can be set during the creation of a data channel. 246 Once the channel object is created, these properties are mutable, 247 with the exception of "streamId". 249 streamId The SCTP stream ID to use for the channel. If not provided 250 by the application, the lowest valued stream ID that is not 251 already in use by a data channel is selected. If the channel is 252 created as a result of negotiation or packet arrival, the stream 253 ID has already been chosen. 255 binaryPPID The SCTP payload protocol identifier (PPID) that is used 256 for binary messages. Textual messages are always sent using a 257 PPID that indicates textual content, so this value only determines 258 the PPID that is attached to binary messages. This field is a 32- 259 bit number. 261 Unless otherwise specified, channels use the PPID for WebRTC 262 binary data channels. Channels created in response to the receipt 263 of a message use the PPID from the received message, unless the 264 message uses the PPID for WebRTC textual data channels, which 265 causes the binary PPID to be selected instead. Details on the 266 newly defined PPIDs are included in Section 6. 268 reliabilityTime The amount of time (in milliseconds) that the 269 browser will attempt to retransmit messages for reliable delivery. 270 Together with reliabilityRetransmissions, this enables unreliable 271 or partially reliable transmission of data. The default value for 272 this property is the largest number available (e.g., 273 Number.POSITIVE_INFINITY). 275 reliabilityRetransmissions The numer of retransmissions that the 276 browser will make for any packet reliable delivery. Together with 277 reliabilityTime, this enables unreliable or partially reliable 278 transmission of data. The default value for this property is the 279 largest number available (e.g., Number.POSITIVE_INFINITY). 281 label The label to assign to the data channel. A default value is 282 selected by the receiving browser. 284 protocol A protocol label that identifies the protocol used on the 285 data channel. This property is undefined unless set by the 286 application. 288 binaryType The BinaryType defined in The WebSockets API determines 289 whether binary data is provided to the application as Blob or 290 ArrayBuffer objects. The default value is "blob". Note that 291 changing this might not have an immediate effect if messages have 292 started to arrive prior to the change. 294 All these properties are specific to each message that is sent. 295 Changes to mutable properties take effect for the next message that 296 is sent on the channel. 298 This isn't a W3C WebRTC document, so specifics of the API aren't 299 really relevant, but it is imagined that these properties could be 300 passed in a dictionary to the method that creates a new data channel 301 and exposed as attributes on the data channel object. 303 5. SDP Format 305 The properties described above appear in SDP. All properties are 306 declarative. Though the specifics of the syntax doesn't matter much, 307 the following example could indicate something that would work: 309 m=application 12345 SCTP/DTLS 0 1 2 5 310 c=IN IP6 ::1 311 a=fmtp:0 binaryPPID=177;label=control 312 a=fmtp:1 label=chat 313 a=fmtp:2 label=characters;reliabilityTime=2000;protocol=lrudfb 314 a=fmtp:5 label=bullets;reliabilityTime=5000 316 [[Formal SDP grammar TBD]] 318 This assumes that the SCTP port number (inside the DTLS 319 encapsulation) is fixed, so that this doesn't need to be indicated 320 anywhere. I'm not sure whether asking IANA for a port allocation 321 makes sense though. 323 6. Payload Protocol Identifiers 325 Two SCTP payload protocol identifiers are defined for WebRTC data 326 channels. 328 The WebRTC textual data channel PPID (number TBD) is used for all 329 messages that are identified as being textual. The payload of 330 messages marked with this PPID MUST be UTF-8 encoded text. 332 The WebRTC binary data channel PPID (number TBD) is used as the 333 default PPID for new data channels. 335 7. IANA Considerations 337 This document probably should register the PPIDs, but I don't really 338 have time to do that right now. 340 8. Security Considerations 342 I thought about this, and I can't think of any specific security 343 considerations. I could blather on about willingness to accept 344 streams and large volumes of data, but that's pretty lame. 346 I'm sure something will turn up eventually. 348 9. Acknowledgments 350 This document is a rush job. If it survives for any longer than a 351 couple of weeks, no doubt this section will come in handy. 353 10. References 355 10.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 361 Description Protocol", RFC 4566, July 2006. 363 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 364 RFC 4960, September 2007. 366 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 367 Transmission Protocol (SCTP) Stream Reconfiguration", 368 RFC 6525, February 2012. 370 10.2. Informative References 372 [I-D.ietf-rtcweb-overview] 373 Alvestrand, H., "Overview: Real Time Protocols for Brower- 374 based Applications", draft-ietf-rtcweb-overview-05 (work 375 in progress), December 2012. 377 [RFC4666] Morneault, K. and J. Pastor-Balbas, "Signaling System 7 378 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation 379 Layer (M3UA)", RFC 4666, September 2006. 381 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 382 (ICE): A Protocol for Network Address Translator (NAT) 383 Traversal for Offer/Answer Protocols", RFC 5245, 384 April 2010. 386 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 387 Security Version 1.2", RFC 6347, January 2012. 389 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 390 RFC 6455, December 2011. 392 Author's Address 394 Martin Thomson 395 Microsoft 396 3210 Porter Drive 397 Palo Alto, CA 94304 398 US 400 Phone: +1 650-353-1925 401 Email: martin.thomson@skype.net