Alternative Proposal for Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
(Unaffiliated)
petithug@acm.org
This document proposes to use a shared TCP connection between a Traversal Using Relays around NAT (TURN) client and a TURN server instead of the multiple TCP connections proposed by
proposes to create a separate TCP connection between the TURN client and the TURN server for each TCP connection between the TURN server and a peer.
This document proposes to reuse the multiplexing mechanism defined in .
With this proposal, the data received and sent between the TURN server and the peer are multiplexed on the TCP connection between the TURN client and the TURN server by using either the Send/Data indications or by using channels.
A window mechanism similar to the one described in SSH is used to manage the flow of data over the shared TCP connection.
The main question behind this proposal is why not reusing the existing multiplexing design in , but one can ask the opposite question:
Why not apply the same multiple connections mechanism proposed in to ?
This would greatly simplify the TURN specification because the TURN client IP address and port of a data connection would uniquely identify the peer so channels, Send and Data indications would become unnecessary.
Data connections simply forward data in both direction after the end of the ConnectionBind transaction so when is used UDP both between the TURN client and the TURN server and between the TURN server and the peer the packets can be sent and received without overhead.
When TCP is used between the TURN client and the TURN server and UDP between the TURN server and the peer, the framing can be used.
In any case, having only one mechanism for carrying data between the TURN client and TURN server is better than having two mechanisms.
Note that it is unlikely that TURN will be modified this late to support the TURN TCP mechanism.
NATs create per-stream state and so can cause other streams to fail once they run out of space, thus preventing additional peer connections from the same allocation.
A shared TCP connection does not create additional per-stream state in the NAT when additional peer connections are created.
TCP connection establishment is relatively slow.
This is the reason why HTTP 1.1 has a persistent connections feature and SSH has a multiplexing mechanism.
The impact of TCP connection establishment can be significant when TURN TCP is used with ICE TCP.
ICE TCP will open a number of TCP connections for connectivity check and then close all of them excepted one.
This behavior fits well with the multiplexing mechanism, where no additional TCP connections will be created for the connectivity checks.
Multiple TCP connections between the same endpoints do not share congestion state.
(Is it still true?)
Using a multiplexed TCP connection can eliminate the slow start delay for subsequent connections and improve congestion control.
A shared TCP connection can suffer from Head-Of-Line blocking, preventing a stream to forward data because a segment carrying data for another stream was lost.
This cannot happen with multiple TCP connections.
Note that the same problem exists in TURN when TCP is used between the TURN client and the TURN server and UDP between the TURN server and the peers.
The multiple TCP connections mechanism permits some optimizations, either in userspace, kernel or hardware, that are difficult to use with the shared connection mechanism.
Shared connections can also prevent using ECN or new congestion algorithms and make the implementation of an eventual "preserving behavior" difficult.
The shared connection mechanism reuses the multiplexing mechanism from TURN, so there is no additional complexity added by this in an implementation that already supports TURN.
The only complexity added is the management of the window.
The mechanism is directly inspired by the SSH mechanism and so can reuse the experience acquired from the OpenSSH implementation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
To initiate a TCP connection to a peer, a TURN client MUST send a Connect request to the TURN server that include a WINDOW-SIZE attribute containing how many bytes of data can be sent to the TURN client without adjusting the window, and a MAX-SIZE attribute containing the maximum size of the buffer allocated.
If the connection is successful, the TURN server sends back to the TURN client a Connect response containing a WINDOW-SIZE attribute containing how many bytes of data can be sent to the TURN server without adjusting the window, and a MAX-SIZE attribute containing the maximum size of the buffer allocated.
The TURN server associates the current window size in the WINDOW-SIZE attribute to the TCP connection to the peer.
The TURN client associates the current window size in the WINDOW-SIZE attribute to the IP address and port of the peer TCP connection.
After accepting the connection, the TURN server sends a ConnectionAttempt request to the client that include a WINDOW-SIZE attribute containing how many bytes of data can be sent to the TURN server without adjusting the window, and a MAX-SIZE attribute containing the maximum size of the buffer allocated.
The TURN server associates the current window size in the WINDOW-SIZE attribute to the TCP connection to the peer.
The TURN client associates the current window size in the WINDOW-SIZE attribute to the IP address and port of the peer TCP connection and sends back to the TURN server a ConnectAttempt response containing a WINDOW-SIZE attribute containing how many bytes of data can be sent to the TURN client without adjusting the window, and a MAX-SIZE attribute containing the maximum size of the buffer allocated.
The TURN server associates the current window size in the WINDOW-SIZE attribute to the IP address and port of the peer TCP connection.
When sending data in a ChannelData, Send or Data message the TURN server or client decreases the current window size by the number of bytes sent.
The TURN server or client MUST stop sending when the current window size is smaller than the size of the data to send.
When ready to receive more data, the TURN server or client sends an AdjustWindow indication to the other side.
The AdjustWindow indication MUST contain either a XOR-PEER-ADDRESS or a CHANNEL-NUMBER attribute identifying the TCP connection to the peer.
The AdjustWindow indication MUST contain a ADD-SIZE attribute containing the value to add to the current window size.
When receiving an AdjustWindow indication, a TURN client or server uses the XOR-PEER-ADDRESS or CHANNEL-NUMBER to find the current window size associated to the TCP connection to the peer.
The TURN client or server then increases the window size by the value in the ADD-SIZE attribute and can eventually restart sending data.
Adam Roach proposed to use the SSH algorithm at the microphone in the BEHAVE session in Minneapolis.
Thanks to RĂ©mi Denis-Courmont and Simon Perreault for their comments, suggestions and questions that helped to improve this document.
This document was written with the xml2rfc tool described in .
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
The Secure Shell (SSH) Connection Protocol
Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</t><t> This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.</t><t> The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS TRACK]
Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server.
Hypertext Transfer Protocol -- HTTP/1.1
Department of Information and Computer Science
University of California, Irvine
Irvine
CA
92697-3425
+1(949)824-1715
fielding@ics.uci.edu
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
jg@w3.org
Compaq Computer Corporation
Western Research Laboratory
250 University Avenue
Palo Alto
CA
94305
mogul@wrl.dec.com
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
frystyk@w3.org
Xerox Corporation
MIT Laboratory for Computer Science, NE43-356
3333 Coyote Hill Road
Palo Alto
CA
94034
masinter@parc.xerox.com
Microsoft Corporation
1 Microsoft Way
Redmond
WA
98052
paulle@microsoft.com
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
Writing I-Ds and RFCs using XML
Invisible Worlds, Inc.
660 York Street
San Francisco
CA
94110
US
+1 415 695 3975
mrose@not.invisible.net
http://invisible.net/
General
RFC
Request for Comments
I-D
Internet-Draft
XML
Extensible Markup Language
This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.
Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport
This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS TRACK]
Evolution of the IP Model
This draft attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, and especially properties which were (and at times still are) incorrectly perceived to exist, as well as properties that would cause problems if changed. Finally, it provides some guidance to protocol designers and implementers.
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE.
TCP Candidates with Interactive Connectivity Establishment (ICE)
Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream.
This section must be removed before publication as an RFC.
Changed author address.
Changed the IPR to trust200902.
Rewrote abstract.
Rewrote introduction with comparisons between the two mechanisms.
MAX-SIZE is the size of the allocated buffer.
Added support for ConnectAttempt.