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

Alan Johnston <alan.b.johnston@gmail.com> Thu, 20 February 2014 14:26 UTC

Return-Path: <alan.b.johnston@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A421A018C for <tram@ietfa.amsl.com>; Thu, 20 Feb 2014 06:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5gg1ulvUozJ for <tram@ietfa.amsl.com>; Thu, 20 Feb 2014 06:26:24 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CE1A019D for <tram@ietf.org>; Thu, 20 Feb 2014 06:26:23 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id a1so1476174wgh.34 for <tram@ietf.org>; Thu, 20 Feb 2014 06:26:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AvSvyk6J4M1aXRfPrEOeY2Yp6aUAKBNNaLERV7wyWOY=; b=RUuSMF8V0KPjtjBCJpoenXZ4THnVorO5V27VszXQYTZvJ1R01ku2SrR1Upp08+S1uz iKmsqghIr08ABy60u2dxbABFiX3aD+AbY0dQGLFtwA3OALbVIoLGpXKWt1nOYhSGM6QA 6RsX61Z7rhI6K1ducP9+jQ1cp3uwmWwIDTlKMqkFh0ANc+reAToff6XLLtP6coryER2h T3iCCFaio0LuIccgs7wkQo7ZNOMWpnLUHdXjEiW89RAkJXm9AkCcvRFMUurejzGi0nod pJOhlr8KHzOtObA9GFkn0Rsttm3ECcQBQWCrf/w7EUl+AhdNumcBx07IcdDqRic5VgV2 Rgyg==
MIME-Version: 1.0
X-Received: by 10.194.185.165 with SMTP id fd5mr2183420wjc.95.1392906378505; Thu, 20 Feb 2014 06:26:18 -0800 (PST)
Received: by 10.217.152.10 with HTTP; Thu, 20 Feb 2014 06:26:18 -0800 (PST)
In-Reply-To: <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com>
References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <CAKhHsXGzA=ZTFGTK7ht9hQbfG70iqKrDtxrZCdQNNMzBYZCk8A@mail.gmail.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com>
Date: Thu, 20 Feb 2014 08:26:18 -0600
Message-ID: <CAKhHsXGsp6ma6Ko9op+YFRqSGM_Ex-jFo_fjz69rN0SEHfNK2A@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Karl Stahl <karl.stahl@intertex.se>
Content-Type: multipart/alternative; boundary="047d7bdc7e2ae5727304f2d749e3"
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/qpZuPBFwtauqhGEhYu_e16ThJ34
Cc: "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
X-BeenThere: tram@ietf.org
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Feb 2014 14:26:31 -0000

Hi Karl,

Thanks for your comments and feedback on the draft.

You are correct in saying that the BANDWIDTH extension is not about QoS.
 It is about fairness between users of a TURN server, and a TURN server
being able to indicate rate limiting policy to users.

Personally, I am not sure how much QoS is actually in scope for TRAM. Have
you been following RMCAT where congestion avoidance for RTP is being
developed?  I see some overlap in your goals and the goals of that work.

- Alan -

On Thu, Feb 20, 2014 at 7:36 AM, Karl Stahl <karl.stahl@intertex.se> wrote:

> 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.
>
>
>
> 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 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.
>
>
>
> 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
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>