Anycast, not just a fancy name
The need to be able to anycast network traffic goes back a long time, having been identified in RFCs (Request For Comment) such as RFC1546:
The word “anycast” is a portmanteau, it’s composed of “any” and “cast”, playing on older network concepts like “unicast” and “broadcast”. Unicast refers to sending data from a single (“uni”) sender to a single remote receiver (“cast”), while broadcast refers to receiving data sent from a single sender to a large number of receivers.
In the case where there are multiple receivers, anycast is similar, where data is sent from a single sender to its single geographically closest receiver.
How anycast works in the modern Internet
The Internet is a network of networks, where each individual network is identified by a unique number, called an ASN (Autonomous System Number). ASN numbers are coordinated by the world’s RIR (Regional Internet Registries), such as ARIN (American Registry for Internet Numbers).
Internet routing is how traffic moves from one ASN to another, for instance, from your ISP (Internet Service Provider) to a virtual host sitting in one of Amazon’s data centers.
It’s mediated by a routing protocol called BGP (Border Gateway Protocol). One of BGP’s jobs is to pick a single route to a destination even if multiple routes are possible. The exact logic chain is complex, but roughly speaking, the shortest path is usually the one chosen.
A clever anycast provider now knows that if the provider places a PoP (Point Of Presence) immediately adjacent to all ISPs (also known as “peering”), then it will always have the shortest possible path between any ISP and itself. So it will always be chosen over any other path, making sure the Sender’s traffic is always sent to the geographically closest receiver.
In practice, this works even without direct peering, but it becomes a little more challenging to configure. An intermediary peer (such as a commercial transit) can be configured to prefer sending traffic to a specified destination via its internal networking protocol, so the same anycast effect can be achieved.
Who uses anycast anyway?
Anycast is in very common use throughout the Internet. Many CDNs (Content Delivery Network) utilize anycast to make sure that anyone who downloads content always downloads from the geographically closest server to them. This ensures speed and fast downloads, since the further away a content server is, the longer it takes to deliver that content.
Video delivery will also utilize anycast to ensure that the load of video delivery is split across multiple servers, with local delivery solely from local servers.
Many DNS (Domain Name Service) providers operate large anycast networks, because anycast can guarantee high availability. If a local server goes down, it is automatically removed from service, and the next-geographically-closest server receives the request.
Anycast resiliency -- Redundancy
Under anycast, if a server behind an anycast provider fails, the provider can remove the route to that server. The provider announces this route removal to all upstream ASNs, causing their BGP instances to reconverge to a new state without that route. Since there are multiple paths still available, BGP chooses the next-geographically-closest route to send traffic, and that next-geographically-closest server now receives traffic from the sender.
Security- DDoS attacks under anycast
A DDoS (Distributed Denial of Service) attack consists of a large number of senders, each individually sending a small amount of traffic but collectively sending a huge amount of traffic to a remote receiver, causing that receiver to become overwhelmed and unable to respond anymore.
Under anycast, natural load balancing occurs and these senders are sent instead to their geographically-closest receivers. This prevents the attackers from being able to direct all their resources to only one server, preventing them from sending enough traffic to overwhelm the entire service.
Subspace approach to anycast
Security - DDoS is actually mitigated
Under Subspace’s approach to anycast, each attacker must send traffic first to their geographically closest Subspace PoP. This allows Subspace to mitigate the attack itself directly by scrubbing traffic at that PoP, leaving the remote server unaffected and still able to respond to the legitimate traffic Subspace will let through.
Updating physical paths without breaking connections
Subspace has improved anycast’s resiliency. Under normal anycast, if a server fails, and the route to it is withdrawn from BGP, then BGP will reconverge to the next-geographically closest server. This next server lacks any context about the pre-existing connection, causing a reset and requiring the client to establish a new connection.
In the rare event of a Subspace PoP failure, all Subspace PoPs share network state information with each other, so a PoP failure cannot stop even a pre-existing connection. Instead, the moment a PoP fails and its BGP announcements are withdrawn, BGP reconverges to send traffic to the next-geographically closest PoP as expected. That PoP, however, since it already knows the appropriate IP and port and forwarding information, accepts the next packet in the stream, and forwards it on appropriately. So it is as though there was only a brief pause in the connection stream.
Subspace anycast implementation simplifies configuration
Subspace operates as a large, global proxy. By offering a unique anycast IP address and port for every customer’s application, the end user’s connection will traverse Subspace instead of the general Internet. By design, Subspace PoPs are everywhere the end users are, so no matter where in the world they may be, Subspace has a PoP close to them. This obviously minimizes latency between when an end user sends a packet and when that packet enters Subspace. Keeping the end user so close to Subspace reduces key round trip time compared to that same end user using the Internet to communicate with a server.
All this while not requiring the customer’s application to do anything more than talk to that single unique anycast IP and port.
Subspace allows for multiple virtual anycast networks to operate separately
Subspace can assign each customer application its own unique anycast IP address and port, and do so dynamically. These IPs and ports can be created, removed, or updated on-the-fly either via the Subspace console or else programmatically via the Subspace API. It’s entirely possible to dedicate one anycast IP and port for a development environment, while creating a second one solely for use by the production environment, or any other purpose.
PacketAccelerator Advantages
Any latency sensitive Internet-based application can benefit from sending its traffic over Subspace via PacketAccelerator. Traffic is bi-directional, it flows over Subspace both to and from a paired client and server. Utilizing Subspace, not only is the latency between any end user and a Subspace PoP minimized, but the travel time across the Subspace internal network is less than the general Internet, often substantially so. Traffic also exits the Subspace internal network at a Subspace PoP geographically closest to the server, once again minimizing latencies and maximizing reliability.
Subspace built a custom SDN (Software Defined Network) to handle loss and jitter in real time, guaranteeing a higher reliability and more stable performance than the general Internet can provide. This SDN will dynamically change its internal route based on latency, jitter, and loss metrics in near-real-time to ensure that a packet which enters Subspace exits Subspace at its desired destination in the shortest period of time.
Want to start building on PacketAccelerator today? Sign up here.
