Internet DRAFT - draft-martinsen-tram-turnbandwidthprobe
draft-martinsen-tram-turnbandwidthprobe
TRAM P. Martinsen
Internet-Draft T. Andersen
Intended status: Informational G. Salgueiro
Expires: November 30, 2015 Cisco
M. Petit-Huguenin
Impedance Mismatch
May 29, 2015
Traversal Using Relays around NAT (TURN) Bandwidth Probe
draft-martinsen-tram-turnbandwidthprobe-00
Abstract
Performing pre-call probing to discover a reasonable value for the
available bandwidth, is useful information that can be utilized by
bandwidth sensitive or bandwidth intensive network devices (e.g.,
video encoders). The method described herein is intended to produce
an initial bandwidth value. Applications using this mechanism should
also employ appropriate rate adaptation techniques. In addition to
bandwidth, latency and bufferbloat can also be measured. No
modification is needed on the server side.
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 November 30, 2015.
Copyright Notice
Copyright (c) 2015 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
Martinsen, et al. Expires November 30, 2015 [Page 1]
Internet-Draft TURN Bandwidth Probe May 2015
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
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 4
4.1. UDP Procedures . . . . . . . . . . . . . . . . . . . . . 5
4.2. TCP Procedures . . . . . . . . . . . . . . . . . . . . . 5
4.3. Sending Data to Measure Available Bandwidth and
Latency . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. New STUN Attribute . . . . . . . . . . . . . . . . . . . . . 7
6.1. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
7.1. Cisco Collaboration Endpoint (CE) . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
When Interactive Connectivity Establishment (ICE) [RFC5245] and
Traversal Using Relays around NAT (TURN) [RFC5766] are used by an
endpoint as a firewall/NAT traversal mechanism, the TURN relay can
also be used to measure bandwidth and latency prior to call setup.
In normal ICE behavior the client first sends a message (allocate
request) to the TURN server to allocate a RELAY address. This
address can be used by the endpoint to receive media from other
endpoints. The media stream is then received by the TURN server and
then relayed back to the endpoint behind the firewall/NAT. For
security reasons the endpoint must first set the correct permissions
on the TURN server to only allow media from remote participants it
wants to communicate with (i.e., addresses taken from the Session
Initiation Protocol (SIP) [RFC3261] Session Description Protocol
(SDP) [RFC4566] offer/answer exchange [RFC3264]) . The endpoint will
also learn its reflexive address on the firewall/NAT when talking to
the TURN server.
Martinsen, et al. Expires November 30, 2015 [Page 2]
Internet-Draft TURN Bandwidth Probe May 2015
Combining this with a TCP transfer on the same TURN server can be
used to also measure bufferbloat, an important metric for multimedia
applications.
Note that only the maximum bandwidth, maximum latency and maximum
bufferbloat of the aggregation of both uplink and downlink can be
measured. It is not possible with this technique to get the metrics
of only one. For most multimedia applications using TURN that is not
an issue as they are generally symmetrical, but some other use cases
(like conferencing) may need other techniques to measure these
metrics separately.
No modification to the TURN server is necessary.
2. Notational Conventions
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. Overview of Operation
Prior to the call (upon registering with the call control server,
receiving a configuration, loading application, or a similar event)
the endpoint can measure bandwidth and latency between the endpoint
and the TURN server.
*Relay
+------+
*Rflx -<-| TURN |<-\
/-------\ +-----+ / +------+ |
| |--<--| NAT |-<--- |
| Alice |--->-|-->--|->-->----->----->--/
\-------/ +-----+
Figure 1
The agent allocates a TURN Relay port on its designated TURN server
as described in TURN RFC [RFC5766]. In the process the agent will
also learn the outermost NAT address. This is called a reflexive
address (Rflx). For more information see Section 2.1 of the TURN RFC
regarding candidate gathering in ICE.
Martinsen, et al. Expires November 30, 2015 [Page 3]
Internet-Draft TURN Bandwidth Probe May 2015
The agent must set the permissions on the allocated RELAY port as
described in Section 8 of the TURN RFC to allow traffic from the
discovered reflexive address.
When sending packets to the allocated RELAY port on the TURN server,
the packets will be forwarded back to the agent in a data indication
packet. See Section 10 of the TURN RFC for details on how the TURN
server can relay packets back to the allocating agent. Available
bandwidth can be measured by sending varying number of packets and
detecting the amount of packet loss. Each packet sent affects both
upstream and downstream links.
To make it easier to calculate the available bandwidth a TIMESTAMP
attribute is defined in this document (see Section Section 6.1) and
can be added to the Session Traversal Utilities for NAT (STUN)
[RFC5389] probe packets. The PADDING attribute from the NAT Behavior
Discovery Using STUN RFC [RFC5780] can be used to vary the packet
size.
Discovering the MTU and network path (using the STUN-PMTUD
[I-D.petithuguenin-tram-stun-pmtud] and STUN Traceroute
[I-D.martinsen-tram-stuntrace] mechanisms) can also be performed when
probing for the bandwidth available between the client and the TURN
server.
4. Base Protocol Procedures
In order to perform the STUN bandwidth probing mechanism described in
this document, the client MUST take the following general steps
(explained in greater detail in the following subsections).
o Allocate TURN RELAY address
o Set correct permissions on the allocated TURN RELAY address
o Originating client sends data to itself through the TURN server
and measures bandwidth throughput and latency
When initiating a bandwidth probe it is important to not do so when a
device powers up or some similar initiating events. If a power
failure has happened and all devices within an area are rebooted
concurrently the bandwidth probing of all the devices can have a
DDOS-like effect. Measures should be taken to avoid such scenarios
(e.g., random delays to initiate bandwidth probing, etc).
Discovery of the TURN server as well as the determination of what
TURN server to uses is entirely at the discretion of the client and
outside the scope of this document. A client MUST be prepared to be
Martinsen, et al. Expires November 30, 2015 [Page 4]
Internet-Draft TURN Bandwidth Probe May 2015
redirected to another TURN server if it receives an ALTERNATE-SERVER
response.
While allocating the TURN RELAY port the client will learn its
outermost NAT address or reflexive address. This is the address the
TURN server will receive the bandwidth probing packets from.
The bandwidth mechanism can use either a UDP transport or a TCP.
Secure transports (i.e. TLS or DTLS) may be used to discover if an
intermediary network element tries to process flows differently when
they are secured.
4.1. UDP Procedures
The client allocates a TURN RELAY port as described in the TURN RFC.
The client then use a CreatePermission request with the obtained
reflexive address encoded in a XOR-PEER-ADDRESS attribute as
described in Section 9.1 of the TURN RFC.
It is recommended to create a TURN channel as soon as possible to
lower the overhead of the packets exchanged.
If the transport address used to send the UDP packets to the TURN
relay is identical to the transport address used to create the TURN
allocation, then a TURN Channel can be created immediately by using
the reflexive transport address learned during the Allocate.
If not, the TURN Channel can be created as soon the first Data
indication is received.
The client can then send UDP packets to the relay transport address
and receive then over the TURN Channel.
Immediately after this the client can send UDP packets over the TURN
channel and receive them directly, as an additional way of averaging
the impact of the difference of encapsulation for the packets. Note
that the client still need to periodically send packets over the TURN
Channel to persist eventual NAT bindings.
Note that the client cannot use a TCP transport to the server with a
UDP allocation because there would be no way to retrieve the UDP
reflexive address for the CreatePermission request.
4.2. TCP Procedures
The client allocates a TURN RELAY port as described in TURN
Extensions for TCP Allocations [RFC6062]. The client then use a
CreatePermission request with the obtained reflexive address encoded
Martinsen, et al. Expires November 30, 2015 [Page 5]
Internet-Draft TURN Bandwidth Probe May 2015
in a XOR-PEER-ADDRESS attribute as described in Section 9.1 of the
TURN RFC.
The client then establishes a TCP connection to the relay transport
address. The client will receive a ConnectAttempt indication that
will trigger a new TCP connection to the TURN server, and the sending
of a ConnectBind.
After completion of this procedure, data sent over the direct TCP
connection will be received over the bound TURN connection, and vice-
versa, although there is no difference of overhead in that case.
4.3. Sending Data to Measure Available Bandwidth and Latency
The specific calculation and measurement of the bandwidth is client
dependent and implementation-specific and is thus outside the scope
of this document.
If the client want to use STUN packets as the basis for the probing
packets, then a TIMESTAMP attribute is defined in this specification
(see Section Section 6.1) to simplify measurement of round-trip time
(RTT) and available bandwidth. A PADDING attribute is already
defined in RFC 5780 [RFC5780] that makes it easy to vary the size of
the STUN probing packet.
The probing packet will be sent upstream to the TURN server and later
received downstream from the TURN server. Available bandwidth would
typically be determined to be the lowest of the bandwidth values
calculated for the upstream and downstream directions.
If the RTP [RFC3550] loop-back mechanism described in RFC 6849
[RFC6849] is in use the method described here can extend the use-
cases mentioned in RFC6849 Section 1.1 to enable the "loopback
source" and "loopback mirror" to be running on the same device.
Using RTP would permit to reuse the standards RTP tools for
calculating latency, jitter and other metrics. It may also permit to
get better results if some intermediary network element has
preferential treatment for media packets.
The client should take care to reuse the same congestion control
mechanisms it uses when sending media to avoid unnecessary strain on
the network.
5. IANA Considerations
This specification defines a new STUN attribute. IANA added this new
attribute to the STUN Attributes sub-registry of the Session
Martinsen, et al. Expires November 30, 2015 [Page 6]
Internet-Draft TURN Bandwidth Probe May 2015
Traversal Utilities for NAT (STUN) Parameters registry. (This is
still an ID draft so not assignment yet)
6. New STUN Attribute
This STUN extension defines the following new attribute:
0xXXX0: TIMESTAMP
6.1. TIMESTAMP
The TIMESTAMP attribute has a length of 80 bits. Padding is needed
to hit the required 32 bit STUN attribute boundary.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seconds (32bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| microseconds (32bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seq (16bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: TIMESTAMP Attribute
The seconds and microseconds fields reflect what would be returned in
the struct timeval when calling getTimeofDay() function. Note that
the size of that struct may vary based on platform, but 32 bits is
more than sufficient to obtain the required accuracy for the feature
described in this document. It is RECOMMENDED to initialize these
fields with a random value that later can be subtracted to get the
right timing.
The seq field is a 16 bit sequence number. It is increased by one
for each bandwidth probe STUN packet sent. It is RECOMMENDED to
choose a random starting value.
7. Implementation Status
[[Note to RFC Editor: Please remove this section and the reference to
[RFC6982] before publication.]]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 6982
Martinsen, et al. Expires November 30, 2015 [Page 7]
Internet-Draft TURN Bandwidth Probe May 2015
[RFC6982]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.
According to RFC 6982 [RFC6982], "this will allow reviewers and
working groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit"
7.1. Cisco Collaboration Endpoint (CE)
Organization: Cisco
Name: Cisco Collaboration Endpoints (CE) software
Description: Hard video endpoint part of the Cisco collaboration
portfolio
Level of maturity: In released products
Coverage Implementation of base procedures of the functionality
described in this specification
Licensing: Proprietary
Implementation experience: Straight forward, but implementation was
don prior to writing up the spec
Contact: Paal-Erik Martinsen (palmarti@cisco.com)
8. Security Considerations
When setting permissions this is done on a per IP address basis.
Port number is not part of the permission. This is necessary
limitation of the TURN protocol [RFC5766] and not something
introduced by this specification.
To prevent replay attacks or other attacks that rely on static
sequence number initialization it is important to randomly initialize
the seq number in the TIMESTAMP Attribute. Likewise it is important
Martinsen, et al. Expires November 30, 2015 [Page 8]
Internet-Draft TURN Bandwidth Probe May 2015
to hide the time information by assigning a random value to the
seconds and microseconds fields. That random value can be added and
subtracted by the client when sending and receiving packets to get
the correct value. This prevents any information leakage regarding
time from the client.
9. Acknowledgements
Thanks to Dan Wing for input.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[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.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)", RFC
5780, May 2010.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations", RFC
6062, November 2010.
[RFC6849] Kaplan, H., Hedayat, K., Venna, N., Jones, P., and N.
Stratton, "An Extension to the Session Description
Protocol (SDP) and Real-time Transport Protocol (RTP) for
Media Loopback", RFC 6849, February 2013.
Martinsen, et al. Expires November 30, 2015 [Page 9]
Internet-Draft TURN Bandwidth Probe May 2015
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July
2013.
10.2. Informative References
[I-D.martinsen-tram-stuntrace]
Martinsen, P. and D. Wing, "STUN Traceroute", draft-
martinsen-tram-stuntrace-00 (work in progress), February
2015.
[I-D.petithuguenin-tram-stun-pmtud]
Petit-Huguenin, M., "Path MTU Discovery Using Session
Traversal Utilities for NAT (STUN)", draft-petithuguenin-
tram-stun-pmtud-00 (work in progress), January 2015.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Authors' Addresses
Paal-Erik Martinsen
Cisco Systems, Inc.
Philip Pedersens Vei 22
Lysaker, Akershus 1325
Norway
Email: palmarti@cisco.com
Trond Andersen
Cisco Systems, Inc.
Philip Pedersens Vei 22
Lysaker, Akershus 1325
Norway
Email: trondand@cisco.com
Martinsen, et al. Expires November 30, 2015 [Page 10]
Internet-Draft TURN Bandwidth Probe May 2015
Gonzalo Salgueiro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Email: gsalguei@cisco.com
Marc Petit-Huguenin
Impedance Mismatch
Email: marc@petit-huguenin.org
Martinsen, et al. Expires November 30, 2015 [Page 11]
