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

["Karl Stahl" <[e-mail]>]

I think the draft should elaborate some around these (and Tiru's) thoughts
of having multiple methods.

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[e-mail]] För Prashanth Patil (praspati)
Skickat: den 20 maj 2014 11:40
Till: [e-mail]
Ämne: Re: [tram] New Version Notification for
draft-patil-tram-turn-serv-disc-01.txt



On 5/20/14 3:57 AM, "Karl Stahl" <[e-mail]> 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:[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-0
>>>1
>>>.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

_______________________________________________
tram mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tram