Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

"Karl Stahl" <> Thu, 20 February 2014 13:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACB511A0162 for <>; Thu, 20 Feb 2014 05:36:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iQXo7_oO1u6L for <>; Thu, 20 Feb 2014 05:36:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 32FEF1A0163 for <>; Thu, 20 Feb 2014 05:36:36 -0800 (PST)
Received: from ([]) by (Telecom3 SMTP service) with ASMTP id 201402201436317120; Thu, 20 Feb 2014 14:36:31 +0100
From: "Karl Stahl" <>
To: "'Alan Johnston'" <>, <>
References: <> <>
In-Reply-To: <>
Date: Thu, 20 Feb 2014 14:36:30 +0100
Message-ID: <01af01cf2e40$c31ebd30$495c3790$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B0_01CF2E49.24E32530"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac8sHMJyCzQV1hQ5R5mBacy4UF3a0gB727Ng
Content-Language: sv
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Feb 2014 13:36:42 -0000

Hi Alan,


Can you comment/elaborate on the purpose and intended usage of this


I am not clear about how the negotiation of bandwidth between a TURN client
and a TURN server can be useful considering how bandwidth is shared on the
Internet today and the QoS/QoE implications of this.
On this mailing list, this draft has been discussed as useful for QoS/QoE
improvement, which I cannot see it is. For such purposes, richer information
than the total bandwidth needs to be conveyed to the TURN server / network,
compare e.g. DISCUSS/MALICE
In the Introduction of draft-thomson-tram-turn-bandwidth-00.txt:
   The operator of a TURN server will likely wish to provide fairness
   between relayed sessions.  A TURN server might also wish to limit the
   use of service to audio-only sessions, or low bandwidth video and
   audio sessions.  In addition, the server may apply rate-limiting
   policy depending on the credential used for authentication, or the
   origin of the client.  Without the BANDWIDTH attribute, there is no
   way for a client to indicate the expected bandwidth utilization, or
   for the server to indicate the maximum bandwidth utilization allowed
   before rate limiting could be applied.
I interpret that this draft is about conveying a “fairness policy” etc. to
the TURN server / network, without specifying how this could be realized or
implemented. Correct? More is needed for a possible the realization
considering QoS/QoE.
If richer information is needed for the realization, that may be the
attributes conveyed by DISCUSS/MALICE (but used for TURN, not STUN, see
discussion in previous email).
On the other hand, if the information conveyed here
(draft-thomson-tram-turn-bandwidth-00.txt) already is available (directly or
indirectly) in the DISCUSS attributes, maybe we could end up with a single
draft that includes the real-time traffic information and sharing policy
that needs to be conveyed to the TURN server / network? Is that something to
Or if recreating the payload type (PT) idea/intent in RTP packets (by now
conveying bandwidth and traffic type in the RTP extension header
<> is
sufficient for QoS/QoE in combination with auto-discussed TURN servers,
maybe draft-thomson-tram-turn-bandwidth-00.txt is the only thing we need in
addition (not the DISCUSS attributes).
For better understanding of these QoS/QoE problems, and methods for
improving (not specifically discussing the policies of sharing real-time
traffic space), I would like to explain:
Over an IP pipe only used for real-traffic (no TCP data traffic), it is
sufficient that the pipe is wide enough for good QoS. That is often used and
implemented by separating IP pipes at a lower level using e.g. Ethernet
VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can
enforce real-traffic into such pipes and QoS is achieved. Let’s call this
Level 2 QoS (Network level)
Over an IP pipe shared between quality requiring real-time traffic and less
demanding data or streaming (usually TCP) traffic, we have the sharing
between these two traffic classes to consider. The main method (and the
mechanism making today’s real-time QoE as good as it often is) is that TCP
endpoints back-off and share their bandwidth usage. Real-time traffic using
UDP transport do not back-off, the endpoints using UDP occupy the bandwidth
needed. When an IP pipe gets filled, it is all endpoint’s TCP bandwidth
usage that is back-off and shared between them, leaving room for the UDP
traffic. This is mechanism we experience everyday over the Internet, using
our “Surf IP pipes”. Let’s call this Level 4 QoS (Transport level)
However, this Level 4 QoS is based on that at congestion times (which happen
every time we click – setting up a TCP flow and transferring some amount of
data as quick as possible) the router handling the most narrow part of the
pipe (the congestion point) drop packets. It is this packet dropping that
(i) signals to TCP endpoints to reduce their bandwidth (via TCP’s error
correction/retransmission mechanism) and (ii) destroys the QoE of real-time
traffic. (Both TCP and UDP packets are dropped in this process that is
triggered by flow intensive TCP traffic.)
We need (i) but don’t want (ii) and to improve on this we can e.g. use
diffserve, DSCP bits in IP packets to instruct routers to always forward the
real-time traffic before any unmarked TCP traffic (which usually fills most
of the pipe). Then QoS is then achieved for real-time traffic. This is Level
3 QoS (IP level). The method used is “traffic shaping”: backing off data
traffic, leaving real-time traffic free passage without packet loss.
Here, in TRAM we want to go beyond Level 4 QoS (already available and
working as good as it can on the Internet), to give quality demanding WebRTC
real-time traffic better QoE by:
a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using
auto-discovered TURN servers) 

b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using
auto-discovered TURN servers). Here we must have traffic shaping mechanisms
working, and with correct and sufficient information to do the job. This is
why we in TRAM discuss DISCUSS/MALICE,
draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the
payload type (PT) idea/intent in RTP packets (by now conveying bandwidth and
traffic type in the RTP extension header

How these QoS/QoE things are done and used in practice is also
illustrated/exemplified in this email discussion: 
Prioritization of individual real-time packets (e.g. using diffserve DSCP
bits) have today little impact on the QoE, UNLESS a pipe full with only
real-time traffic (which is unusual), because in today’s IP pipes with high
bandwidth, packets are not stored for later delivery, but rather dropped by
routers implementing diffserve (after only a short time period = small
buffer size). The only good remedy is higher bandwidth, that can handle ALL
real-time traffic. 
Prioritization of real-time packets (any diffserve DSCP bits marking) “makes
QoS perfect”, when there are best effort (=no DSCP bits set) TCP (=non
real-time) traffic going over the IP pipe that can be pushed off. Routers
implementing diffserve do that.
Having gone through all of this, I want to point out that the huge mission
to bring quality to real-time traffic over our best effort Internet, is not
a question of huge investments in new bandwidth (that happens anyway for
data and streaming video needs) or about sharing bandwidth (bandwidth is
available in access if we only consider the real-time need). It is about
borrowing some already existing bandwidth from data usage. And there are
only unnoticeable consequences of this borrowing; A delay of a fraction of a
second or so for click-responses or watching a movie. So the huge mission,
may be a an easy task if we do it cleverly.
And finally, the purpose of this draft-thomson-tram-turn-bandwidth-00.txt
seems is related to how to request or buy or limit or pay for access to the
good real-time IP pipes for best QoE.
Isn’t that the case Alan, rather than intended to be used as QoS/QoE
improvement method (as it has been discussed).


Från: tram [] För Alan Johnston
Skickat: den 17 februari 2014 21:14
Ämne: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt




We have written a new I-D on a bandwidth attribute for TURN.  The use case
is to allow a TURN client to indicate to the server the bandwidth it expects
to use for the relayed candidate, or for a TURN server to indicate to the
client the maximum bandwidth before the TURN server might apply rate


Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which
was discussed in the past, but this draft does not propose an ICE use case
for consent.


Comments most welcome!


- Alan -

---------- Forwarded message ----------
From: <>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts

        Title           : A Bandwidth Attribute for TURN
        Authors         : Martin Thomson
                          Bernard Aboba
                          Alan Johnston
                          Oleg Moskalenko
        Filename        : draft-thomson-tram-turn-bandwidth-00.txt
        Pages           : 8
        Date            : 2014-02-13

   An attribute is defined for Session Traversal Utilities for NAT
   (STUN) that allows for declarations of bandwidth limits on the
   negotiated flow.  The application of this attribute is the
   negotiation of bandwidth between a Traversal Using Relays around NAT
   (TURN) client and a TURN server.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

I-D-Announce mailing list
Internet-Draft directories: