RTCWeb Datagram Connection
draft-jesup-rtcweb-data-00.txt

Abstract

This document investigates the possibilities for designing a generic transport service that allows Web Browser to exchange generic data in a peer to peer way. Different transport protocols and their properties are investigated in order to identify the most appropriate one.

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 April 27, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

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
• 2. Requirements
• 3. Use cases.
• 3.1. Use cases for unreliable datagram based channel
• 3.2. Use cases for reliable channels (datagram or stream).
• 4. Protocol alternatives
• 4.1. Datagrams over DTLS over DCCP over UDP.
• 4.2. Datagrams over SCTP over DTLS over UDP.
• 4.3. A new protocol on top of UDP.
• 4.4. A RTP compatible protocol.
• 5. Datagrams over SCTP over DTLS over UDP.
• 5.1. User Space vs Kernel implementation.
• 5.2. The envisioned usage of SCTP in the RTCWeb context
• 5.3. SCTP/DTLS/UDP vs DTLS/SCTP/UDP
• 6. Message Format.
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgments
• 10. References
• Authors' Addresses

1. Introduction

The issue of how best to handle non-media data types in the context of RTCWEB is still under discussion in the mailing list; there have been several proposal on how to address this problem, but there is not yet a clear consensus on the actual solution.

However it seems to be a general agreement that for NAT traversal purpose it has to be:

FOO/UDP/IP

or most likely:

FOO/DTLS/UDP/IP (for confidentiality, source authenticated, integrity protected transfers)

where FOO is a protocol that is supposed to provide congestion control and possible some type of framing or stream concept.

Moreover there has been a clear interest for both an unreliable and a reliable peer to peer datagram based channel.

This document provides Requirement and use cases for both unreliable and reliable peer to peer datagram base channel, provide an overview of the pro and cons of the different proposed solutions, and finally analyze in more detail the SCTP based solution.

2. Requirements

This section lists the requirements for P2P data connections between two browsers.

Req. 1

Multiple simultaneous datagram streams must be supported. Note that there may 0 or more media streams in parallel with the data streams, and the number and state (active/inactive) of the media streams may change at any time.

Req. 2

Both reliable and unreliable datagram streams must be supported.

Req. 3

Data streams must be congestion controlled; either individually, as a class, or in conjunction with the media streams, to ensure that datagram exchanges don't cause congestion problems for the media streams, and that the rtcweb PeerConnection as a whole is fair with competing streams such as TCP.

Req. 4

The application should be able to provide guidance as to the relative priority of each datagram stream relative to each other, and relative to the media streams. [ TBD: how this is encoded and what the impact of this is. ] This will interact with the congestion control.

Req. 5

Datagram streams must be encrypted; allowing for confidentiality, integrity and source authentication. See the security spec [xxx] for detailed info.

Req. 6

Consent and NAT traversal mechanism: These are handled by the PeerConnection's ICE [RFC5245] connectivity checks and optional TURN servers.

3. Use cases.

3.1. Use cases for unreliable datagram based channel

U-C 1

A real-time game where position and object state information is sent via one or more unreliable data channels. Note that at any time there may be no media channels, or all media channels may be inactive.

U-C 2

Non-critical state updates about a user in a video chat or conference, such as Mute state.

3.2. Use cases for reliable channels (datagram or stream).

Note that either reliable datagrams or streams are possible; reliable streams would be fairly simple to layer on top of SCTP reliable datagrams with in-order delivery.

U-C 3

A real-time game where critical state information needs to be transferred, such as control information. Typically this would be datagrams.

U-C 4

Non-realtime file transfers between people chatting. This could be datagrams or streaming; streaming might be an easier fit

U-C 5

Realtime text chat while talking with multiple people in a conference. Typically this would be datagrams.

U-C 6

Renegotiation of the set of media streams in the PeerConnection. Typically this would be datagrams

4. Protocol alternatives

4.1. Datagrams over DTLS over DCCP over UDP.

    
                 +------+
                 |WEBAPP|
                 +------+
                 | DTLS |
          +-------------+
          | STUN | DCCP |
          +-------------+
          |    UDP      |
          +-------------+              
    
        

DCCP [RFC4340] adds to a UDP-like foundation the minimum mechanisms necessary to support congestion control. It is a unicast, connection-oriented protocol with bidirectional data flow.

The main downside of DCCP is the uncertainty of the DCCP implementations. Moreover DCCP only meets the requirements for the unreliable data channel, so in order to satisfy the reliable data channel requirements there is a need to build a new mechanism on top of DCCP or use a different protocol for it.

The main advantage of DCCP is that the Congestion Control (CC) methods are modularly separated from its core, that allows each application to choose a method it prefers.

4.2. Datagrams over SCTP over DTLS over UDP.

    
                 +------+
                 |WEBAPP|
                 +------+
                 | SCTP |
          +-------------+
          | STUN | DTLS |
          +-------------+
          |    UDP      |
          +-------------+              
    
        

An SCTP [RFC4960] based solution will provide several interesting features among the others: Multistreaming, Ordered and Unordered delivery, Reliability and partial-Reliability [RFC3758], and Dynamic Address Reconfiguration [RFC5061]. The SCTP feature so seems to satisfy all the requirements for both the unreliable and the reliable scenario.

TBD: any downside for SCTP???

There are SCTP implementations for all the different OS: Linux (mainline kernel 2.6.36), FreeBSD (release kernel 8.2), Mac OS X, Windows (SctpDrv4) and Solaris (OpenSolaris 2009.06), as well as a user-land SCTP implementation based on the FreeBSD implementation).

The SCTP solution is analyzed in more detail in Section 5.

4.3. A new protocol on top of UDP.

This option requires to at least build a congestion control (CC) mechanism on top of the plain UDP.

In designing it we have to follow carefully the guidelines provided in [RFC5405].

    
                 +------+
                 |WEBAPP|
                 +------+
                 |  CC  |
          +-------------+
          | STUN | DTLS |
          +-------------+
          |    UDP      |
          +-------------+              
    
        

TBD: describe here the proposal to implement in the userspace TCP/DTLS/UDP for reliable data channels, and UDP-with-TFRC/DTLS/UDP for unreliable data channels (e.g. libjingle).

4.4. A RTP compatible protocol.

TBD

5. Datagrams over SCTP over DTLS over UDP.

5.1. User Space vs Kernel implementation.

Even kernel implementation of SCTP are already available for all the different platforms (see Section 4.2 ), there are compelling reasons that incline towards for a SCTP stack that works well in user land.

The main reason is deployability.

TBD..

5.2. The envisioned usage of SCTP in the RTCWeb context

The appealing features of SCTP in the RTCWeb context are:

-

the congestion control which is TCP friendly.

-

the congestion control is modifiable for integration with media stream congestion control.

-

support for multiple channels with different characteristics.

-

support for out-of-order delivery.

-

support for large datagrams and PMTU-discovery and fragmentation.

-

the reliable or partial reliability support.

Multi streaming is probably also of interest.

Multihoming will not be used in this scenario. The SCTP layer would simply act as if it were running on a single-homed host, since that is the abstraction that the lower layers (e.g. UDP) would expose.

5.3. SCTP/DTLS/UDP vs DTLS/SCTP/UDP

The two alternatives being discussed in this subsection are shown in the following Figure 4.

                    +------+                    +------+
                    |WEBAPP|                    |WEBAPP|
                    +------+                    +------+
                    | DTLS |                    | SCTP |
             +-------------+             +-------------+
             | STUN | SCTP |             | STUN | DTLS |
             +-------------+             +-------------+
             |    UDP      |             |    UDP      |
             +-------------+             +-------------+

The UDP encapsulation of SCTP used in the protocol stack shown on the left hand side of Figure 4 is specified in [I-D.ietf-tsvwg-sctp-udp-encaps] and the usage of DTLS over SCTP is specified in [RFC6083]. Using the UDP encapsulation of SCTP allows SCTP implementations to run in user-land without any special privileges, but still allows the support of SCTP kernel implementations. This also requires no SCTP specific support in middleboxes like firewalls and NATs. However, if multihoming is required, SCTP needs to setup the associations iteratively, which requires support at the SCTP implementations. If WEBAPP does not use multihoming, the support of the iterative association setup procedure is not required. The SCTP payload is protected by DTLS, which provides confidentiality, integrity and source authentication. SCTP-AUTH as specified in [RFC4895] is used to provide integrity of SCTP control information related to the user messages like the SCTP stream identifier. Please note that the SCTP control information (like the SCTP stream identifier) is sent unencrypted.

Considering the protocol stack on the right hand side of Figure 4, the usage of DTLS over UDP is specified in [I-D.ietf-tls-rfc4347-bis]. Using SCTP on top of DTLS is currently unspecified. Since DTLS is typically implemented in user-land, an SCTP user-land implementation has also to be used. Kernel SCTP implementations can't be used. When using DTLS as the lower layer, only single homed SCTP associations can be used, since DTLS does not expose any any address management to its upper layer. DTLS implementations used for this stack must support controlling fields of the IP layer like the DF-bit in case of IPv4 and the DSCP field. This is required for performing path MTU discovery. The DTLS implementation must also support sending user messages exceeding the path MTU. When supporting multiple SCTP associations over a single DTLS connection, incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore the number of SCTP associations should be limited to one or ICMP and ICMPv6 messages should be ignored. In general, the lower layer interface of an SCTP implementation has to be adopted to address the differences between IPv4 or IPv6 (being connection-less) or DTLS (being connection-oriented). When this stack is used, DTLS protects the complete SCTP packet, so it provides confidentiality, integrity and source authentication of the complete SCTP packet.

It should be noted that both stack alternatives support the usage of multiple SCTP streams. A user message can be sent ordered or unordered and, if the SCTP implementations support [RFC3758], with partial reliability. When using partial reliability, it might make sense to use a policy limiting the number of retransmissions. Limiting the number of retransmissions to zero provides a UDP like service where each user messages is sent exactly once.

SCTP provides congestion control on a per-association base. This means that all SCTP streams within a single SCTP association share the same congestion window. Traffic not being sent over SCTP is not covered by the SCTP congestion control.

6. Message Format.

TBD if we need also to design a framing or not.

At time of writing nobody has identified a real need for masking of UDP, and DTLS is a much-preferred solution for encryption/authentication.

More SCTP already provides sequence number information (e.g. stream sequence numbers). However there could be a need to support different kind of message (link in WebSocket where there is support to distinguish between Unicode text and binary frames), since for SCTP they are all user message. In the case there is this need a possibility is to map types to streams.

7. Security Considerations

To be done.

8. IANA Considerations

This document does not require any actions by the IANA.

9. Acknowledgments

Many thanks for comments, ideas, and text from Cullen Jennings, Eric Rescorla, Randall Stewart and Justin Uberti.

10. References

Authors' Addresses