[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/