idnits 2.17.1 draft-jesup-rtcweb-data-01.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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '... 7 Data streams MUST provide message ...' RFC 2119 keyword, line 144: '...ansport protocol MUST NOT encode local...' RFC 2119 keyword, line 149: '... stream protocol SHOULD support unboun...' RFC 2119 keyword, line 151: '...s image-file-transfer; or else it MUST...' RFC 2119 keyword, line 154: '...t format/encoding MUST be such that it...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5389' is defined on line 610, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-14) exists of draft-ietf-tsvwg-sctp-udp-encaps-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWeb Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Informational S. Loreto 5 Expires: May 3, 2012 Ericsson 6 M. Tuexen 7 Muenster University of Applied 8 Sciences 9 October 31, 2011 11 RTCWeb Datagram Connection 12 draft-jesup-rtcweb-data-01.txt 14 Abstract 16 This document investigates the possibilities for designing a generic 17 transport service that allows Web Browser to exchange generic data in 18 a peer to peer way. Several, already standardized by IETF, transport 19 protocols and their properties are investigated in order to identify 20 the most appropriate one. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Use cases for unreliable datagram based channel . . . . . 5 60 3.2. Use cases for reliable channels (datagram or stream). . . 5 61 4. Protocol alternatives . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Datagrams over DTLS over DCCP over UDP. . . . . . . . . . 6 63 4.2. Datagrams over SCTP over DTLS over UDP. . . . . . . . . . 7 64 4.3. A new protocol on top of UDP. . . . . . . . . . . . . . . 8 65 4.3.1. TCP over DTLS over UDP. . . . . . . . . . . . . . . . 9 66 4.4. A RTP compatible protocol. . . . . . . . . . . . . . . . . 10 67 5. Datagrams over SCTP over DTLS over UDP. . . . . . . . . . . . 11 68 5.1. User Space vs Kernel implementation. . . . . . . . . . . . 11 69 5.2. The envisioned usage of SCTP in the RTCWeb context . . . . 11 70 5.3. SCTP/DTLS/UDP vs DTLS/SCTP/UDP . . . . . . . . . . . . . . 12 71 6. Message Format. . . . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 75 10. Informational References . . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 The issue of how best to handle non-media data types in the context 81 of RTCWEB is still under discussion in the mailing list; there have 82 been several proposals on how to address this problem, but there is 83 not yet a clear consensus on the actual solution. 85 However it seems to be a general agreement that for NAT traversal 86 purpose it has to be: 88 FOO/UDP/IP 90 or most likely: 92 FOO/DTLS/UDP/IP (for confidentiality, source authenticated, integrity 93 protected transfers) 95 where FOO is a protocol that is supposed to provide congestion 96 control and possible some type of framing or stream concept. 98 Moreover there has been a clear interest for both an unreliable and a 99 reliable peer to peer datagram based channel. 101 This document provides Requirement and use cases for both unreliable 102 and reliable peer to peer datagram base channel, provide an overview 103 of the pro and cons of the different proposed solutions, and finally 104 analyze in more detail the SCTP based solution. 106 2. Requirements 108 This section lists the requirements for P2P data connections between 109 two browsers. 111 Req. 1 Multiple simultaneous datagram streams must be supported. 112 Note that there may 0 or more media streams in parallel with the 113 data streams, and the number and state (active/inactive) of the 114 media streams may change at any time. 116 Req. 2 Both reliable and unreliable datagram streams must be 117 supported. 119 Req. 3 Data streams must be congestion controlled; either 120 individually, as a class, or in conjunction with the media 121 streams, to ensure that datagram exchanges don't cause congestion 122 problems for the media streams, and that the rtcweb PeerConnection 123 as a whole is fair with competing streams such as TCP. 125 Req. 4 The application should be able to provide guidance as to the 126 relative priority of each datagram stream relative to each other, 127 and relative to the media streams. [ TBD: how this is encoded and 128 what the impact of this is. ] This will interact with the 129 congestion control. 131 Req. 5 Datagram streams must be encrypted; allowing for 132 confidentiality, integrity and source authentication. See the 133 security spec [xxx] for detailed info. 135 Req. 6 Consent and NAT traversal mechanism: These are handled by the 136 PeerConnection's ICE [RFC5245] connectivity checks and optional 137 TURN servers. 139 Req. 7 Data streams MUST provide message fragmentation support such 140 that IP-layer fragmentation does not occur no matter how large a 141 message/buffer the Javascript application passes down to the 142 Browser to be sent out. 144 Rec. 8 The data stream transport protocol MUST NOT encode local IP 145 addresses inside its protocol fields; doing so reveals potentially 146 private information, and leads to failure if the address is 147 depended upon. 149 Req. 9 The data stream protocol SHOULD support unbounded-length 150 "messages" (i.e., a virtual socket stream) at the application 151 layer, for such things as image-file-transfer; or else it MUST 152 support at least a maximum application-layer message size of 4GB. 154 Req. 10 The data stream packet format/encoding MUST be such that it 155 is impossible for a malicious Javascript to generate an 156 application message crafted such that it could be interpreted as a 157 native protocol over UDP - such as UPnP, RTP, SNMP, STUN, etc. 159 Req. 10 The data stream transport protocol MUST start with the 160 assumption of a PMTU of 1280 [ *** need justification ***] bytes 161 until measured otherwise. 163 Req. 11 The data stream transport protocol MUST NOT rely on ICMP 164 being generated or being passed back, such as for PMTU discovery. 166 3. Use cases. 168 3.1. Use cases for unreliable datagram based channel 170 U-C 1 A real-time game where position and object state information 171 is sent via one or more unreliable data channels. Note that at 172 any time there may be no media channels, or all media channels may 173 be inactive. 175 U-C 2 Non-critical state updates about a user in a video chat or 176 conference, such as Mute state. 178 3.2. Use cases for reliable channels (datagram or stream). 180 Note that either reliable datagrams or streams are possible; reliable 181 streams would be fairly simple to layer on top of SCTP reliable 182 datagrams with in-order delivery. 184 U-C 3 A real-time game where critical state information needs to be 185 transferred, such as control information. Typically this would be 186 datagrams. Such a game may have no media channels, or they may be 187 inactive at any given time, or may only be added due to in-game 188 actions. 190 U-C 4 Non-realtime file transfers between people chatting. This 191 could be datagrams or streaming; streaming might be an easier fit 193 U-C 5 Realtime text chat while talking with an individual or with 194 multiple people in a conference. Typically this would be 195 datagrams. 197 U-C 6 Renegotiation of the set of media streams in the 198 PeerConnection. Typically this would be datagrams 200 4. Protocol alternatives 201 4.1. Datagrams over DTLS over DCCP over UDP. 203 +------+ 204 |WEBAPP| 205 +------+ 206 | DTLS | 207 +-------------+ 208 | STUN | DCCP | 209 +-------------+ 210 | ICE | 211 +-------------+ 212 | UDP1 | UDP2 |... 213 +-------------+ 215 Figure 1: stack diagram 217 DCCP [RFC4340] adds to a UDP-like foundation the minimum mechanisms 218 necessary to support congestion control. It is a unicast, 219 connection-oriented protocol with bidirectional data flow. 221 The main downside of DCCP is the uncertainty of the DCCP 222 implementations. Moreover DCCP only meets the requirements for the 223 unreliable data channel, so in order to satisfy the reliable data 224 channel requirements there is a need to build a new mechanism on top 225 of DCCP or use a different protocol for it. 227 The main advantage of DCCP is that the Congestion Control (CC) 228 methods are modularly separated from its core, that allows each 229 application to choose a different congestion control methods it 230 prefers. Each congestion control method is denoted by unique ID 231 (CCID): a number from 0-255. CCIDs 2, 3 and 4 are current defined; 232 CCIDs 0, 1, and 5-255 are reserved. The end-points negotiate their 233 CCIDs during connection initiation and achieve agreement through the 234 exchange of feature negotiation options in DCCP headers. 236 CCID 2 [RFC4341] denotes Additive Increase, Multiplicative Decrease 237 congestion control with feature modelled directly on TCP. It 238 achieves the maximum bandwidth over the long term consistent with the 239 use of end-to-end congestion control but reduces the congestion 240 window by half upon congestion detection. Applications that prefer a 241 large amount of bandwidth as feasible over the longer terms should 242 use CCID2. 244 CCID 3 [RFC4342], TCP friendly rate control mechanism(TFRC), denotes 245 an equation-based and rate controlled congestion control mechanisms 246 designed to be reasonably fair when competing for bandwidth with TCP 247 like flows. It shows much lower variation of throughput over time 248 compared with TCP that makes CCID 3 more suitable than CCID 2 for 249 applications such as streaming media content that prefers to minimize 250 abrupt changes in the sending rate. 252 CCID 4 [RFC5622] is a modified version of CCID 3 and designed for 253 applications that use a small fixed segment size, or change their 254 sending rate by varying the segment size. It denotes TFRC-SP (TCP 255 friendly rate control for small packets) 257 Both CCID 3 and 4 uses the TCP throughput equation for CC; the former 258 is based on the calculation of loss event rate but the later also 259 include nominal packet size of 1460 bytes, a round trip estimate in 260 TCP throughput calculation. In contrast to CCID 3, the CCID 4 sender 261 imposes a minimum interval of 10 ms between data packets regardless 262 of the allowed transmit rate. 264 4.2. Datagrams over SCTP over DTLS over UDP. 266 +------+ 267 |WEBAPP| 268 +------+ 269 | SCTP | 270 +-------------+ 271 | STUN | DTLS | 272 +-------------+ 273 | ICE | 274 +-------------+ 275 | UDP1 | UDP2 |... 276 +-------------+ 278 Figure 2: stack diagram 280 An SCTP [RFC4960] based solution will provide several interesting 281 features among the others: Multistreaming, Ordered and Unordered 282 delivery, Reliability and partial-Reliability [RFC3758], and Dynamic 283 Address Reconfiguration [RFC5061]. 285 Moreover SCTP provides the possibility to transport different 286 "protocols" over multiple streams and associations using the ppid 287 (Payload Protocol Identifier). An application can set a different 288 PPID with each send call. This allows the receiving application to 289 look at this information (as well as the stream id/seq) on receiving 290 to know what type of protocol the data payload has. 292 The SCTP feature so seems to satisfy all the requirements for both 293 the unreliable and the reliable scenario. 295 There are SCTP implementations for all the different OS: Linux 296 (mainline kernel 2.6.36), FreeBSD (release kernel 8.2), Mac OS X, 297 Windows (SctpDrv4) and Solaris (OpenSolaris 2009.06), as well as a 298 user-land SCTP implementation based on the FreeBSD implementation). 300 The SCTP solution is analyzed in more detail in Section 5. 302 4.3. A new protocol on top of UDP. 304 This option requires to at least build a congestion control (CC) 305 mechanism on top of the plain UDP. 307 In designing it we have to follow carefully the guidelines provided 308 in [RFC5405]. 310 +------+ 311 |WEBAPP| 312 +------+ 313 | CC | 314 +-------------+ 315 | STUN | DTLS | 316 +-------------+ 317 | ICE | 318 +-------------+ 319 | UDP1 | UDP2 |... 320 +-------------+ 322 Figure 3: stack diagram UDP 324 4.3.1. TCP over DTLS over UDP. 326 +------+ 327 |WEBAPP| 328 +------+ 329 |FRAME | 330 +------+ 331 | TCP | 332 +-------------+ 333 | STUN | DTLS | 334 +-------------+ 335 | ICE | 336 +-------------+ 337 | UDP1 | UDP2 |... 338 +-------------+ 340 Figure 4: stack diagram 342 Layering TCP atop DTLS or UDP is an approach that has been suggested 343 several times in the past, including TCP-over-UDP 344 [I-D.baset-tsvwg-tcp-over-udp] and UDP-Encapsulated Transport 345 Protocols [I-D.denis-udp-transport]. 347 A similar mechanism has also been used for Google Talk's peer-to-peer 348 file transfer protocol, implemented in the libjingle library as 349 "PseudoTcp" [http://code.google.com/p/libjingle/source/browse/trunk/ 350 talk/p2p/base/pseudotcp.cc]. In this implementation, a lightweight 351 userspace TCP stack has been developed with support for a fairly 352 minimal set of TCP options, namely delayed acknowledgements, Nagle, 353 fast retransmit, fast recovery (NewReno), timestamps, and window 354 scaling. Some features have been removed, such as urgent data. And 355 as in the aforementioned drafts, the TCP header has been tweaked 356 slightly to remove fields redundant with the UDP header, namely 357 source/destination port and checksum. 359 The advantage of this approach is clear; TCP is well-known and 360 understood, and its congestion control is by definition TCP-fair. 361 User-space implementations of TCP exist, e.g. as PseudoTcp, which has 362 considerable deployment experience. It is also possible to support 363 multiplexing of datagram flows with this approach, either by adding a 364 stream identifier to the TCP header (in place of the port numbers, 365 perhaps), or doing the same in a higher-level framing layer. 367 This approach has some disadvantages as well; since TCP is a stream, 368 rather than datagram-oriented protocol, some framing needs to be 369 added on top of TCP to provide the necessary datagram interface to 370 the calling API. In addition, TCP only provides reliable delivery; 371 there is no provision for a unreliable channel. This deficiency 372 could be remedied by providing a separate protocol for unreliable 373 channels. 375 Such a protocol could be a lightweight datagram protocol that 376 implements the sequence number and other fields necessary to run 377 TFRC-SP. 379 4.4. A RTP compatible protocol. 381 +------+ 382 |WEBAPP| 383 +----------------+ 384 |STUN|DTLS| SRTP | 385 +----------------+ 386 | ICE | 387 +----------------+ 388 | UDP1 | UDP2 |... 389 +----------------+ 391 Figure 5: stack diagram 393 When sending RTP with DTLS, rather than encapsulating RTP in DTLS, 394 SRTP keys are extracted from the DTLS key material, allowing use of 395 SRTP's more efficient format. This same approach could be extended 396 for sending of application data as a RTP payload. 398 The benefits of this approach are centered around the ability to 399 reuse the existing mechanisms for audio/video data for application 400 data, and the resultant simplification that occurs. If everything 401 ends up RTP, and RTP provides information about loss and timing, we 402 can have common encryption, congestion control, and multiplexing 403 mechanisms for all types of data. For example, we could use RTP SSRC 404 to demux different application data streams, and RTCP NACK to 405 faciliate reliable delivery. 407 On the other hand, RTP has a number of semantics associated with it 408 that aren't necessarily a good fit for arbitrary application data. 409 While the RTP timestamp, sequence number and SSRC fields are 410 meaningful, there are a number of other header fields that may not 411 make sense, and the applicability of RTP's notions of timing, media 412 playout, and control feedback is unclear. 414 5. Datagrams over SCTP over DTLS over UDP. 416 5.1. User Space vs Kernel implementation. 418 Even kernel implementation of SCTP are already available for all the 419 different platforms (see Section 4.2 ), there are compelling reasons 420 that incline towards for a SCTP stack that works well in user land. 422 The main reason is deployability. 424 There are many applications today that are expected to run on a wide 425 range of old and new operating systems. Web browsers are an 426 excellent example. They support operating systems 10 years old or 427 more, they run on mobile and desktop operating systems, and they are 428 highly portable to new operating systems. This is achieved by having 429 a fairly narrow portability layer to minimize what needs to be 430 supported on old operating systems and ported to new ones. This 431 creates a strong desire to implemented as much functionality as 432 possible inside the application instead of relying on the operating 433 system for it. 435 This leads to a situation where there is a desire for the SCTP stack 436 to be implemented in the user space instead of the kernel space. For 437 many applications that require support of operating systems without 438 SCTP (insert whatever stack order is - UDP, DTLS - whatever), there 439 is no way to deploy this unless it can be implemented in the 440 application. The traditional reasons for kernel implementations, 441 such as mux of many application using transport port numbers, does 442 not particularly apply here where that level of multiplexing between 443 application was provided by the underling UDP that is tunneled over. 444 The requirement is: 446 It MUST be possible to implement the SCTP and DTLS portion of the 447 stack in the user application space. 449 5.2. The envisioned usage of SCTP in the RTCWeb context 451 The appealing features of SCTP in the RTCWeb context are: 453 - the congestion control which is TCP friendly. 454 - the congestion control is modifiable for integration with media 455 stream congestion control. 456 - support for multiple channels with different characteristics. 457 - support for out-of-order delivery. 459 - support for large datagrams and PMTU-discovery and fragmentation. 460 - the reliable or partial reliability support. 462 Multi streaming is probably also of interest. 464 Multihoming will not be used in this scenario. The SCTP layer would 465 simply act as if it were running on a single-homed host, since that 466 is the abstraction that the lower layers (e.g. UDP) would expose. 468 5.3. SCTP/DTLS/UDP vs DTLS/SCTP/UDP 470 The two alternatives being discussed in this subsection are shown in 471 the following Figure 6. 473 +------+ +------+ 474 |WEBAPP| |WEBAPP| 475 +------+ +------+ 476 | DTLS | | SCTP | 477 +-------------+ +-------------+ 478 | SRTP | SCTP | | SRTP | DTLS | 479 +-------------+ +-------------+ 480 | ICE | | ICE | 481 +-------------+ +-------------+ 482 | UDP1 | UDP2 |... | UDP1 | UDP2 |... 483 +-------------+ +-------------+ 485 Figure 6: Two variants of SCTP and DTLS usage 487 The UDP encapsulation of SCTP used in the protocol stack shown on the 488 left hand side of Figure 6 is specified in 489 [I-D.ietf-tsvwg-sctp-udp-encaps] and the usage of DTLS over SCTP is 490 specified in [RFC6083]. Using the UDP encapsulation of SCTP allows 491 SCTP implementations to run in user-land without any special 492 privileges, but still allows the support of SCTP kernel 493 implementations. This also requires no SCTP specific support in 494 middleboxes like firewalls and NATs. Multihoming and failover 495 support is implemented via the ICE layer, and SCTP associations are 496 single-homed at the SRTP layer. The SCTP payload is protected by 497 DTLS, which provides confidentiality, integrity and source 498 authentication. SCTP-AUTH as specified in [RFC4895] is used to 499 provide integrity of SCTP control information related to the user 500 messages like the SCTP stream identifier. Please note that the SCTP 501 control information (like the SCTP stream identifier) is sent 502 unencrypted. 504 Considering the protocol stack on the right hand side of Figure 6, 505 the usage of DTLS over UDP is specified in 507 [I-D.ietf-tls-rfc4347-bis]. Using SCTP on top of DTLS is currently 508 unspecified. Since DTLS is typically implemented in user-land, an 509 SCTP user-land implementation has also to be used. Kernel SCTP 510 implementations can't be used. When using DTLS as the lower layer, 511 only single homed SCTP associations can be used, since DTLS does not 512 expose any any address management to its upper layer. DTLS 513 implementations used for this stack must support controlling fields 514 of the IP layer like the DF-bit in case of IPv4 and the DSCP field. 515 This is required for performing path MTU discovery. The DTLS 516 implementation must also support sending user messages exceeding the 517 path MTU. When supporting multiple SCTP associations over a single 518 DTLS connection, incoming ICMP or ICMPv6 messages can't be processed 519 by the SCTP layer, since there is no way to identify the 520 corresponding association. Therefore the number of SCTP associations 521 should be limited to one or ICMP and ICMPv6 messages should be 522 ignored. In general, the lower layer interface of an SCTP 523 implementation has to be adopted to address the differences between 524 IPv4 or IPv6 (being connection-less) or DTLS (being connection- 525 oriented). When this stack is used, DTLS protects the complete SCTP 526 packet, so it provides confidentiality, integrity and source 527 authentication of the complete SCTP packet. 529 It should be noted that both stack alternatives support the usage of 530 multiple SCTP streams. A user message can be sent ordered or 531 unordered and, if the SCTP implementations support [RFC3758], with 532 partial reliability. When using partial reliability, it might make 533 sense to use a policy limiting the number of retransmissions. 534 Limiting the number of retransmissions to zero provides a UDP like 535 service where each user messages is sent exactly once. 537 SCTP provides congestion control on a per-association base. This 538 means that all SCTP streams within a single SCTP association share 539 the same congestion window. Traffic not being sent over SCTP is not 540 covered by the SCTP congestion control. 542 6. Message Format. 544 TBD if we need also to design a framing or not. 546 At time of writing nobody has identified a real need for masking of 547 UDP, and DTLS is a much-preferred solution for encryption/ 548 authentication. 550 More SCTP already provides sequence number information (e.g. stream 551 sequence numbers). However there could be a need to support 552 different kind of message (link in WebSocket where there is support 553 to distinguish between Unicode text and binary frames), since for 554 SCTP they are all user message. In the case there is this need a 555 possibility is to map types to streams. 557 7. Security Considerations 559 To be done. 561 8. IANA Considerations 563 This document does not require any actions by the IANA. 565 9. Acknowledgments 567 Many thanks for comments, ideas, and text from Cullen Jennings, Eric 568 Rescorla, Randall Stewart and Justin Uberti. 570 10. Informational References 572 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 573 Conrad, "Stream Control Transmission Protocol (SCTP) 574 Partial Reliability Extension", RFC 3758, May 2004. 576 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 577 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 579 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 580 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 581 Congestion Control", RFC 4341, March 2006. 583 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 584 Datagram Congestion Control Protocol (DCCP) Congestion 585 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 586 March 2006. 588 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 589 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 590 Control for Small Packets (TFRC-SP)", RFC 5622, 591 August 2009. 593 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 594 "Authenticated Chunks for the Stream Control Transmission 595 Protocol (SCTP)", RFC 4895, August 2007. 597 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 598 RFC 4960, September 2007. 600 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 601 Kozuka, "Stream Control Transmission Protocol (SCTP) 602 Dynamic Address Reconfiguration", RFC 5061, 603 September 2007. 605 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 606 (ICE): A Protocol for Network Address Translator (NAT) 607 Traversal for Offer/Answer Protocols", RFC 5245, 608 April 2010. 610 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 611 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 612 October 2008. 614 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 615 for Application Designers", BCP 145, RFC 5405, 616 November 2008. 618 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 619 Transport Layer Security (DTLS) for Stream Control 620 Transmission Protocol (SCTP)", RFC 6083, January 2011. 622 [I-D.ietf-tls-rfc4347-bis] 623 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 624 Security version 1.2", draft-ietf-tls-rfc4347-bis-06 (work 625 in progress), July 2011. 627 [I-D.ietf-tsvwg-sctp-udp-encaps] 628 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 629 Packets", draft-ietf-tsvwg-sctp-udp-encaps-01 (work in 630 progress), October 2011. 632 [I-D.baset-tsvwg-tcp-over-udp] 633 Baset, S. and H. Schulzrinne, "TCP-over-UDP", 634 draft-baset-tsvwg-tcp-over-udp-01 (work in progress), 635 June 2009. 637 [I-D.denis-udp-transport] 638 Denis-Courmont, R., "UDP-Encapsulated Transport 639 Protocols", draft-denis-udp-transport-00 (work in 640 progress), July 2008. 642 Authors' Addresses 644 Randell Jesup 645 Mozilla 647 Email: randell-ietf@jesup.org 649 Salvatore Loreto 650 Ericsson 651 Hirsalantie 11 652 Jorvas 02420 653 Finland 655 Email: salvatore.loreto@ericsson.com 657 Michael Tuexen 658 Muenster University of Applied Sciences 659 Stegerwaldstrasse 39 660 Steinfurt 48565 661 Germany 663 Email: tuexen@fh-muenster.de