- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 12 Jun 2013 16:30:05 +0200
- 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