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

Justin Uberti <juberti@google.com> Thu, 20 February 2014 17:30 UTC

Return-Path: <juberti@google.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 915C31A0209 for <tram@ietfa.amsl.com>; Thu, 20 Feb 2014 09:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level:
X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 zxGxskEtMx7Z for <tram@ietfa.amsl.com>; Thu, 20 Feb 2014 09:30:53 -0800 (PST)
Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F3B971A0227 for <tram@ietf.org>; Thu, 20 Feb 2014 09:30:51 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id lf12so2190882vcb.3 for <tram@ietf.org>; Thu, 20 Feb 2014 09:30:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=01bEgWTIBn2xnWPiac8ZMwedUYkCx7CHKu/UOzkiiaI=; b=AEkIqDePI/SAW85amnI+EsHDLAGT9Dd462l0ZlrgpZgOAg+ZY9W0B2IOfTkCzP8fdM w94ObugIn0J4pFURyasV2WEij5KfwMUoyLc8J0g5V+vTC/bx1guLvqgr5hiR/OtoCTtd iVAo8dLRJl+/pjXK8PvHP7rBjlf/JrfbqcQG/9tBZvw/5EZcjSrUF5aR5/WROD7byK8o esz1CJq1Wvj9n4GdWcJmOCdCuoe7xmDRkNpbzKlOUQ+x9Kfk42x0bQi/R10tcKGzJCYH c/dt2i3o/r/OmffPzHPMr0eAqZk2NTfF+bLK1wCN90O7wCzUB6ycMLyEPDfeCBhNT7K3 OmAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=01bEgWTIBn2xnWPiac8ZMwedUYkCx7CHKu/UOzkiiaI=; b=BNO2bHrNo6GDvwwY0EFHq+L4a9GVNoW+k+1raMNMdhJOrJLD8SRFFN0DjMMoAb+m23 6Ej1sXD0eM+sHnc35JS2Ns75pJ05PFMGIJVS88CekACrHBcygGvlNqtZ1IarJx0wM6Jl tdzFXjBR+NdmqEhL/6DtRmOhCpdgWibJuT6jFOOJNML1uShVuWsad4TWbG5TeLTmpV1l bbe6LMqndUCvsdgjBN0S3u2uhSRcVUMPNMxBS9IT7kKZIPMSElVmiXnVhVZlsM5jCV71 9D+kv/ub0jVxbw8tOnF6PRDauKXdgjhmRIKzsBis88zpFtcJOEZWbCOX1X6SnGhq3DmS a9pg==
X-Gm-Message-State: ALoCoQlitZGZo1593YfM7g4u8pHaDgHFPK48SCfH79DIObeYZSdg0PH8GJfTitneq4+ODuxFPiv24sc73GvdojVZhGyshC0eo1sWdoQcTgvw229xk2yCPnTITTIlktBB9A6fsqt+zi1lmtqphmK2pVjK0K5NeuNJ9gfhej97k6EKtbWalsNNTeogRzmJfJ8y7asgbv7cIl0/
X-Received: by 10.220.50.18 with SMTP id x18mr1709235vcf.66.1392917447886; Thu, 20 Feb 2014 09:30:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.89.170 with HTTP; Thu, 20 Feb 2014 09:30:27 -0800 (PST)
In-Reply-To: <CAKhHsXGsp6ma6Ko9op+YFRqSGM_Ex-jFo_fjz69rN0SEHfNK2A@mail.gmail.com>
References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <CAKhHsXGzA=ZTFGTK7ht9hQbfG70iqKrDtxrZCdQNNMzBYZCk8A@mail.gmail.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <CAKhHsXGsp6ma6Ko9op+YFRqSGM_Ex-jFo_fjz69rN0SEHfNK2A@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 20 Feb 2014 09:30:27 -0800
Message-ID: <CAOJ7v-0fZ9ZWDoVaOb6QaexDe4i69SKwEErHeuP-0f1-BCRf2Q@mail.gmail.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b34427aaeee9a04f2d9ddbe"
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/M2u0aVD25N6C1V2NLha6jJpa2sQ
Cc: Karl Stahl <karl.stahl@intertex.se>, "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 17:30:56 -0000

QoS does not even appear in the TRAM charter:
https://datatracker.ietf.org/doc/charter-ietf-tram/

While some of the pieces we are building may be useful for QoS, it is not
an explicit goal of this WG, and I would prefer to focus on the concrete
milestones that have already been identified.


On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com>wrote:

> 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
>>
>>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>