W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Anycast (Re: Allowing RTCIceServer to contain multiple URLs)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 12 Jun 2013 16:30:05 +0200
Message-ID: <51B885ED.6010605@alvestrand.no>
To: public-webrtc@w3.org
On 06/07/2013 01:11 PM, Cullen Jennings (fluffy) wrote:
>>   
>> Related to this - for a web scale deployment, I'd do it much like google does DNS and have all the TURN servers have the same IP address so it can be cached for a long time then use any cast to get to the geographically close TURN server.
>>
>> Hmm... Anycast really isn't guaranteed to be stable over this kind of time
>> scale.
> Fair enough - that's always the issue brought up.  Actually anycast isn't guaranteed to be stable over any time so very implementation dependent what happens.
>
I think address -> server binding needs to be stable (ie it's likely to 
cause disruption at failover) for TURN servers. For STUN servers, there 
should be no problem; it's stateless, just like DNS.

That said - the true nature of the Internet (not what it says on the 
label) is that the kind of instability that causes your anycast to 
retarget will also cause enough disruption to make ICE failover kick in 
(that is, the process will NOT be seamless). So TURN server retargeting 
might work just fine - it'll be handled exactly the same way as a TURN 
server reboot, and thus, IP-level anycast may be an acceptable solution.

But this is far over in IETF and operational-deployment land. At the 
API, we just need to make sure we can pass the parameters needed by the 
DNS-based mechanisms we want to give access to.
Received on Wednesday, 12 June 2013 14:30:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC