Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: tram [mailto:[e-mail]] On Behalf Of Karl Stahl
> Sent: Tuesday, May 20, 2014 3:58 AM
> To: Prashanth Patil (praspati); [e-mail]; 'Simon Perreault'
> Subject: Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-
> 01.txt
> 
> 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.

With Secure DHCPv6 with Public Key http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02, DHCP has benefits over Anycast.
But since DHCP is not workable in some cases, clients may end-up using both the techniques (for e.g. use happy-eyeball mechanism) and give precedence to TURN server learnt using secure DHCP.

> 
> 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?

Yes

-Tiru

> 
> /Karl
> 
> -----Ursprungligt meddelande-----
> Från: tram [mailto:[e-mail]] För Prashanth Patil (praspati)
> Skickat: den 19 maj 2014 20:12
> Till: Karl Stahl; [e-mail]; '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" <[e-mail]> 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:[e-mail]] För Prashanth Patil
> >(praspati)
> >Skickat: den 2 maj 2014 12:02
> >Till: [e-mail]
> >Ä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, "[e-mail]"
> ><[e-mail]>
> >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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/tram
> >
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram