Traversal Using Relays around NAT (TURN) Bandwidth ProbeCisco Systems, Inc.Philip Pedersens Vei 221325LysakerAkershusNorwaypalmarti@cisco.comCisco Systems, Inc.Philip Pedersens Vei 221325LysakerAkershusNorwaytrondand@cisco.comCisco Systems, Inc.7200-12 Kit Creek RoadResearch Triangle ParkNC27709USgsalguei@cisco.comImpedance Mismatchmarc@petit-huguenin.orgTRAM
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.
When Interactive Connectivity Establishment (ICE) and Traversal Using Relays around NAT (TURN)
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) Session Description Protocol
(SDP) offer/answer exchange ) . The endpoint will also learn its reflexive
address on the firewall/NAT when talking to the
TURN server.
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.
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 .
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.
The agent allocates a TURN Relay port on its designated TURN
server as described in TURN RFC . 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.
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
) and can be added to the
Session Traversal Utilities for NAT (STUN) probe packets. The PADDING attribute from
the NAT Behavior Discovery Using STUN RFC can be used to vary the packet size.
Discovering the MTU and network path (using the STUN-PMTUD
and STUN
Traceroute
mechanisms) can also be performed when probing for the bandwidth
available between the client and the TURN server.
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).
Allocate TURN RELAY address Set correct permissions on the allocated TURN RELAY
address 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 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.
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.
The client allocates a TURN RELAY port as described in
TURN Extensions for TCP Allocations . 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.
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.
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 ) to simplify measurement
of round-trip time (RTT) and available bandwidth. A
PADDING attribute is already defined in RFC 5780 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 loop-back mechanism
described in RFC 6849 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.
This specification defines a new STUN attribute. IANA added
this new attribute to the STUN Attributes sub-registry of
the Session Traversal Utilities for NAT (STUN) Parameters
registry. (This is still an ID draft so not assignment yet)
This STUN extension defines the following new attribute:
The TIMESTAMP attribute has a length of 80 bits. Padding
is needed to hit the required 32 bit STUN attribute
boundary.
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.
[[Note to RFC Editor: Please remove this section and the
reference to 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 . 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 , "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"
Cisco Cisco Collaboration Endpoints (CE)
software Hard video endpoint part of the
Cisco collaboration portfolio In released products Implementation of base
procedures of the functionality described in this
specification Proprietary Straight forward,
but implementation was don prior to writing up the spec Paal-Erik Martinsen (palmarti@cisco.com)
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 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 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.
Thanks to Dan Wing for input.