Experimental Results

We present the results for the experiments conducted on the 44 node topology for the BGP-ANYCAST simulations. The topology has 34 clients and 10 Anycast server nodes. Of the 10 Anycast servers, 9 are located in North America and 1 in Europe. All servers are configured as “global nodes”. Of the 34 clients, 22 are located in North America and rest in Europe and Asia. Normally, we would see clients exhibiting regional affinity – i.e., clients in North America would be served by servers in North America and so on. However, due the limited number of ASes considered in the current topology, we find that clients in North America (especially the ones located in Western and Central parts of North America) are serviced by the Anycast server in Europe. The converse also happens to be true – clients in Russia were observed to be serviced by servers in North America.

We divided the simulations into 3 categories : One with no failures ; One with link down failures ; and one with prefix withdrawals. In these initial set of experiments, we created single failures and created them around the Europe Anycast server, as that server received maximum number of requests. For the explicit withdraw case we saw a very quick convergence, as the graph is quite strongly connected (the 44 nodes are connected with 467 links, which is around the halfway mark to being fully connected). For the link down case, we brought just one of the links that the AS shares with another AS (which seemed to on the preferred path) was brought down. However, as the simulation is randomized w.r.t. starting time of BGP nodes, different best paths were selected in each run of the simulation and hence, we did not see downtime in all cases.

Each simulation experiment was run for a total of 2000 seconds. For the withdraw case, the prefix was withdrawn at 800th second of the simulation and not re-advertised after that. For the linkdown case, the link was brought down at the 677th fo the simulation. (The times for the failure were chosen quite randomly.) For each case, the simulation was repeated 50 times. We measured mean response times, % of requests received by Anycast servers etc., as discussed further.

Mean Number of responses received from each Anycast server:

The following graph shows the mean number of requests received by (or responses received from) each of the Anycast servers. We see that for the explicit withdraw case, the requests are distributed to other nodes after the failure. The same does not strongly hold for the linkdown case.

Percentage of responses

The following graph shows the percentage of responses received from the Anycast servers. The distribution is quite similar to the Mean response graph above.

Geographic distribution

The following graph shows the geographic distribution of the responses from servers. The graph shows mean responses received by clients from the Anycast servers in a region.

The linkdown case does not show much change from the No Failure case, as only one link was down and the clients could still reach the server through other links.

Flips

We measured the flips that the clients observed during the failure cases. However, since we started clients when the network was in a steady state and also, since only one failure was simulated, affected clients showed only one flip. We expect to have interesting results for this case when more failures are simulated.

Future work

The main points of focus for the future are:

1. Reasonably modeling multiple network failures. A few studies have shown that few paths in the internet tend to be prone to frequent failures ( the 80-20 rule applies : 80% of the failures occur in 20% of the links). We plan to simulate such failures and in addition to reported measurements, we would like to measure flips observed by clients, network churn ( in terms of number of bgp updates sent etc.)
2. Support for hierarchy. Support both global and local nodes and observe the amount of traffic that is absorbed by the local nodes in failure and no-failure cases.
3. Expand to a larger network. The current topology is quite strongly connected and is not quite representative of the Internet. We plan to include tier-2 and tier-3 service providers in the topology for a richer, realistic topology.