Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
"Karl Stahl" <karl.stahl@intertex.se> Mon, 17 February 2014 11:51 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 8212F1A047A for <tram@ietfa.amsl.com>; Mon, 17 Feb 2014 03:51:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Level:
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 x94SfJz9gx2j for <tram@ietfa.amsl.com>; Mon, 17 Feb 2014 03:51:48 -0800 (PST)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id E5EF91A0493 for <tram@ietf.org>; Mon, 17 Feb 2014 03:51:44 -0800 (PST)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402171251392493; Mon, 17 Feb 2014 12:51:39 +0100
From: Karl Stahl <karl.stahl@intertex.se>
To: "'Pal Martinsen (palmarti)'" <palmarti@cisco.com>, tram@ietf.org
References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <CAOJ7v-27jSO3j4v5H3Dz6+pL=TxNaT8y2Gc9Q2iTPmqwpabUsA@mail.gmail.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <CAOJ7v-1MwEejzK_zFtEFsZZP4AYcGm=-aWPWRJvOaHpf3iH3qw@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE2243DA8E0@xmb-rcd-x02.cisco.com> <CALDtMrLxfn3aJDbo=yeNTzhXk1mhFYbvtaKMCFCWi0gpyoA8ew@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE2243DAB7D@xmb-rcd-x02.cisco.com> <CAOJ7v-0Ma67W--5SrddvQbHSzjDvPsbrDTVTVt-aAE43eNWz_w@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> <913383AAA69FF945B8F946018B75898A242AD1F4@xmb-rcd-x10.cisco.com> <52FCD3E3.5060301@viagenie.ca> <54984825-37D2-4C21-A0CF-F03C6D30162D@cisco. com>
In-Reply-To: <54984825-37D2-4C21-A0CF-F03C6D30162D@cisco.com>
Date: Mon, 17 Feb 2014 12:51:39 +0100
Message-ID: <03c401cf2bd6$9e5e9c70$db1bd550$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHPJ7mlTNEKdEV/S06oVknK3f+v9pqxnjCAgAABbgCAAB7xgIAAizSAgAAdCoCAAIjhgIAAsgGAgAAGhYCABacXgA==
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6gIY-3jerW0F8DRWyvKcdEfuOE8
Cc: 'Simon Perreault' <simon.perreault@viagenie.ca>
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
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: Mon, 17 Feb 2014 11:51:51 -0000
Interesting thoughts, inline comments below --> -----Ursprungligt meddelande----- Från: tram [mailto:tram-bounces@ietf.org] För Pal Martinsen (palmarti) Skickat: den 13 februari 2014 15:40 Till: tram@ietf.org Kopia: Simon Perreault Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs On 13 Feb 2014, at 15:17 pm, Simon Perreault <simon.perreault@viagenie.ca> wrote: > Le 2014-02-12 22:40, Tirumaleswar Reddy (tireddy) a écrit : >> There are other ways to solve the problem for example using PCP. > > True. > >> Can you clarify how deploying a TURN server in the Enterprise >> protects the users and the network ? > > IMHO that's not the right question to ask. It is pretty clear to me > that, technically, TURN does indeed have the potential to solve the > problem identified by Karl. (I understand the problem to be: "ISP > wants to provide enhanced QoS to WebRTC.") > > I have two questions in my mind: > > a) Is this a real problem that is worth fixing? Yes.. But not just QoS. There should be some kind fairness and share the resources so everyone can get the best result. If the link is getting crowed it would be nice of the endpoint than can would for example reduce its bandwidth by dropping from 1080p to 720p. Tis have some impact on user experience, but uses half the bandwidth. [Karl] Have you noticed that Google does this in Chrome/VP8 already? When getting bad network conditions (you see disturbances in the video), the video screen shrinks to reduce bandwidth usage. That is "some kind fairness and share the resources" intent, but unfortunately not very effective, since the bandwidth reduction in practice is given back to TCP (non-real time traffic) streams filling the pipe. That is the way TCP (data) vs. UDP (media) today share the Internet pipes (UDP makes TCP streams reduce their bandwidth usage at congestion time - and that is also reversed when reducing UDP) by backing off TCP. That is why we need to be able to apply "traffic shaping" at lower network levels. I would like us to move away from hard reservations as that does not give us the best usage of a scarce resource (bandwidth) as video codecs are very elastic in its nature and it would be hard to know how much bandwidth to allocate for a video stream. [Karl] True! But i might be dreaming. [Karl] Are you? :) I will comment further/elsewhere on the DISCUSS/MALICE draft, which I see related to this > b) Is TURN the best, most appropriate solution? > Probably a part of the solution, It is a nice way of forcing media through a certain path. But I think that path only should be chosen by the endpoint if that is the best(*1) path. (*1) For certain values of best.. [Karl] Agree, but the path to be chosen by the endpoint, can only be advised/offered by the ISP/NSP if it is within their network the quality fixes have to be done. I have been planning to write a draft: POLICE, Path Optimisation done Locally with ICE. But that probably belongs to MMUSIC. But to get that of the ground we need to figure out how to get more information from the network regarding bandwidth, cost and other decisions that might influence the path selection. (RTT we get from the connectivity checks). That would be something for the TRAM WG to figure out.. (And maybe the PCP WG) [Karl] Yes, and I see DISCUSS/MALICE (that has been mentioned by Justin and others here) as one step to do this. Another thing to remember is that webRTC is probably going to use Trickle-ICE. In clear that means the host candidates will be tested as soon as they are ready. The rest of the candidate discovery might happen in parallel or after. This might affect how we discover the available TURN servers. [Karl] There must be some recommendation of such ICE usage, to ensure that the quality path (if available) is chosen - Yes! Due to security concerns the webRTC also severely limits the speed the connectivity checks happen. So unless Trickle ICE is in use it is good to keep the number o candidates to a minimum. [Karl] Enforcing a specific TURN-path, will reduce the number of candidates, so maybe Tickle-ICE does not even have to be used, when there are a an ISP/NSP adviced/offered TURN servers to use .-. Pål-Erik > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > 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
- [tram] Milestone 3: TURN server auto-discovery me… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- [tram] Milestone 3: TURN server auto-discovery me… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Dan Wing
- Re: [tram] Milestone 3: TURN server auto-discover… Marc Blanchet
- Re: [tram] Milestone 3: TURN server auto-discover… Dan Wing
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Oleg Moskalenko
- Re: [tram] Milestone 3: TURN server auto-discover… Pal Martinsen (palmarti)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- [tram] IMPORTANT CLARIFICATIONS: Milestone 3: TUR… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Pal Martinsen (palmarti)
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] IMPORTANT CLARIFICATIONS: Milestone 3:… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- [tram] QoS for RTC over the Internet, DISCUSS: Mi… Karl Stahl
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Simon Perreault
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Pal Martinsen (palmarti)
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Karl Stahl