MPTCP Working Group L. Deng INTERNET-DRAFT P. Fan Intended Status: Informational Hui Deng Expires: August 14, 2014 China Mobile February 14, 2014 ISP Turn Server For Third Party WEBRTC Traffic Relay draft-deng-tram-isp-turn-00 Abstract This document describes usecases and requirements for ISP to provide their own TURN servers to relay third party WEBRTC traffic. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 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 Expires August 14, 2014 [Page 1] INTERNET DRAFT February 14, 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Use-cases for Network deployed TURN servers . . . . . . . . . . 3 3.1 Traffic Locality . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Resource Sharing . . . . . . . . . . . . . . . . . . . . . . 4 3.3 ISP QoS Support . . . . . . . . . . . . . . . . . . . . . . 4 4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Expires August 14, 2014 [Page 2] INTERNET DRAFT February 14, 2014 1 Introduction Historically, stun/turn servers are not deployed by ISPs, as ICE is designed to allow network-agnostic feature. It is envisioned that driven by WEBRTC movement, third party ICE (stun and turn) would see increasingly deployment boost in the coming years, as webrtc-compatible browsers rely on ICE framework to enable NAT traversal capabilities for peer-to-peer media communication. For turn, which is essentially a media relay gateway for peer-to-peer media traffic, relying exclusively in a network agnostic way is clearly not an efficient way of large volume traffic routing from the ISP's point of view. It may result in a second thought for the ISP on whether or not it should provide public TURN server facilities to third party WEBRTC applications. On the other hand, from the perspective of WEBRTC applications, cooperation with ISP deployed turn server could also mean another chance of further exploring network capability in delivering better user experience. 2 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 RFC 2119 [RFC2119]. 3 Use-cases for Network deployed TURN servers Three cases are discussed in current draft. 3.1 Traffic Locality From an ISP's point of view, for two local WEBRTC users communicating via an third party TURN server usually result in sub-optimal outcome. If the SP's TURN server is located outside the ISP's network, the media traffic it relays has to go through the inter-working point to another ISP twice, which is usually the most congested points for the user and most expensive links for the local ISP. In this case, using a local (network deployed) TURN server would result in a win-win situation. Expires August 14, 2014 [Page 3] INTERNET DRAFT February 14, 2014 3.2 Resource Sharing For large WEBRTC SPs, it may be tempting to build up their own relay overlay and gain sufficient efficiency for targeted areas. However, small or integrated WEBRTC SPs, may prefer to make use of ISP's locally deployed relay network to reduce CAPEX and OPEX for emerging markets. On the other hand, by providing public accessible relay network and share it with multiple third party applications, the construction/management cost for an ISP is considerably small in comparison to each SP building up a private one. 3.3 ISP QoS Support For QoS sensitive traffic like WEBRCT media, it would bring substantial enhancement to user experience if relevant QoS requirement be honored and properly handled by the network devices along the way. Although there has been work on DSCP setting for various WEBRTC media packet, there is no guarantee that these end2end setting be honored by an ISP, unless they are officially recognized by the network from a QoS-enabled boundary device and/or be explicitly promised to be honored by agreement. By utilizing ISP deployed TURN server, there is an explicit way of indicating to the network the traffic is real-time interactive and should be QoS enabled. 4 Summary According to the above discussion, it is believed that making explicit usage of ISP deployed relay network would be a plus to both third party WEBRTC SPs as well as local ISPs. To enable flexible application, the ISP needs to be given an opportunity to advertise/announce to the application/WebRTC browser the availability of an optimal TURN server to use. This should also be the TURN server to use, unless there are other concerns than best quality/user experience for the application to be considered. The auto-discovery mechanism of TURN servers discussed, is a way to realize and meet the needs for the ISP to announce and enforce the usage of an optimal TURN server for quality considerations, and should not in anyway conflict with the need for NAT/firewall traversal. Expires August 14, 2014 [Page 4] INTERNET DRAFT February 14, 2014 5 Security Considerations TBA. 6 Acknowledgements The authors wish to thank Karl Stahl for providing comments, feedback, text and improvement proposals on the document. 7 IANA Considerations There is no IANA action in this document. Expires August 14, 2014 [Page 5] INTERNET DRAFT February 14, 2014 6 References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower-based Applications", I-D.ietf-rtcweb- overview (Work in Progress), september 2013. Expires August 14, 2014 [Page 6] INTERNET DRAFT February 14, 2014 Authors' Addresses Lingli Deng China Mobile Email: Email: denglingli@chinamobile.com Peng Fan China Mobile Email: Email: fanpeng@chinamobile.com Hui Deng China Mobile Email: Email: denghui@chinamobile.com Expires August 14, 2014 [Page 7]