This is the third in a series of posts (part 1 here, part 2 here) about new features we’re releasing to our voice stack in the very near future.

What makes Simwood unique and very distinct from others who buy a magic VoIP box from a vendor is that our service is built on the best of open-source and the best of black boxes where necessary, all pulled together with our secret sauce. It is also deployed (inter)nationally on our own network. By the time “me too” gets a tick box they don’t understand on their magic black box, our customers will be several further innovations further on. Why? Because we exist to put new communications technology in the hands of your customers, and help you enrich their lives. Let’s leave “me too” to compete with yesterday, while we make today the best it can be!

This is a huge topic that we cannot cover in just one blog post so we’re going to cover off the basics here and then revisit it in other contexts. It will also form the basis of Simon’s speaking engagements at various industry events this year. In short order: the Simwood network is now anycast enabled and this brings great benefits. However, as we’re not aware of anyone else in the world any-casting SIP it will be released as a beta option in our new stack and we’d love your feedback.

What is Anycast?

There are various different flavours of -cast in networking terms but the one you’ll be most familiar with is undoubtedly Unicast. With unicast, one IP address exists in one place and routers routing tables show the available paths to that single IP address. If that IP address ceases to be available, it will be unreachable until the service is repaired or another host adopts that IP address. Furthermore, the path to that IP address from a given client will be whatever it happens to be, i.e. the IP address is geostationary and if it happens to be the other side of the world, your packet will need to go half way round the world to get to it.

Anycast, by contrast, puts the same IP address is many places. At each stage of a packet’s journey, the router has multiple ways to reach multiple different instances of the same IP address, but is blissfully unaware that the IP address exists in different instances. By applying its default behaviour of routing based on the shortest path to the destination, the result is that the packet will be delivered to the instance that is closest in topological terms. The difference between unicast and anycast is best illustrated in a diagram:

Anycast can be applied both globally (i.e. outside our own network) and locally (i.e. within the network) and there are different benefits in each case. We’re doing both but let us explore just global anycast for now – local anycast is equally exciting but not relevant here.

Global anycast

You may be most familiar with this from DNS. If you use Google’s 8.8.8.8 DNS server or any of the OpenDNS ones, you will be experiencing anycast. In fact the majority of the Internet’s root servers themselves are anycasted. The result is, when you perform a DNS lookup, the response comes from the closest server and thus as quickly as possible. Furthermore, the failure of an instance is a non-event as your requests will be routed to the next closest one. Likewise, if a new instance is added that happens to be closer, it is seamlessly used with no reconfiguration. Thus, from the end-user’s perspective, the service is highly (highly generally = always) available and very performant.

Now DNS is the best use case for anycast and it is no surprise it found early adoption there. The problem is routes can change so anycast works best for stateless applications, a single question and a single answer being perfect. A long session where the route could change mid-way would be undesirable as it would either break or require engineering at the application level to handle the effective failover.

HTTP is a bad use case for anycast in theory as it uses TCP so connections need to be negotiation and maintained for as long as a transaction takes. If a route changes mid-way through a download, that download will fail. In practice, anycast is being widely used in HTTP too and has been for some time. In practice route changes have been found to have negligible impact. As such many CDNs and technically led companies such as LinkedIn have used anycast for HTTP for some time.

We’ve put together a simple demo of anycast on the Simwood network at http://anycast-demo.simwood.com – you should find you hit the city that is most appropriate in network terms for you and do so pretty consistently. At the time of writing, this is only deployed in Slough and Manchester but we’ll be adding other sites in. You will find routing to them just happens if they become more appropriate. There’s no DNS voodoo here; it’ll work the same even if you prefer to use IP addresses!

Anycasted SIP

But what about SIP? Well, a SIP call can run on for considerably longer than a download – hours for some calls – so the impact of route changes could be more pronounced and the consequences of breaking a call mid-way are more severe than a missing image on a web-page. However, SIP would greatly benefit from the benefits anycast can deliver for a number of reasons:

• Despite our best efforts, there is some aversion to using hostnames when configuring SIP equipment. Many customers ignore our pleas to use hostnames, and part of the reason is that magic box vendors make it impossible to do so. This undermines the ability to use DNS for failover or load-balancing. Anycast would fix this.
• Those who do use hostnames might not do so appropriately. Take for example a customer in Manchester routing calls to our equipment in Slough. This might make sense if we only peer with his ISP in Slough, but as we enable peering with them in Manchester and that becomes the more relevant site, are they likely to reconfigure? Anycast would ensure traffic entered at the closest site without any config change.
• SIP is nomadic. If I have a trunk configured on my softphone in the UK, but hop off a plane in the US I don’t expect to reconfigure. I could enjoy the ghastly experience the mobile operators enforce (i.e. all voice and data backhauled to the UK) but wouldn’t it be great if service could roam too? Anycast sorts that – I just connect to the local proxy without touching anything.
• SIP needs to be always available and the techniques for doing so at the various points from end-user equipment can be pretty dirty. Anycast potentially fixes that.

We’re pleased to say we believe we’ve got global anycast working reliably for SIP and it is awesome! Our intention is to add an anycast address which customers can use to route calls or simply for optimum node discovery. We know it works at the network layer, and we know we’re compliant with RFCs but that doesn’t mean customer equipment is so it needs real-world testing. If we can identify and mitigate further gotchas we can make SIP truly highly available and your customers can enjoy low latency access with minimum scope for their calls to be affected. Of course, your own equipment in the path may stand in the way, but if you map your end users directly to Simwood and use our API to administrate them, they’ll get the benefit of anycast in due course. If you want them to enjoy that anywhere, we might just have an app coming for that.

***

This is a great example of our network being a strategic asset that can make a difference to your end-users’ communication experience. “Me too” can’t yet procure an anycasted magic box and even if they could, do they have or can they configure a network to deploy it on? Recent outages due to fundamentals suggest not.

By contrast, “Virtual carriers” try to turn their absence of a network and complete derogation of responsibility for your customer’s media into a selling point. They’ll try telling you that given your customer in Manchester calling their Aunty in Amsterdam, them passing the call through a carrier in Singapore and you having to send the media directly there is a benefit to you! Wrong, it means they make margin for doing virtually nothing and your customer’s audio travels halfway round the world with them having zero control or responsibility for it. You have no control either and you don’t know from one call to the next which far-flung part of the world the call will traverse and over which networks.

Neither of those are acceptable to us and we think these anycast developments will really shine a light on how our network delivers value to your customers.