Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt
"Prashanth Patil (praspati)" <praspati@cisco.com> Tue, 20 May 2014 09:40 UTC
Return-Path: <praspati@cisco.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 71D281A04C8 for <tram@ietfa.amsl.com>; Tue, 20 May 2014 02:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 xNQFWk6NJxfu for <tram@ietfa.amsl.com>; Tue, 20 May 2014 02:40:27 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2497D1A05C3 for <tram@ietf.org>; Tue, 20 May 2014 02:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7474; q=dns/txt; s=iport; t=1400578826; x=1401788426; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XCp/FlRdmBGx1lJfhtXvNNpMtoyLrk316mq7Gmm6FIE=; b=lR8NflABK5ARdrMxyliUmH5C2/cyHZcqAo0nwuauaHqALi6NZXGPidxA Tvj6dmaoCHO72VXZI+o1eti75ZYcdXMO05k01uhL0Qu11G/V64caWtbOm Mkv9MeoTK/4GOPz/lwVX0xD67eti0MVg8wZUamKgk51lDbi/Zxv7WMPZC 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0NADoie1OtJV2T/2dsb2JhbABQCYMGUVEHqV4BAQEFAZJuhzsBgRkWdIIlAQEBBAEBAWoBCRICAQgYJwcnCxQRAgQTCYg4CAXSPheFVYNbhEMDBwEBHDUFhEAEiWCQAIE9kWCDOG2BAQkXIg
X-IronPort-AV: E=Sophos;i="4.98,873,1392163200"; d="scan'208";a="45422432"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 20 May 2014 09:40:22 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4K9eMCh011566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tram@ietf.org>; Tue, 20 May 2014 09:40:22 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.7]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 20 May 2014 04:40:22 -0500
From: "Prashanth Patil (praspati)" <praspati@cisco.com>
To: "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt
Thread-Index: AQHPc43I/cHap6Ml70mhGHdWVtbuyJtIej/ggAFtsIA=
Date: Tue, 20 May 2014 09:40:21 +0000
Message-ID: <CFA0F35D.3636D%praspati@cisco.com>
References: <CFA01C24.36103%praspati@cisco.com> <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se>
In-Reply-To: <069201cf73b1$948b5a80$bda20f80$@stahl@intertex.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [10.142.189.176]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9A88F96F7E8238448A0B0501751A60CF@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pvGFJBbzh4x-rG0OpZTsu8XvZUs
Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.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: Tue, 20 May 2014 09:40:29 -0000
On 5/20/14 3:57 AM, "Karl Stahl" <karl.stahl@intertex.se> wrote: >I read "We'll probably need both if we want to maximize chances of >discovery." in the draft also, but don't really get it. > >Do you mean that if the network provider offers one particular TURN server >to his network users, that TURN server should be advertised in both >suggested ways? By maximize, the draft really means discovering servers that may not support all discoverable methods. For example, if a provider already has TURN application service provisioned in DNS (as in RFC5928), it can be readily discovered without needing anycast. -Prashanth > >/Karl > >-----Ursprungligt meddelande----- >Från: tram [mailto:tram-bounces@ietf.org] För Prashanth Patil (praspati) >Skickat: den 19 maj 2014 20:12 >Till: Karl Stahl; tram@ietf.org; 'Simon Perreault' >Ämne: Re: [tram] New Version Notification for >draft-patil-tram-turn-serv-disc-01.txt > >Hi Karl, > >On 5/18/14 6:13 PM, "Karl Stahl" <karl.stahl@intertex.se> wrote: > >>I browsed through this document and to me it looks mature enough to be >>pushed forward (hopefully soon) to get an IANA anycast address etc., so >>these things can be put into current WebRTC browsers. As we know, many >>enterprises cannot use WebRTC at all today due to their restrictive >>firewall policies - they need a TURN server on their LAN, discovered >>and used by the WebRTC browsers to even begin using WebRTC. >> >>However, I raised a few questions and some suggestions >>http://www.ietf.org/mail-archive/web/tram/current/msg00480.html >>at the end of the previous version of this draft that never became >>discussed and remain: >> >>A) Under 8.2 there is a suggested way to assure that the TURN server >>returned by the anycast method, is provided by the network provider >>(and not some far away TURN server that should not be trusted to use >>without authentication): "... can set an IP TTL on their TURN requests >>that limits how far they can travel into the public Internet." >> >>I suggest that this TTL limitation is specified (e.g. Don't look >>further than 3 steps - local firewall + max 2 ISP routers) and brought >>into section "5. Discovery using Anycast" of the draft. > >I think the decision should be left up to the application. We could, >maybe, >make a recommendation at best (i.e. it is not a MUST). > > >> >>B) Shall we really have more than one method? If the Anycast method can >>be used by everyone, why then also have DHCP and now a two more methods? > >There are essentially 2 methods described in the draft (1) Service >resolution and (2) Anycast. We'll probably need both if we want to >maximize >chances of discovery. >DHCP happens to be one method to obtain the domain-name for (1) Service >resolution. While the DHCP method may not workable in some cases, the >other >two methods (one of them inspired by draft-kist-alto-3pdisc) could offer >better results. We can do away with DHCP, if that is the WG consensus. > > >> >>I assume you intend that all webrtc browsers implement and can use all >>methods? Or? (If a service provider e.g. deploys DHCP discovered TURN >>servers, but some webrtc browser in some operating system don't >>find/cannot use the TURN server, it would be bad.) >> >>In previous discussions, there were some fears that DHCP options are >>not available in some common OSs. If so, I think the DHCP method should >>be skipped. >> >>Also, if the other methods (other than anycast) may fail, why have them? > >Anycast may fail, too. > > >> >>Are they better to deploy and provision for network service providers? >> >>And will webrtc browsers implement all these methods? >> >>Do we have input/feedback on these questions? >> >>Should the "connect speed factor" not also be considered? Even though >>the auto discovery can be done in advance of a call, we should consider >>the mobility use case. With a mobile client changing network, >>LAN/LTE/public WiFi etc., we want to get up and run as soon as >>possible, so the auto discovery of a new TURN server should not be a >>tedious process >> >>And should the quick anycast auto discovery not be the first to be >>tried/used (which it is not now in the draft)? > >Given that there is a service resolution mechanism for TURN over DTLS >(http://tools.ietf.org/html/draft-ietf-tram-stun-dtls-02#page-6), it seems >useful to do service resolution before. > >> >>C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery >>is now RFC7216. > >Thanks, will update. > >-Prashanth > > >> >>/Karl >> >> >>-----Ursprungligt meddelande----- >>Från: tram [mailto:tram-bounces@ietf.org] För Prashanth Patil >>(praspati) >>Skickat: den 2 maj 2014 12:02 >>Till: tram@ietf.org >>Ämne: [tram] FW: New Version Notification for >>draft-patil-tram-turn-serv-disc-01.txt >> >>A new revision of the TURN server discovery draft has been published. >>Notable updates : >> >>* 300 (Try Alternate) response for anycast. >>* Mechanism described in draft-kist-alto-3pdisc i.e. using the clients >>own address to populate the DNS reverse zone (i.e., in-addr.arpa or >>ip6.arpa) with appropriate NAPTR records pointing to the TURN server. >>* Learning domain names from own identity. >> >>-Prashanth >> >> >>On 5/2/14 3:25 PM, "internet-drafts@ietf.org" >><internet-drafts@ietf.org> >>wrote: >> >>> >>>A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt >>>has been successfully submitted by Prashanth Patil and posted to the >>>IETF repository. >>> >>>Name: draft-patil-tram-turn-serv-disc >>>Revision: 01 >>>Title: TURN Server Auto Discovery >>>Document date: 2014-05-02 >>>Group: Individual Submission >>>Pages: 11 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-01 >>>.tx >>>t >>>Status: >>>https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/ >>>Htmlized: >>>http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01 >>>Diff: >>>http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01 >>> >>>Abstract: >>> Current Traversal Using Relays around NAT (TURN) server discovery >>> mechanisms are relatively static and limited to explicit >>> configuration. These are usually under the administrative control of >>> the application or TURN service provider, and not the enterprise or >>> the ISP, the network in which the client is located. Enterprises and >>> ISPs wishing to provide their own TURN servers need auto discovery >>> mechanisms that a TURN client could use with no or minimal >>> configuration. This document describes two such mechanisms for TURN >>> server discovery. >>> >>> >>> >>> >>> >>>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. >>> >>>The IETF Secretariat >>> >> >>_______________________________________________ >>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 mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram
- [tram] FW: New Version Notification for draft-pat… Prashanth Patil (praspati)
- Re: [tram] FW: New Version Notification for draft… Paul Kyzivat
- Re: [tram] FW: New Version Notification for draft… Prashanth Patil (praspati)
- Re: [tram] FW: New Version Notification for draft… Paul Kyzivat
- Re: [tram] FW: New Version Notification for draft… Simon Perreault
- Re: [tram] New Version Notification for draft-pat… Karl Stahl
- Re: [tram] New Version Notification for draft-pat… Brandon Williams
- Re: [tram] New Version Notification for draft-pat… Karl Stahl
- Re: [tram] New Version Notification for draft-pat… Brandon Williams
- Re: [tram] New Version Notification for draft-pat… Prashanth Patil (praspati)
- Re: [tram] New Version Notification for draft-pat… Karl Stahl
- Re: [tram] New Version Notification for draft-pat… Tirumaleswar Reddy (tireddy)
- Re: [tram] New Version Notification for draft-pat… Prashanth Patil (praspati)
- Re: [tram] New Version Notification for draft-pat… Karl Stahl
- Re: [tram] New Version Notification for draft-pat… Karl Stahl
- Re: [tram] New Version Notification for draft-pat… Tirumaleswar Reddy (tireddy)
- Re: [tram] New Version Notification for draft-pat… Karl Stahl
- Re: [tram] New Version Notification for draft-pat… Tirumaleswar Reddy (tireddy)