Internet DRAFT - draft-wing-tsvwg-turn-flowdata
draft-wing-tsvwg-turn-flowdata
TSVWG D. Wing
Internet-Draft T. Reddy
Intended status: Standards Track Cisco Systems
Expires: March 14, 2015 B. Williams
Akamai, Inc.
R. Ravindranath
Cisco Systems
September 10, 2014
TURN extension to convey flow characteristics
draft-wing-tsvwg-turn-flowdata-01
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 March 14, 2015.
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
Wing, et al. Expires March 14, 2015 [Page 1]
Internet-Draft TURN flowdata September 2014
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design considerations . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 4
4.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 5
4.2.1. Conflict Resolution . . . . . . . . . . . . . . . . . 5
4.3. Receiving a ChannelBind Response . . . . . . . . . . . . 6
5. FLOWDATA format . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Traversal Using Relay NAT (TURN) [RFC5766] is a protocol that is
often used to improve the connectivity of P2P applications. TURN
allows a connection to be established 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
Wing, et al. Expires March 14, 2015 [Page 2]
Internet-Draft TURN flowdata September 2014
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 indications 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.
Wing, et al. Expires March 14, 2015 [Page 3]
Internet-Draft TURN flowdata September 2014
* 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:
o Usable at the application level to the TURN client, without
needing operating system support.
o 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
Wing, et al. Expires March 14, 2015 [Page 4]
Internet-Draft TURN flowdata September 2014
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. The TURN server determines if the flow can
be fully or 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, minimum bandwidth,
maximum bandwidth). 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.
Wing, et al. Expires March 14, 2015 [Page 5]
Internet-Draft TURN flowdata September 2014
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---| |
Figure 1: Message diagram, resolving conflict
In the above example if the TURN server has already responded to
client B before it receives the request from client A then the TURN
server can correct the conflict only when the client B refreshes the
binding.
4.3. Receiving a ChannelBind Response
When the client receives a ChannelBind success response, it proceeds
with processing the response according to the TURN specification
[RFC5766]. If the message does not include an FLOWDATA attribute, no
additional processing is required. The returned FLOWDATA attribute,
if present, indicates the accommodation of this flow the TURN server
will perform. This document does not define what the TURN client
might do with that information, but it could choose among several
TURN servers or use it for other purposes.
5. FLOWDATA format
This section describes the format of the new STUN attribute FLOWDATA.
FLOWDATA will have a type TBD-CA and length of 4 bytes. The FLOWDATA
attribute in the request has the following format.
Wing, et al. Expires March 14, 2015 [Page 6]
Internet-Draft TURN flowdata September 2014
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 |
+---------------------------------------------------------------+
| Upstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FLOWDATA attribute in request
Description of the fields:
uDT: Upstream Delay Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
uLT: Upstream Loss Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
uJT: Upstream Jitter Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
dDT: Downstream Delay Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
dLT: Downstream Loss Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
dJT: Downstream Jitter Tolerance, 0=no information available, 1=very
low, 2=low, 3=medium, 4=high.
RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
Upstream Minimum Bandwidth: Measures bandwidth sent by the client.
Value is in octets per second. The value 0 means no information
is available.
Wing, et al. Expires March 14, 2015 [Page 7]
Internet-Draft TURN flowdata September 2014
Downstream Minimum Bandwidth: Measures bandwidth sent to the client.
Value is in octets per second. The value 0 means no information
is available.
Upstream Maximum Bandwidth: Measures bandwidth sent by the client.
Value is in octets per second. The value 0 means no information
is available.
Downstream Maximum Bandwidth: Measures bandwidth sent to the client.
Value is in octets per second. The value 0 means no information
is available.
Different applications have different needs for their flows. The
following table is derived from [RFC4594] to serve as a guideline for
tolerance to loss, delay and jitter for some sample applications.
The range 0 to 4 used for the fields in FLOWDATA attribute, meets the
need to convey the tolerance levels for the traffic serviced by the
service classes in the below table.
Wing, et al. Expires March 14, 2015 [Page 8]
Internet-Draft TURN flowdata September 2014
-------------------------------------------------------------------
|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) | | | |
-------------------------------------------------------------------
Figure 3: Flow characteristics
Wing, et al. Expires March 14, 2015 [Page 9]
Internet-Draft TURN flowdata September 2014
The FLOWDATA attribute in the response has the following format
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 |
+---------------------------------------------------------------+
| Accommodated Upstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accommodated Downstream Minimum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accommodated Upstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accommodated Downstream Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: FLOWDATA attribute in response
Description of the fields:
AuDT: Accommodated Upstream Delay Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
AuLT: Accommodated Upstream Loss Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
AuJT: Accommodated Upstream Jitter Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
AdDT: Accommodated Downstream Delay Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
AdLT: Accommodated Downstream Loss Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
Wing, et al. Expires March 14, 2015 [Page 10]
Internet-Draft TURN flowdata September 2014
AdJT: Accommodated Downstream Jitter Tolerance, 0=no information
available, 1=able to accommodate very low, 2=able to accommodate
low, 3=able to accommodate medium, 4=able to accommodate high.
RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0
on transmission.
Accommodated Upstream Minimum Bandwidth: Bandwidth accommodated for
this flow. Value in bytes per second. 0 means no information is
available.
Accommodated Downstream Minimum Bandwidth: Bandwidth accommodated
for this flow. Value in bytes per second. 0 means no information
is available.
Accommodated Upstream Maximum Bandwidth: Bandwidth accommodated for
this flow. Value in bytes per second. 0 means no information is
available.
Accommodated Downstream Maximum Bandwidth: Bandwidth accommodated
for this flow Value in bytes per second, 0 means no information is
available.
6. Security Considerations
On some networks, only certain users or certain applications are
authorized to signal the priority of a flow. This authorization can
be achieved with STUN long-term authentication [RFC5389].
7. IANA Considerations
This document defines the FLOWDATA STUN attribute, described in
Section 5. IANA has allocated the comprehension-optional codepoint
TBD-CA for this attribute.
8. Acknowledgement
Authors would like to thank Anca Zamfir and Charles Eckel for their
comments and review.
9. References
9.1. Normative References
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-11
(work in progress), August 2014.
Wing, et al. Expires March 14, 2015 [Page 11]
Internet-Draft TURN flowdata September 2014
[I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
Polk, "DSCP and other packet markings for RTCWeb QoS",
draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June
2014.
[I-D.williams-peer-redirect]
Williams, B. and T. Reddy, "Peer-specific Redirection for
Traversal Using Relays around NAT (TURN)", draft-williams-
peer-redirect-01 (work in progress), June 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
9.2. Informative References
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, August
2006.
Authors' Addresses
Dan Wing
Cisco Systems
821 Alder Drive
Milpitas, California 95035
USA
Email: dwing@cisco.com
Tirumaleswar Reddy
Cisco Systems
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Wing, et al. Expires March 14, 2015 [Page 12]
Internet-Draft TURN flowdata September 2014
Brandon Williams
Akamai, Inc.
8 Cambridge Center
Cambridge, MA 02142
USA
Email: brandon.williams@akamai.com
Ram Mohan Ravindranath
Cisco Systems
Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: rmohanr@cisco.com
Wing, et al. Expires March 14, 2015 [Page 13]
