Hi Alan,

 

Can you comment/elaborate on the purpose and intended usage of this
draft-thomson-tram-turn-bandwidth-00.txt?

 

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
<http://tools.ietf.org/html/draft-martinsen-tram-discuss-00>
http://tools.ietf.org/html/draft-martinsen-tram-discuss-00.
 
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
consider?
 
Or if recreating the payload type (PT) idea/intent in RTP packets (by now
conveying bandwidth and traffic type in the RTP extension header
<http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html 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) 
or

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
<http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html.

 
How these QoS/QoE things are done and used in practice is also
illustrated/exemplified in this email discussion:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html 
 
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).
 
/Karl
 
 

 

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

 

All,

 

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
limiting.

 

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: <internet-drafts@ietf.org>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce@ietf.org



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


        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

Abstract:
   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:
https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft> 
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt