From Cacheboy

Redirection via DNS

DNS redirection is pretty simple - for each request of a "magic" record, perform some kind of mapping, and return the mapping result.

The shortcomings are also pretty simple and well understood:

• DNS TTL isn't guaranteed;
• The mapping is done on the IP of the resolver, which is not always going to return the same set of mapping possibilities that the client itself would

The interesting question to answer is determining which percentage of client requests end up at a server which was -not- the "best" selection as per the mapping functions.

Redirection via BGP

BGP redirection is generally known as "Anycast".

A DNS record maps to an IP address whose announced network prefix is announced at a variety of locations around the world. The request is then redirected to a server (or group of servers) at each POP which listen on that IP address.

Anycast based services exploit the nature of BGP "best path" determination to find the POP which is closest to the user. The ISPs get to determine what is "closest" to them via traditional BGP methods.

The problem is that a topology change will suddenly make packets for established sessions appear at a different POP.

The interesting questions to answer:

• does this happen enough in practice for it to be noticable?
• .. the above, but graphed across a variety of request and traffic types (UDP DNS request/replies? TCP DNS request/replies? Small HTTP objects? Not so small ones?)
• Can state be distributed enough between nodes to allow larger objects to continue being served after a topology change?

One may combine DNS based redirection with anycast based discovery - ie, run the DNS service on an anycast subnet, direct clients trying to resolve the mirror node DNS entry to the "local" servers without involving any kind of GeoIP or BGP topology information. (In this case BGP topology information is used by the -network- to route the DNS request to the "closest" POP; but the DNS server itself doesn't use BGP to make the decision as to whats the "closest" server for that client.)

HTTP Redirection

Another method of redirection involves simply sending a 30x response back with the "better" location of said content to the client.

The CDN can then use various combinations of origin server, DNS and BGP Anycast based redirection for the initial assignment; and then the mirror nodes can further refine the traffic by redirecting to a closer mirror node.

HTTP redirections can "fine-tune" the (currently unknown to this project!) percentage of requests which have been mis-classified by the BGP method.

The problems here include extra processing time (ie, a new TCP connection and HTTP request/reply) - which may not matter for larger objects - and the possibility that the user-agent just won't handle the redirect and will try again. Yes, I've seen this occur with mozilla/firefox updates. More to come with that when it is deployed on the Cacheboy CDN.

(more to come..)