[tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to inface to lower level's QoS-stuff
"Karl Stahl" <karl.stahl@intertex.se> Wed, 26 February 2014 15:48 UTC
Return-Path: <karl.stahl@intertex.se>
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 076EC1A066E; Wed, 26 Feb 2014 07:48:08 -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 FIILXOMzJZY8; Wed, 26 Feb 2014 07:48:01 -0800 (PST)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A03741A01EF; Wed, 26 Feb 2014 07:47:59 -0800 (PST)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402261647536755; Wed, 26 Feb 2014 16:47:53 +0100
From: Karl Stahl <karl.stahl@intertex.se>
To: "'Yoakum, John H (John)'" <yoakum@avaya.com>, 'Oleg Moskalenko' <mom040267@gmail.com>, 'Alan Johnston' <alan.b.johnston@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> <CALDtMrKb3_38Rs0vaGnpEvNvTYz8YUTo89STvLJNXfkfdipDSQ@mail.gmail.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com>
In-Reply-To: <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com>
Date: Wed, 26 Feb 2014 16:47:50 +0100
Message-ID: <06f801cf330a$1aca7880$505f6980$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06F9_01CF3312.7C8EE080"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHPLmMlcJtLqkuUgEmVgUSRCLyaepq+efWAgARzPGA=
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/E6a6q4Yv6HOvn5JOawuzhIiywkg
Cc: rtcweb@ietf.org, tram@ietf.org
Subject: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to inface to lower level's QoS-stuff
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: Wed, 26 Feb 2014 15:48:08 -0000
(After having typed this up; I see todays charter discussion etc. that I havent read yet, but it will hopefully will be clearer by pointing at this entry.) Hi John, and Collin, Pål, Magnus, Charles, Simon, In my step A) B) and D) efforts in http://www.ietf.org/mail-archive/web/tram/current/msg00275.html for the mission to bring quality to real-time traffic over our best effort Internet is a huge mission, I am convinced it not a huge task We just have to be a bit clever here :). I only see these few standard steps required, before it can happen! To accomplish these (1), (2), (3)-things 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). There are a lot of Mission Impossible, Pointers, Good arguments and other things to consider in the mails from you guys that I have not (yet) answered. Allow me to come back to those under THIS THREAD/Subject after having figured out how to do it in a structured way, with the aim of collecting the summary in a new "Interfacing to QoS" thread, that only will relate to how IP/IETF/WebRTC level 3-5 *can interface* to the QoS-stuff (whether within IETF, in the telephony world or elsewhere e.g. IEEE Ethernet, mainly relating to lower level). I think this is doable *without* ending up in any of the (i), (ii), (iii)-things (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). (?) and possible other Evil -things. I refer to http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html for these -things and further. John, Alan, Henry (Sinnreich), Henning, Richard, Cullen, Jörgen (Björkner), Lars (Berggren) and other good friends since the early SIP age (before SIP was hijacked into application specific network and proprietary usage and nowadays rarely is used the IETF-way): I want to point out how confusing the QoS-issue has been and as hard as I will the fight Mission Impossible attitude, I will also fight the it is all about bandwidth and it will go away with time attitude (also in the above http reference) I agree with parts of what John says below but the remedy to achieve the Good (1), (2), (3)-things instead of the Evil (i), (ii), (iii)-things, is NOT to ignore QoS-things It is the opposite! For you having more and relevant input That has not been said, and that you think I will not address anyway in this "Interfacing to QoS" path, please provide, but I will not be able to process much more than already have been said and I will use http back-pointers for what has already been discussed in more detail. If you want to point out QoS-stuff Requiring More Input-from/Feedback-to the level 3 and above stuff IN ADDITION to what already has been discussed here http://www.ietf.org/mail-archive/web/tram/current/msg00302.html Please also point out WHAT and WHY that can/or cannot be handled by the methods proposed here and whether other existing methods can be used to achieve the mission of "Interfacing to QoS" from IP = level 3 to lower levels. I will do some thinking about what LISTs different things shall be brought to and then split the [TRAM] [WEBRTC] and advice regarding involving other list will be considered. Such will probably show up and happen during this mission. Another thing from http://www.ietf.org/mail-archive/web/tram/current/msg00275.html: What name Footnote **[Karl]* For similar reasons I have started to say things like the box containing the TURN server. We should not change the TURN server spec into including specific QoS methods to apply (like reservation, changing DSCP bits or applying traffic shaping mechanism). What is happening here is that we share the traffic information that the TURN server gets hold of, with a QoS applying function (that will be different for different networks) in the same box. With the same box I mean that we for now dont care about the interface/commands for sharing information between the TURN server and the QoS applying function. There may be a future need to specify/standardize this, but if we start doing that now and in TRAM, we risk ending up in a 10-year process before having something in place (which without a spec automatically will happen in vendors product development, by putting the TURN server into already available QoS applying function boxes (like firewalls or the mobile DPI/PCRF combination). *What we need to consider and specify, is only what traffic info is required (to be provided by the application/browser) for QoS applying functions in different networks (including the very common reservation types) to do job (i.e. giving us good QoE for real-time applications).* And Henry, I will have to continue to use the S(BC)-word and the I(MS)-word, since you did not succeed to eradicate them ;-) Lets hope we find a word for the above box (quite undefined on the QoS-side It is only the TURN side and traffic info we are up to designing here) that does not need to be eradicated. So no WebRTC-SBC I guess (hopefully it will not even be WebRTC-specific), and ICE-SBC sounds crazy (since ICE was developed to remove the need of SIP SBCs), the same applies to TURN-SBC (which implies that this box hopefully is not even ICE-specific). TURN-QoS-Interface box is relevant but long /Karl PS: To avoid being stopped by the to many recipients spam filter, the Guys (including Mary) from http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html and the ones mentioned in the email are copied separately. Från: Yoakum, John H (John) [mailto:yoakum@avaya.com] Skickat: den 20 februari 2014 19:56 Till: Oleg Moskalenko; Alan Johnston Kopia: Karl Stahl; tram@ietf.org Ämne: RE: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt +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 <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] Fwd: I-D Action: draft-thomson-tram-turn-b… Alan Johnston
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Alan Johnston
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Simon Perreault
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Simon Perreault
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Tirumaleswar Reddy (tireddy)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Pal Martinsen (palmarti)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Simon Perreault
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Tirumaleswar Reddy (tireddy)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Tirumaleswar Reddy (tireddy)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Karl Stahl
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Karl Stahl
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Alan Johnston
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Justin Uberti
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Yoakum, John H (John)
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Michael Hammer
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Oleg Moskalenko
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Michael Hammer
- Re: [tram] Fwd: I-D Action: draft-thomson-tram-tu… Paul Kyzivat
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Karl Stahl
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Pal Martinsen (palmarti)
- Re: [tram] I-D Action: draft-thomson-tram-turn-ba… Alan Johnston
- [tram] [RTCWEB] [TRAM] Protesting: Requesting TRA… Karl Stahl
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Pal Martinsen (palmarti)
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Karl Stahl
- [tram] A note from your (so far) friendly AD ... Spencer Dawkins
- Re: [tram] A note from your (so far) friendly AD … Justin Uberti
- Re: [tram] A note from your (so far) friendly AD … Mary Barnes
- Re: [tram] A note from your (so far) friendly AD … James Polk
- Re: [tram] A note from your (so far) friendly AD … Mary Barnes
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] [rtcweb] I-D Action: draft-thomson-tra… Cullen Jennings (fluffy)
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Barry Leiba
- Re: [tram] A note from your (so far) friendly AD … Gonzalo Camarillo
- [tram] BCP over TURN will not be in scope ... and… Spencer Dawkins
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Cullen Jennings (fluffy)
- Re: [tram] BCP over TURN will not be in scope ...… Cullen Jennings (fluffy)
- Re: [tram] BCP over TURN will not be in scope ...… Simon Perreault
- Re: [tram] BCP over TURN will not be in scope ...… Gonzalo Camarillo
- [tram] [rtcweb] The way to "Interfacing to QoS", … Karl Stahl
- Re: [tram] [rtcweb] The way to "Interfacing to Qo… Simon Perreault
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Karl Stahl
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Karl Stahl
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Gonzalo Camarillo
- Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting… Karl Stahl
- Re: [tram] [rtcweb] RTP header extension for "Int… Karl Stahl