Subject: [tram] TURN server discovery (please discuss!)

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Mar 2014 09:51:23 -0400

Tramsters,

During the meeting in London there was a mixed reaction to the
presentation of draft-patil-tram-turn-serv-disc-00. We heard very few
hums both for and against adoption.

As a reminder, here is the related milestone:

Sep 2014 - Send new TURN server discovery mechanism for enterprises and
ISPs to IESG for publication as Proposed Standard

I'd like people to respond to this email explaining their position
regarding the presented solution. Why do you (not) support it? What is
missing? What would be a good solution in your opinion? It seems we did
not have time to fully discuss those questions face-to-face, so let's do
it here.

Basically, the draft proposes two mechanisms: DHCP and anycast. We know
each of these solutions has drawbacks which were well discussed. The
question is: are they deal breakers, or could we live with them?

WPAD was also discussed. The main issue seems to be that WPAD is not
really standardized anywhere. IMHO this issue can be worked around if
the solution is good technically. So, how is it technically? Would it
work? What are the drawbacks? I don't think this has been discussed enough.

Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc for
inspiration. As I understand it, that solution relies on the client's IP
address "owner" (e.g. the ISP or enterprise) to populate the DNS reverse
zone (i.e., in-addr.arpa or ip6.arpa) with appropriate NAPTR records
pointing to the network-provided TURN server. Can this work? This is a
new idea for which I have not seen any discussion yet.

Let's solve this!

Thanks,
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

---

From: Cb B <[email-masked]>
Date: Thu, 20 Mar 2014 07:08:00 -0700

> new idea for which I have not seen any discussion yet.

Just adding a data point, mobile networks generally don't use dhcp so that
limits the scope of dhcp as an option.

I anticipate mobile networks will need TURN.

CB
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Mar 2014 10:44:58 -0400

I made a suggestion back in february:

http://www.ietf.org/mail-archive/web/tram/current/msg00156.html

IMO there are important use cases for that, and it is worth mentioning.

	Thanks,
	Paul

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 20 Mar 2014 14:48:02 +0000

>question is: are they deal breakers, or could we live with them?

The first mechanism is actually Service Resolution. The draft suggests
DHCP as the primary means to obtain a domain name which can be used for
service resolution. There was a suggestion that domain name could also be
extracted from own SIP/XMPP/email identity
(http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)- which
we plan to add to the draft in the next version.

-Prashanth

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 20 Mar 2014 14:48:45 +0000

Just adding a data point, mobile networks generally don't use dhcp so that limits the scope of dhcp as an option.

CB
[TR]

we had discussed similar problem to discover PCP servers in Mobile Networks (http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-04#section-4) sometime back. Based on the discussion
1)DHCPv6 stateless configuration information is supported by 3GPP specification (http://tools.ietf.org/html/rfc6459#section-5.2)

2)Since DHCPv4 is not widely used, possible solutions discussed to solve the problem are anycast, enhancing PCO to provide TURN {PCP} server IP address

-Tiru

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Mar 2014 16:03:18 +0100

> I anticipate mobile networks will need TURN.
While DHCP is working fine for devices like IP phones, it will not work for applications running in an operating system. I don't know how to discover DHCP options from an app - is there an API for that?

/O

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Mar 2014 11:29:56 -0400

Le 2014-03-20 10:48, Prashanth Patil (praspati) a écrit :
> There was a suggestion that domain name could also be

But that doesn't work because it would be an application-provided TURN
server. We need to discover network-provided TURN servers.

Simon

---

From: Cb B <[email-masked]>
Date: Thu, 20 Mar 2014 10:19:05 -0700

On Mar 20, 2014 7:48 AM, "Tirumaleswar Reddy (tireddy)" <[email-masked]>
wrote:
>
> Just adding a data point, mobile networks generally don't use dhcp so
that limits the scope of dhcp as an option.
> we had discussed similar problem to discover PCP servers in Mobile
Networks (
http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-04#section-4)
sometime back. Based on the discussion
>
> 1)DHCPv6 stateless configuration information is supported by 3GPP
specification (http://tools.ietf.org/html/rfc6459#section-5.2)
>
> 2)Since DHCPv4 is not widely used, possible solutions discussed to solve
the problem are anycast, enhancing PCO to provide TURN {PCP} server IP
address
> -Tiru

I dont know any deployed mobile network where those will work today.

Today with IMS in mobile networks, NAPTR is used in DNS, so in would
suggest that as a viable path

CB

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 21 Mar 2014 07:32:32 +0000

>server. We need to discover network-provided TURN servers.

Sure, but should we not provide a means for discovering those? Maybe
suggest that this should be attempted only if the client is not able to
discover a network-provided server. The network provided server is
probably closer, so attempt to discover that first.

How to prioritize if a client discovers more than one TURN server is
another discussions altogether.

-Prashanth

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Mar 2014 08:54:46 -0400

Le 2014-03-21 03:32, Prashanth Patil (praspati) a écrit :
> Sure, but should we not provide a means for discovering those?

The point is that those means already exist.

> Maybe

Right. But IMHO prioritization is an easy problem compared with the
actual discovery.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 22 Mar 2014 06:20:39 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Friday, March 21, 2014 6:25 PM
> To: Prashanth Patil (praspati); [email-masked]
> Subject: Re: [tram] TURN server discovery (please discuss!)
> 
> >>> There was a suggestion that domain name could also be extracted from
> >>> own SIP/XMPP/email identity
> >>> (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)-
> >>> which we plan to add to the draft in the next version.
> >>
> >> But that doesn't work because it would be an application-provided
> >> TURN server. We need to discover network-provided TURN servers.
> >
> > suggest that this should be attempted only if the client is not able
> > to discover a network-provided server. The network provided server is
> Right. But IMHO prioritization is an easy problem compared with the actual
> discovery.

Prioritization of TURN server may also involve various parameters like path characteristics (RTT, loss etc.), features provided by the TURN server (let's say with or without Mobility using TURN),  
trust with the TURN server etc.

-Tiru

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Mar 2014 09:58:57 -0700

Re: WPAD:  This is causing HTTPBIS considerable pain.  If you feel
particularly masochistic, or desperate, then perhaps it can be
remembered, but any attempt to use WPAD will be sorely regretted.

> new idea for which I have not seen any discussion yet.

ALTO have been covering a lot of the same ground as GEOPRIV.
draft-ietf-geopriv-res-gw-lis-discovery sits in the RFC editor's
queue.  It's the same mechanism.

That said, this is only useful to the extent that the owner of the
network you are using is also the one providing the TURN service.  Is
this the operating assumption here?  Or are there other avenues that
need to be explored?

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Mar 2014 13:07:01 -0400

> remembered, but any attempt to use WPAD will be sorely regretted.

Duly noted.

> queue.  It's the same mechanism.

Thanks for the pointer!

> network you are using is also the one providing the TURN service.

Couldn't the NAPTR record point to a third-party TURN server?

> Is this the operating assumption here?  Or are there other avenues that
> need to be explored?

Maybe, but I can't think of any.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Mar 2014 10:12:29 -0700

> Couldn't the NAPTR record point to a third-party TURN server?

That's definitely the case, though the network operator still assumes
a critical responsibility for the service (namely: discovery).

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 31 Mar 2014 08:49:51 +0200

Two comments inline below /Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Simon Perreault
Skickat: den 24 mars 2014 18:07
Till: Martin Thomson
Kopia: [email-masked]
Ämne: Re: [tram] TURN server discovery (please discuss!)

Duly noted.

[Karl] And an ISP can hardly provision WPAD, can he?

>> Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc 
>> for inspiration. As I understand it, that solution relies on the 
>> client's IP address "owner" (e.g. the ISP or enterprise) to populate 
>> the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) with 
>> appropriate NAPTR records pointing to the network-provided TURN 
>> server. Can this work? This is a new idea for which I have not seen any discussion yet.

[Karl] Doesn't all reverse DNS lookup methods require that the browser finds its global ip address to begin with - for which you need a stun server? That is the bootstrap problem (how do you find a stun server to find the turn server) where the October discussion on the rtcweb terminated such track.

Thanks for the pointer!

> Is this the operating assumption here?  Or are there other avenues 
> that need to be explored?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 31 Mar 2014 09:38:44 -0400

> [Karl] And an ISP can hardly provision WPAD, can he?

Right, WPAD would not work for an ISP.

> [Karl] Doesn't all reverse DNS lookup methods require that the browser finds its global ip address to begin with - for which you need a stun server? That is the bootstrap problem (how do you find a…

This provides some inspiration:

http://tools.ietf.org/html/draft-ietf-geopriv-res-gw-lis-discovery-08#section-4.1

I suppose that the browser-default or application-provided STUN server
could be used for bootstrapping.

Simon