Network Working Group M. Petit-Huguenin Internet-Draft (Unaffiliated) Intended status: Standards Track March 9, 2009 Expires: September 10, 2009 Alternative Proposal for Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations draft-petithuguenin-turn-tcp-variant-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 10, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document proposes to use a shared TCP connection between a Traversal Using Relays around NAT (TURN) client and a TURN server Petit-Huguenin Expires September 10, 2009 [Page 1]
Internet-Draft TURN TCP March 2009 instead of the multiple TCP connections proposed by [I-D.ietf-behave-turn-tcp] Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Shared Connection vs Multiple Connections Comparison . . . . . 3 2.1. Unified Mechanism . . . . . . . . . . . . . . . . . . . . . 3 2.2. TCP Connection Overhead . . . . . . . . . . . . . . . . . . 3 2.3. Multiple Connections Advantages . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Client and Server Processing . . . . . . . . . . . . . . . . . 5 4.1. Sending a Connect Request . . . . . . . . . . . . . . . . . 5 4.2. Receiving a Connect Request . . . . . . . . . . . . . . . . 5 4.3. Receiving a Connect Response . . . . . . . . . . . . . . . 5 4.4. Receiving a TCP Connection on an Allocation . . . . . . . . 5 4.5. Receiving a ConnectAttempt Request . . . . . . . . . . . . 5 4.6. Receiving a ConnectAttempt Response . . . . . . . . . . . . 5 4.7. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 6 4.8. Sending an AdjustWindow Indication . . . . . . . . . . . . 6 4.9. Receiving an AdjustWindow Indication . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Running Code Considerations . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 8 A.1. Modifications between -01 and -00 . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Petit-Huguenin Expires September 10, 2009 [Page 2]
Internet-Draft TURN TCP March 2009 1. Introduction [I-D.ietf-behave-turn-tcp] 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 [I-D.ietf-behave-turn]. 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 [RFC4254] is used to manage the flow of data over the shared TCP connection. 2. Shared Connection vs Multiple Connections Comparison 2.1. Unified Mechanism The main question behind this proposal is why not reusing the existing multiplexing design in [I-D.ietf-behave-turn], but one can ask the opposite question: Why not apply the same multiple connections mechanism proposed in [I-D.ietf-behave-turn-tcp] to [I-D.ietf-behave-turn]? 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 [RFC4571] 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. 2.2. TCP Connection Overhead NATs create per-stream state and so can cause other streams to fail once they run out of space [I-D.iab-ip-model-evolution], thus preventing additional peer connections from the same allocation. A shared TCP connection does not create additional per-stream state in Petit-Huguenin Expires September 10, 2009 [Page 3]
Internet-Draft TURN TCP March 2009 the NAT when additional peer connections are created. TCP connection establishment is relatively slow. This is the reason why HTTP 1.1 [RFC2616] has a persistent connections feature and SSH [RFC4254] has a multiplexing mechanism. The impact of TCP connection establishment can be significant when TURN TCP is used with ICE TCP [I-D.ietf-mmusic-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 [1]. (Is it still true?) Using a multiplexed TCP connection can eliminate the slow start delay for subsequent connections and improve congestion control. 2.3. Multiple Connections Advantages 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 [2] acquired from the OpenSSH implementation. 3. Terminology 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 [RFC2119]. Petit-Huguenin Expires September 10, 2009 [Page 4]
Internet-Draft TURN TCP March 2009 4. Client and Server Processing 4.1. Sending a Connect Request 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. 4.2. Receiving a Connect Request 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. 4.3. Receiving a Connect Response The TURN client associates the current window size in the WINDOW-SIZE attribute to the IP address and port of the peer TCP connection. 4.4. Receiving a TCP Connection on an Allocation 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. 4.5. Receiving a ConnectAttempt Request 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. 4.6. Receiving a ConnectAttempt Response The TURN server associates the current window size in the WINDOW-SIZE attribute to the IP address and port of the peer TCP connection. Petit-Huguenin Expires September 10, 2009 [Page 5]
Internet-Draft TURN TCP March 2009 4.7. Sending Data 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. 4.8. Sending an AdjustWindow Indication 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. 4.9. Receiving an AdjustWindow Indication 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. 5. Security Considerations TBD 6. IANA Considerations TBD 7. Running Code Considerations TBD 8. Acknowledgements Adam Roach proposed to use the SSH algorithm at the microphone in the BEHAVE session in Minneapolis. Thanks to Remi Denis-Courmont and Simon Perreault for their comments, suggestions and questions that helped to improve this document. Petit-Huguenin Expires September 10, 2009 [Page 6]
Internet-Draft TURN TCP March 2009 This document was written with the xml2rfc tool described in [RFC2629]. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [I-D.ietf-behave-turn-tcp] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", draft-ietf-behave-turn-tcp-02 (work in progress), March 2009. 9.2. Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, July 2006. [I-D.iab-ip-model-evolution] Thaler, D., "Evolution of the IP Model", draft-iab-ip-model-evolution-01 (work in progress), November 2008. [I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-13 (work in progress), February 2009. [I-D.ietf-mmusic-ice-tcp] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Petit-Huguenin Expires September 10, 2009 [Page 7]
Internet-Draft TURN TCP March 2009 draft-ietf-mmusic-ice-tcp-07 (work in progress), July 2008. URIs [1] <http://www.icir.org/floyd/tcp_mux.html> [2] <http://www.psc.edu/networking/projects/hpn-ssh/papers/ a14-rapier.pdf> Appendix A. Release notes This section must be removed before publication as an RFC. A.1. Modifications between -01 and -00 o Changed author address. o Changed the IPR to trust200902. o Rewrote abstract. o Rewrote introduction with comparisons between the two mechanisms. o MAX-SIZE is the size of the allocated buffer. o Added support for ConnectAttempt. Author's Address Marc Petit-Huguenin (Unaffiliated) Email: petithug@acm.org Petit-Huguenin Expires September 10, 2009 [Page 8]