TURN extension to convey flow characteristics
draft-wing-tsvwg-turn-flowdata-00

Abstract

TURN server and the network in which it is hosted due to load could adversely impact the traffic relayed through it. During such high load event, it is desirable to shed some traffic but TURN server lack requirements about the flows to prioritize them. This document defines such a mechanism to communicate flow characteristics from the TURN client to its TURN server.

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 December 6, 2014.

Copyright Notice

Copyright (c) 2014 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. Terminology
• 3. Design considerations
• 4. Solution Overview
• 4.1. Sending a ChannelBind Request
• 4.2. Receiving a ChannelBind Request
• 4.2.1. Conflict Resolution
• 4.3. Receiving a ChannelBind Response
• 5. FLOWDATA format
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgement
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

Traversal Using Relay NAT (TURN) [RFC5766] is a protocol that is often used to improve the connectivity of P2P applications. TURN ensures that a connection can be established even when one or both sides is incapable of a direct P2P connection. A TURN server could be provided by an enterprise network, an access network, an application service provider or a third party provider. A TURN server could be used to relay media streams, WebRTC data channels [I-D.ietf-rtcweb-overview] , gaming, file transfer etc. A TURN server and the network in which it is hosted could have insufficient bandwidth or other characteristics that could adversely impact the traffic relayed through it and need a mechanism to identify and provide differentiated service to flows relayed through the TURN server.

This specification provides a mechanism for the client to signal the flow characteristics of a relay channel to the TURN server, so that certain relay channels can receive service that is differentiated from others. The TURN server authorizes the request and signals back to the client that it can (fully or partially) accommodate the flow. This sort of signaling will be useful for long-lived flows such as media streams, WebRTC data channels etc traversing through the TURN server. The TURN server can further communicate the flow information to a number of on-path devices in its network using a Policy decision Point (e.g. SDN controller). This way the network hosting the TURN server can accommodate the flow. With this mechanism, a TURN client can request the TURN server to provide certain characteristics for the relayed channel on both legs (client-to-server, server-to-peer). Applications using TURN as a communication relay would benefit from such an arrangement as it would improve the Quality of Experience (QOE) of the end user.

Note: It is not the intent of this document to advocate in favor of prioritizing relayed candidates over host, server-reflexive candidates, but to highlight the proposed mechanism only when TURN server is selected for various reasons like privacy, ICE connectivity checks with local host/server-reflexive candidates have failed etc.

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 [RFC2119].

3. Design considerations

1. TURN client can choose to either use Send and Data methods or channels to exchange data with its peer. For bandwidth intensive applications (like video, audio, WebRTC data channels) using Send indication or Data indication adds 36 bytes overhead to the application data and substantially increases the bandwidth required between the client and the server. Hence channels are commonly used for bandwidth intensive applications to exchange data. The other problem with using Send/Data indications is that if the TURN server determines that a flow can only be partially accommodated then this feedback cannot be conveyed back to the client. Hence in this specification focuses on conveying the flow characteristics only in ChannelBind request/response.
2. DSCP style markings can also help provide QOS, but has the following limitations:
   • DiffServ style packet marking can help provide QoS in some environments but DSCP markings are often modified or removed at various points in the network or when crossing network boundaries. DSCP markings set by the client may be modified or removed by the intervening network(s) before it reaches the TURN server.
   • DSCP values are site specific, with each site selecting its own code points for each QoS level, hence it may not work across domains. However [I-D.ietf-tsvwg-rtcweb-qos] recommends default set of DSCP values for browsers when there is no site specific information.
   • TURN client may not be able to set DSCP values for outgoing packets because of OS limitations.
   • DSCP provides differentiated service only in the outgoing direction of a flow.

The mechanism described in this document has none of the above limitations and the following useful properties:

• Usable at the application level to the TURN client, without needing operating system support.
• Robust metadata support, to convey sufficient information to the TURN server about the flow.

4. Solution Overview

When a channel binding is initiated by the client, it may also indicate certain characteristics of its flow to the TURN server. The TURN server uses that information to prioritize the flow in its network and signals back to the client that it can (fully or partially) accommodate the flow.

This specification defines one new comprehension-optional STUN attribute: FLOWDATA. If a TURN client wishes to signal the flow characteristics of the relay channel it MUST insert this attribute in ChannelBind request. This attribute if used MUST be sent only in the ChannelBind request. Other specifications in future may extend this attribute to be used in other STUN methods. The TURN server determines if it can accommodate that flow, making configuration changes if necessary to accommodate the flow, and returns information in the FLOWDATA attribute indicating its ability to accommodate the described flow.

4.1. Sending a ChannelBind Request

The TURN client sends ChannelBind request with the FLOWDATA STUN attribute to signal the flow characteristics of the relay channel to the TURN server. If the flow characteristics of a relay channel change then the client MAY send ChannelBind request with an updated FLOWDATA STUN attribute to refresh the binding. Similarly if the binding is refreshed using ChannelBind request then the client can also signal updated FLOWDATA STUN attribute if the flow characteristics of the relay channel have changed.

4.2. Receiving a ChannelBind Request

When a TURN server receives a ChannelBind request that includes a FLOWDATA attribute, it processes the request as per the TURN specification [RFC5766] plus the specific rules mentioned below.

The TURN server will determine if it can provide the flow resources requested by the client. If the TURN server determines the flow can only be partially accommodated, it returns values in the FLOWDATA fields that it can accommodate or returns 0 in those FLOWDATA fields where it has no information. In other words if the request indicated a low tolerance for delay but the TURN server determines that only high delay is available, the FLOWDATA response indicates high delay is available. The same sort of processing occurs on all of the FLOWDATA fields of the response (upstream and downstream delay tolerance, loss tolerance, jitter tolerance). If the TURN server determines the flow can only be partially accommodated and the client has also signaled CHECK- ALTERNATE attribute [I-D.williams-peer-redirect] then the TURN server MAY re-direct the client to an alternate TURN server that could accommodate the flow characteristics conveyed by the client.

If the TURN server can accommodate the flow as described in the FLOWDATA attribute, it sends a success response and includes the FLOWDATA attribute filled in according to Section 5. The TURN server SHOULD include the FLOWDATA attribute in ChannelBind response only when the client had signaled FLOWDATA attribute in ChannelBind request.

4.2.1. Conflict Resolution

It is possible that two hosts send requests with different thresholds for delay or jitter in each direction for the same flow, and their requests arrive at the same TURN server. If this occurs, it is RECOMMENDED that the TURN server uses the stricter delay/loss tolerance (that is, the lower tolerance to delay or jitter). The diagram below depicts a conflict message flow.

   TURN Client A      TURN server           TURN Client B
     |                         |                       |
     |-loss=med, delay=med---->|<-loss=hi, delay=hi----|
     |                         |                       |
     |                    (conflict!)                  |
     |                         |                       |
     |                         |--loss=med, delay=med->|
     |                         |                       |
     |<--loss=med, delay=med---|                       |

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Attribute Type (TBD-CA)   |          Length (4)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | uDT | uLT | uJT |   RSVD1     | dDT | dLT | dJT |    RSVD2    |
  +---------------------------------------------------------------+
   
          

 -------------------------------------------------------------------
|Service Class  |                              |    Tolerance to    |
|    Name       |  Traffic Characteristics     | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
|   Network     |Variable size packets, mostly |      |      |      |
|   Control     |inelastic short messages, but |  Low |  Low | High |
|               | traffic can also burst       |      |      |      |
|               | (e.g., OSPF)                 |      |      |      |
|---------------+------------------------------+------+------+------|
|               | Fixed-size small packets,    | Very | Very | Very |
|  Telephony    | constant emission rate,      |  Low |  Low |  Low |
|               | inelastic and low-rate flows |      |      |      |
|               | (e.g., G.711, G.729)         |      |      |      |
|---------------+------------------------------+------+------+------|
|   Signaling   | Variable size packets, some  | Low  | Low  | High |
|               | what bursty short-lived flows|      |      |      |
|---------------+------------------------------+------+------+------|
|  Multimedia   | Variable size packets,       | Low  | Very |      |
| Conferencing  | constant transmit interval,  |  -   | Low  | Low  |
|               |rate adaptive, reacts to loss |Medium|      |      |
|---------------+------------------------------+------+------+------|
|   Real-Time   | RTP/UDP streams, inelastic,  | Low  | Very | Low  |
|  Interactive  | mostly variable rate         |      | Low  |      |
|---------------+------------------------------+------+------+------|
|  Multimedia   |  Variable size packets,      |Low - |Medium| High |
|   Streaming   | elastic with variable rate   |Medium|      |      |
|---------------+------------------------------+------+------+------|
|   Broadcast   | Constant and variable rate,  | Very |Medium| Low  |
|     Video     | inelastic, non-bursty flows  |  Low |      |      |
|---------------+------------------------------+------+------+------|
|  Low-Latency  | Variable rate, bursty short- | Low  |Low - | High |
|      Data     |  lived elastic flows         |      |Medium|      |
|---------------+------------------------------+------+------+------|
|      OAM      |  Variable size packets,      | Low  |Medium| High |
|               |  elastic & inelastic flows   |      |      |      |
|---------------+------------------------------+------+------+------|
|High-Throughput| Variable rate, bursty long-  | Low  |Medium| High |
|      Data     |   lived elastic flows        |      |- High|      |
|---------------+------------------------------+------+------+------|
|   Standard    | A bit of everything          |   0     0       0  |
|---------------+------------------------------+------+------+------|
| Low-Priority  | Non-real-time and elastic    | High | High | High |
|      Data     | (e.g., network backup)       |      |      |      |
 -------------------------------------------------------------------
   
          

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Attribute Type (TBD-CA)   |          Length (4)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | AuDT| AuLT| AuJT|   RSVD1     | AdDT| AdLT| AdJT|    RSVD2    |
  +---------------------------------------------------------------+