Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

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

> -----Original Message-----
> From: Karl Stahl [mailto:[e-mail]]
> Sent: Thursday, February 13, 2014 5:06 PM
> To: Tirumaleswar Reddy (tireddy); 'Simon Perreault'; [e-mail];
> [e-mail]
> Subject: SV: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
> 
> I checked Malice=discussed and just commented in previous response
> 
> But we need to ENFORCE paths adviced/offered by the enterprise and/or
> NSP/ISP to be used (to cope with the problems).
> 
> Do you see an alternate way/method of doing that, not using TURN?

Yes, http://tools.ietf.org/search/draft-penno-pcp-mobile-qos-00 explains how P2P media streams can be identified and differentiated QoS services can be provided by the ISP without forcing WebRTC client to only advertise relayed candidates.

-Tiru.

> 
> /Karl
> 
> -----Ursprungligt meddelande-----
> Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> Skickat: den 12 februari 2014 08:01
> Till: Karl Stahl; 'Simon Perreault'; [e-mail]; [e-mail]
> Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
> 
> Hi Karl,
> 
> Yes, there is a problem but P2P WebRTC streams (both media and data
> channels) can be identified and QoS can be provided by the access network
> without forcing TURN to be used. You may want to look into PCP FLOWDATA
> (http://tools.ietf.org/html/draft-wing-pcp-flowdata-00), MALICE
> (http://tools.ietf.org/html/draft-martinsen-mmusic-malice-00).
> 
> -Tiru.
> 
> > -----Original Message-----
> > From: Karl Stahl [mailto:[e-mail]]
> > Sent: Wednesday, February 12, 2014 12:47 AM
> > To: Tirumaleswar Reddy (tireddy); 'Simon Perreault'; [e-mail];
> > [e-mail]
> > Subject: SV: [tram] Milestone 3: TURN server auto-discovery mechanism
> > for enterprise and ISPs
> >
> > Tireddy wrote below > There are various ways to prioritize WebRTC
> > media streams and I don't see a need to block P2P connectivity.
> >
> > --- We need not only to think about prioritizing WebRTC, it is about
> > "traffic shaping also".
> > - If we consider the case of WebRTC traffic over Internet/mobile OTT
> > (not talking about feeding WebRTC into some application specific
> > network like IMS where they may be other quality measures), we get
> > lost quality wise already when (if) we allow prioritized WebRTC
> > traffic to go into a congestion point (like a NAT/firewall or default
> > gateway, where there may be heavy data traffic already filling the pipe.
> > - Quality loss here (lost WebRTC media packets) cannot be recovered
> > later
> > - That is the "need to block P2P connectivity" (which may sound ugly
> > but is really about assuring that we CAN get P2P connectivity with
> > best quality, with help of service providers and LAN administrators
> > that want WebRTC traffic to be good and accessible...)
> >
> > --- Or do see another/better way around this that I cannot see?
> >
> > -----Ursprungligt meddelande-----
> > Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> > Skickat: den 11 februari 2014 03:40
> > Till: Karl Stahl; 'Simon Perreault'; [e-mail]; [e-mail]
> > Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for
> > enterprise and ISPs
> >
> > > The only way we found around this, was to stop STUN through the IP
> > > default gateway (like a restrictive Enterprise firewall does
> > > inhibiting ICE connectivity, which others are concerned about...).
> > > Since the provisioning of auto- discovery using the anycast
> > > mechanism, would be adding a route in a default gateway, adding a
> > > firewall rule to eat STUN packets would assure that the provisioned
> > > TURN server actually becomes used (and not bypassed "by accident").
> > > (That was the thought behind the “automatically” within quotes.)
> >
> > There are various ways to prioritize WebRTC media streams and I don't
> > see a need to block P2P connectivity.
> > --- We need not only to think about prioritizing WebRTC, it is about
> > "traffic shaping also".
> > - If we consider the case of WebRTC traffic over Internet/mobile OTT
> > (not talking about feeding WebRTC into some application specific
> > network like IMS where they may be other quality measures), we get
> > lost quality wise already when (if) we allow prioritized WebRTC
> > traffic to go into a congestion point (like a NAT/firewall or default
> > gateway, where there may be heavy data traffic already filling the pipe.
> > - Quality loss here (lost WebRTC media packets) cannot be recovered
> > later
> > - That is the "need to block P2P connectivity" (which may sound ugly
> > but is really about assuring that we CAN get P2P connectivity with
> > best quality, with help of service providers and LAN administrators
> > that want WebRTC traffic to be good and accessible...)
> >
> > --- Or do see another/better way around this that I cannot see?
> >
> >  Using TURN server itself endpoint can learn server-reflexive
> > candidates. If there is a restrictive firewall that blocks P2P
> > connectivity then relayed candidate would eventually be nominated
> > because ICE connectivity check fails with other candidate types.
> >
> > I don't see any need to advertise only relayed candidates in the
> > offer/answer other than for privacy reasons.
> >
> > -Tiru.
> >
> > > -----Original Message-----
> > > From: tram [mailto:[e-mail]] On Behalf Of Karl Stahl
> > > Sent: Tuesday, February 11, 2014 4:48 AM
> > > To: 'Simon Perreault'; [e-mail]; [e-mail]
> > > Subject: Re: [tram] Milestone 3: TURN server auto-discovery
> > > mechanism for enterprise and ISPs
> > >
> > > Simon,
> > >
> > > Good questions - see inline below --> .
> > > Some more thought is required!
> > >
> > > /Karl
> > >
> > > -----Ursprungligt meddelande-----
> > > Från: tram [mailto:[e-mail]] För Simon Perreault
> > > Skickat: den 10 februari 2014 15:16
> > > Till: Karl Stahl; [e-mail]; [e-mail]
> > > Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism
> > > for enterprise and ISPs
> > >
> > > Karl,
> > >
> > > It is great to see such enthusiasm! Thanks!
> > >
> > > I have a couple technical questions...
> > >
> > > Le 2014-02-08 08:11, Karl Stahl a écrit :
> > > > - Note that to achieve some of the above points, TURN must be
> > > > favored over STUN to enforce that the TURN-path actually is used.
> > > > (The Anycast method suggested below, “automatically” does this.)
> > >
> > > I understand the STUN vs TURN priority issue. But I don't see how
> > > anycast affects it in any way. Can you please explain?
> > >
> > > --- Good point - I was a bit quick here (maybe too quick) We have
> > > given this quite bit of thought, since even if a TURN server is
> > > provided and discovered, CURRENT usage of ICE may suggest a
> > > candidate from the remote party that will make a connection without
> > > the need/usage of the TURN server (that we wanted to be used for the
> > > good
> > purposes listed).
> > >
> > > The only way we found around this, was to stop STUN through the IP
> > > default gateway (like a restrictive Enterprise firewall does
> > > inhibiting ICE connectivity, which others are concerned about...).
> > > Since the provisioning of auto- discovery using the anycast
> > > mechanism, would be adding a route in a default gateway, adding a
> > > firewall rule to eat STUN packets would assure that the provisioned
> > > TURN server actually becomes used (and not bypassed "by accident").
> > > (That was the thought behind the “automatically” within quotes.)
> > >
> > > BUT, since you brought up the question, assuming that we have the
> > > power to enforce WebRTC usage of ICE, I believe a MUST requirement
> > > to use an auto- discovered TURN server instead of STUN, would solve
> > > the
> > same problem.
> > > However, thinking further (in relation to your next question -
> > > "anyone could set up a badly-maintained" - enforcing such ICE usage
> > > may not be
> > > good.)
> > >
> > >
> > > > - 3^rd The Anycast method below – I see no problem
> > > >
> > > > It also has the advantage of encouraging (but not requiring) the
> > > > STUN/TURN to be built in the default gateway or
> > > > NAT/firewall/access router itself, with a second interface to a
> > > > public IP address on the WAN side. (Current volume deployed, low
> > > > cost NSP triple play modems usually have a quality assured level 2
> > > > or level 3 WAN pipe for just voice (and another for IPTV) – The
> > > > anycast discovered TURN-server can be the access gateway to such
> > > > quality pipe for WebRTC media, in a single NSP provided CPE,
> > > > scaling from residential and up.)
> > >
> > > Suppose we define well-known anycast TURN server addresses. How
> > > would this not be subject to the same service quality issues that
> > > plagued 6to4? That is, anyone could set up a badly-maintained,
> > > under-provisioned TURN server and announce it over BGP to the world,
> > > as it was done for
> > > 6to4 relays. Or just bad BGP outbound filter configuration. And how
> > > can we prevent triangle routing? There is nothing guaranteeing that
> > > the anycast server you see is being provided to you by your ISP,
> > > rather than a server sitting on the other side of the planet.
> > >
> > > --- Good point - needs to be resolved. For this I don't have a ready
> > answer...
> > > An auto-discovered TURN server must be trusted (whatever method it
> > > is discovered by). We are trusting the one providing us with an IP
> > > address and default gateway anyway. It would be easy if we could
> > > reuse that trust, instead of another mechanisms.
> > >
> > > Is there a good way for the browser to check that the anycast
> > > address is not handled beyond the network service provider's default
> gateway?
> > Ideas?
> > >
> > >
> > >
> > > 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
> > > _______________________________________________
> > > tram mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tram
> > >
> > > _______________________________________________
> > > tram mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tram
>