Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
"Karl Stahl" <karl.stahl@intertex.se> Tue, 25 February 2014 00:20 UTC
Return-Path: <karl.stahl@intertex.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494B61A02D8; Mon, 24 Feb 2014 16:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.801
X-Spam-Level: *
X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no
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 2Yac5EBfSkH2; Mon, 24 Feb 2014 16:20:38 -0800 (PST)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 71AD11A0334; Mon, 24 Feb 2014 16:20:36 -0800 (PST)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250120330129; Tue, 25 Feb 2014 01:20:33 +0100
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Alan Johnston' <alan.b.johnston@gmail.com>, rtcweb@ietf.org, tram@ietf.org, 'Bernard Aboba' <bernard_aboba@hotmail.com>, 'David Singer' <singer@apple.com>, 'Harald Alvestrand' <harald@alvestrand.no>
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> <CALDtMrKb3_38Rs0vaGnpEvNvTYz8YUTo89STvLJNXfkfdipDSQ@mail.gmail.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <B7FA2629-6D48-4569-BB62-56395C3EE4BC@cisco.com> <CAKhHsXFYZXV38K-DfPsmg1XWSk4gK2kRyCHC6N-k-UOovDyrUA@mail.gmail.com>
In-Reply-To: <CAKhHsXFYZXV38K-DfPsmg1XWSk4gK2kRyCHC6N-k-UOovDyrUA@mail.gmail.com>
Date: Tue, 25 Feb 2014 01:20:30 +0100
Message-ID: <050401cf31bf$64ae8ff0$2e0bafd0$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0505_01CF31C7.C672F7F0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac8vLpOyXxkwjXJURauBPg8ftk+5EwBhXIDA
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Std_6_TuPFzv2J4yYcOb9ZU-mDg
X-Mailman-Approved-At: Tue, 25 Feb 2014 00:00:28 -0800
Cc: "'Cullen Jennings (fluffy)'" <fluffy@cisco.com>, marc.robins@sipforum.org, eburger@standardstrack.com, mary.barnes@polycom.com, 'Henning Schulzrinne' <hgs@cs.columbia.edu>
Subject: Re: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 00:20:42 -0000
Hi Alan, I have in previous email http://www.ietf.org/mail-archive/web/tram/current/msg00304.html suggested that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken off the TRAM WG, but I think is shall be reintroduced after you clarify as you do in http://www.ietf.org/mail-archive/web/tram/current/msg00300.html : 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. in the draft. The confusion (to say least, see below) surrounding QoS within IETF has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with the advise in http://www.ietf.org/mail-archive/web/tram/current/msg00304.html : The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether IETF standard work in these WGs by contributors having an interest in more than one of current or emerging: ISPs, carrier equipment vendors or web browser makers, may discriminate any with an interest only in one of these. The same should apply to non-activity by WG contributors to remedy such discrimination opened by allowed proprietary usage of RFCs such as RFC 5285. This is because the introduction of the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectives of TRAM, immediately would allow for: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now possible, for (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), under *all* OSs, and *all* current and future IP networks (3) *without* having to be forced into application specific networks (PSTN, IMS) instead of the Internet (including OTT). While the confusion surrounding the QoS discussion in TRAM and RTCWEB combined with the general QoS attitude within IETF it is all about bandwidth and it will go away with time otherwise: (i) will *not allow* ISPs to use already available and currently deployable quality IP pipes for real-time traffic to also be used for WebRTC generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the very common and used method of simply providing an extra IP pipe (often provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by browsers. (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes intermittently are filled, whatever bandwidth is available). As Good doers, we should not allow this to happen. /Karl Från: Alan Johnston [mailto:alan.b.johnston@gmail.com] Skickat: den 21 februari 2014 18:59 Till: Pal Martinsen (palmarti) Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; Yoakum, John H (John) Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt I guess the way I would expect this to progress is for QoS discussions to happen in another working group. Once that other working group came to consensus on an approach, and if that approach required STUN or TURN extensions, then we would discuss mechanisms and possible milestones in TRAM. - Alan - On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote: Hi, I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on the wire format discussions. .-. Pål-Erik On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) < <mailto:yoakum@avaya.com> yoakum@avaya.com> wrote: +1 I fully agree with the comments that QOS should be a low priority for the initial focus of the TRAM efforts. There are other groups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. Significant focus on QOS before we better enable TURN to be easily used in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. Cheers, John AVAYA 1.919.425.8446 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < <mailto:alan.b.johnston@gmail.com> alan.b.johnston@gmail.com> wrote: 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. - I'd concentrate on the TURN application-level functionality, for now, and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram
- Re: [rtcweb] [tram] I-D Action: draft-thomson-tra… Karl Stahl
- [rtcweb] [RTCWEB] [TRAM] Protesting: Requesting T… Karl Stahl
- Re: [rtcweb] [tram] I-D Action: draft-thomson-tra… Karl Stahl
- Re: [rtcweb] [tram] I-D Action: draft-thomson-tra… Pal Martinsen (palmarti)
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Cullen Jennings (fluffy)
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Cullen Jennings (fluffy)
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Cullen Jennings (fluffy)
- Re: [rtcweb] [tram] I-D Action: draft-thomson-tra… Cullen Jennings (fluffy)
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Barry Leiba
- [rtcweb] BCP over TURN will not be in scope ... a… Spencer Dawkins
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Cullen Jennings (fluffy)
- Re: [rtcweb] BCP over TURN will not be in scope .… Cullen Jennings (fluffy)
- [rtcweb] [tram] The way to "Interfacing to QoS", … Karl Stahl
- Re: [rtcweb] BCP over TURN will not be in scope .… Gonzalo Camarillo
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Karl Stahl
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Karl Stahl
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Gonzalo Camarillo
- Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: R… Karl Stahl
- Re: [rtcweb] [tram] RTP header extension for "Int… Karl Stahl