Why do you use a CDN?

Portal Home > Knowledgebase > Articles Database > Why do you use a CDN?

Posted by DNSShawn, 01-04-2011, 08:54 PM
If your goal is to push the content closer to the end user then shouldn't you also push the DNS closer to end user?
Posted by funkywizard, 01-04-2011, 09:27 PM
yes DNSShawn, that sounds like a great idea! What kind of DNS based solutions do you have for us, DNSShawn?
Posted by DNSShawn, 01-04-2011, 09:28 PM
You said it, not me
Posted by plumsauce, 01-04-2011, 11:33 PM
Sounds like a great idea, at first blush ... until you figure out its completely masked anyways. Where's that popcorn icon again?
Posted by funkywizard, 01-05-2011, 12:18 AM
masked? FWIW, my original post was a joke, but in all seriousness anycast dns in general is a good way to improve site performance.
Posted by arisythila, 01-05-2011, 12:30 AM
Shawn, DNS doesnt matter. I would keep diversity, DNS in multiple physical locations, but I dont think that a user is going to experience problems because name servers are located in NY opposed to Seattle if they are coming in from seattle.
Posted by plumsauce, 01-05-2011, 12:57 AM
FWIW, popcorn = joke as well But, by masked, I mean that once the amortisation effects of the intervening isp resolver cache is taken into account, a +/- 30ms difference in the response time of a authoritative name server is pretty minor. That's for a busy site that tends to keep caches hot. For example: 1st user to want to visit www.example.com: 70ms(rtt to isp dns)+ 100ms(rtt of isp to authority) = 170ms 2nd user to want to visit www.example.com: 70ms(rtt to isp dns) = 70ms 3rd user to want to visit www.example.com: 70ms(rtt to isp dns) = 70ms The 2nd, 3rd, etc. visitors only wait the rtt to their isp dns cache, so the rtt to the authoritative name server does not exist for them. In addition, the client machine only does 1 lookup for the session. So, the 30ms would be amortised even further on a per page view basis. Anycast? Not so much. The actual network distance to the dns server does not change just because the routing information is different. As you know, this has been hashed out in another epic thread recently. In the last part of that thread, you can find: What he is saying is that it is better to let the particular resolver figure out how to get to the fastest of a set of authoritative name servers rather than try to manipulate it with bgp/anycast. Considering the source, that's pretty definitive. Last edited by plumsauce; 01-05-2011 at 01:07 AM.
Posted by funkywizard, 01-05-2011, 01:46 AM
I dunno. Using hyperspin.com I see DNS resolution times make up almost all of the time loading my site for the "using my own" dns resolver domain (ktunnel.com) (>100ms in the US, 200-800ms everywhere else), whereas for my dns made easy domain (vtunnel.com), it brought down the total time to load the site by a lot (at least 100ms), with some locations doing under 50ms that were at 200ms or more using my own resolvers. It's a pretty significant difference. Especially when you consider yahoo's advice of using multiple subdomains in order to increase parellelism of downloading items from your website (a browser will only download 2 items at once from each subdomain). If you have an image heavy site, you can download the site a lot faster if you split up the images into multiple subdomains, but if your dns resolution times are high, then this negates this potential performance advantage. By using an anycast dns resolver that can get your domains resolved in <100ms instead of >200ms, you can make better use of the subdomain trick to get your site loaded a lot faster than it normally would.
Posted by plumsauce, 01-05-2011, 02:54 AM
Ahhhh, but you are not comparing apples to apples then are you? And if you don't do that, the flawed logic leads to an erroneous conclusion. First, the minor quibble. You present the dns only times for ktunnel but then only allude to the total time for vtunnel. It would be more transparent to present both sets in equivalent terms. Now, where the logic chain falls down is that you compare the response times of 3 dns servers in Dallas, Phoenix, and London with those of DME placed around the world. And, you are talking hyperspin which is a company based in Asia. Yes, they have monitor points in the US. They also have monitor points in Asia. To isolate the supposed advantage of bgp/anycast you would need to have the same servers as DME, the same network as DME, and have a physical dns server placed next to each physical DME dns server. Only then can you say the the difference of X milliseconds is due to anycast. And you won't be able to because the *network* distance will be the same or shorter when employing singlecast with the demonstrated behaviour of dns caches to track best RTT over time. These are not obscure behaviours as the most pronounced RTT tracking behaviour is found in BIND. It is a design goal of the bind cache. And finally, to really drive the point home, the true reason for the difference is below. ktunnel is hobbled as compared to vtunnel because a lookup for ktunnel.com requires three extra lookup as compared to vtunnel.com. Looking up ktunnel requires *double* the number of lookups. No wonder it looks slower. But, it has nothing to do with anycast. These extra lookups are caused by the fact that the name servers for ktunnel are at freeproxies.org. In that scenario, an initial query at the root servers will yield a referral to the name servers, but without glue records. The querying server then has to query three extra times. Once for .org, once for freeproxies.org and once to confirm the glue. Couple this with the fact that of all the generic tld's, the .org parents are the slowest, and it is predictable that ktunnel lookups will be slower than vtunnel lookups. Here are the results copy and pasted from a third party test tool(hundreds of lines of output): As ktunnel is a .com, the best thing you can do to remedy the situation is to move them to name servers that are themselves in a .com or .net tld. This is because the .com and .net parent servers are common and will return glue for name servers with either tld. That will cut the dns traversal in half, from 6 queries to 3 queries. Just like for vtunnel. Our users don't get hit with this problem because the control panel *tells* them which name server series to use with which tld. Every recommendation has been checked by hand. I'll send you the consulting bill in the mail Last edited by plumsauce; 01-05-2011 at 03:02 AM.
Posted by funkywizard, 01-05-2011, 03:09 AM
You can feel free to use hyperspin on the domains I mentioned and look at the numbers yourself. It varies quite a bit from run to run, so it's almost pointless to quote specific numbers, but the dns resolution times and total load times for vtunnel (dns made easy) are consistently much lower than for ktunnel (my own dns servers), despite being hosted on the same servers. Ok, so, you're saying that using dns made easy might give me a huge advantage, but not because it's anycast, but because they have servers all over the place? Even if the anycast portion gives exactly zero performance improvement, and 100% of the improvement comes from having dns servers in all those locations, I really don't care. For the $50 / year DME charges, I'm not going to be able to set up my own dns servers in locations around the world, so DME still provides me with a solid benefit vs doing it myself. Thank you, that's very useful information.
Posted by plumsauce, 01-05-2011, 03:33 AM
In part yes. Actually, mostly. In fact, bgp/anycast actually breaks the RTT tracking feature found in all of the major dns cache software used in production because it never gets to see what might be better for the particular network.(bind, powerdns, msdns, djbdns). Exactly. But we come from different ends of the same stick. At my end of the stick, it is important that potential users don't get suckered by the anycast hype. We *do* agree that using a provider is sometimes best because the provider brings specialist skills to the table. For example, the analysis of the dns traversal behaviour above which is the real cause or at least a major contributor of the difference. Da nada
Posted by jaikanth123, 01-05-2011, 03:40 AM
It should be used because : It increases the parallelism available. (Most browsers will only download 3 or 4 files at a time from any given site.) It increases the chance that there will be a cache-hit. (As more sites follow this practice, more users already have the file ready.) It ensures that the payload will be as small as possible. (Google can pre-compress the file in a wide array of formats (like GZIP or DEFLATE). This makes the time-to-download very small, because it is super compressed and it isn't compressed on the fly.) It reduces the amount of bandwidth used by your server. (Google is basically offering free bandwidth.) It ensures that the user will get a geographically close response. (Google has servers all over the world, further decreasing the latency.)
Posted by ibee, 01-05-2011, 05:16 AM
Yes, you are correct. DNS must also be closer to the user's location but it wont be that significant like the files.
Posted by BuffaloBill, 01-05-2011, 10:55 AM
here we go again.... First of all... you are taking the quote completely out of context and there are other proper and improper ways of doing IP anycast. IP Anycast when this was written (back in 2003) you would announce the same IP in multiple locations... but also usually (more often than not) on different providers..... What the posted author is saying is that ASN path network alone will not always be the shortest path. But networks are not like this anymore. The faster CDN and DNS networks of the day will take Tier 1 providers (as many as possible) and announce the same IPs through the same providers in as many regional locations as possible. This ensures that not only your traffic is closest ASN path away but also the closest regional location. To argue that IP anycast does not increase performance is just insane at this point...... Not only does it increase speed, but it increases redundancy at the same time. So what you are saying is that if you have your authoritative name servers: 1) Anycast in United States and Europe. and 2) Only in United States You do a DNS lookup from Europe. You are saying that 2 will be faster? Are you joking around here? IP Anycast will ALWAYS have a faster lookup for your DNS over traditional unicast environments. Have you actually every looked at the BIND code that does this? It's complete mosh.... Yes theoretically a DNS resolver is supposed to "look" at the authoritative name servers for a domain, and then eventually choose the name server with the fastest RTT for future lookups. The first time it checks this it will check each name server... If it is unicast.... it will be slower. Then... if you look at the code... It will then need to continuously check all name servers to get this. Each time if it is unicast... it is slower. IP Anycast is by far faster, more reliable, and a better infrastructure than unicast for DNS or CDN.
Posted by plumsauce, 01-05-2011, 01:17 PM
No. The reading of the quote was quite literal and taken in context of the related paper and presentation. As for whether 2003 is ancient, 7 years is not that long in the RFC world, despite the hype of web-two-uh-oh. But, referring back to the other thread, it was argued by an anycast advocate that "the only true way of anycast" was to use a single tier 1 so that the routing information could be supplemented via igrp, and yet in this thread you argue for "as many as possible". There cannot be two best methods by definition. Only one of the assertions can be correct. No, the argument is that anycast can cause anomalies that the cache cannot correct because it is being fed lies by bgp/anycast. And, it isn't just one person. It is also the public opinion of the author of one of the standard bgp reference texts, and as quoted by a respected dns researcher(verisign, measurement factory, squid cache, dnssec, nanog steering committee). Not to mention their peers at NANOG and DNS-OARC. They must all be insane. It's a good thing you added the because your characterisation of what I said is inaccurate and misleading. What I actually said in post #9 was: To isolate the supposed advantage of bgp/anycast you would need to have the same servers as DME, the same network as DME, and have a physical dns server placed next to each physical DME dns server. Only then can you say the the difference of X milliseconds is due to anycast. And you won't be able to because the *network* distance will be the same or shorter when employing singlecast with the demonstrated behaviour of dns caches to track best RTT over time. So, to match the statement you are responding to, your hypothesis would have to be modified to read: That's what a true apples to apples comparison would entail. There is no barrier to a unicast dns operator to have as many physical servers as a anycast dns operator and with the same network reachability. Then your assertion: cannot be true, and might be false depending on the skill of the bgp implementor and the existence of settlement driven routing policies. Yes. But, all of the code is a complete "mosh" anyways. A lot of that can be charitably attributed to what is dictated as correct behaviour in the somewhat convuluted RFC's. First, the RTT tracking maintenance is a background task. Second, it is learned behaviour over time. Third, the basis of discussion is "hot" zones. That is, zones that are used often enough that the startup cost has been amortised well in the past. When RTT tracking is allowed to work it homes in on the "real" fastest unicast server, and not the lie that the bgp/anycast for a set of anycast dns server might be telling it. That is what Beijnum's "third hand routing information" is alluding to. See the immediately preceding comment. The assertion does not pass the smell test. In particular I remind you of the recent ultradns blackout of the west coast of the US. As I said in another post, it is possible that the regional blackout was a policy decision to avert a complete blackout rather than a technical failure. But, the fact remains that lookups for all zones served by ultradns could not be performed from the west coast because the bgp/anycast lies being told prevented west coast networks from going any place else. And finally, here are the links to the paper and presentation: http://dns.measurement-factory.com/w...2004-paper.pdf http://www.nanog.org/meetings/nanog2...ns/wessels.pdf the source page is here(Wed, 2008-12-31 19:45): https://www.dns-oarc.net/node/167 If there is equivalent rigorously reviewed data for non-root server anycast, it would certainly be an interesting read. The root papers are well known. Last edited by plumsauce; 01-05-2011 at 01:23 PM.
Posted by dotHostel, 01-05-2011, 01:57 PM
If you have the link at hand could you please post it? Thanks!
Posted by dotHostel, 01-05-2011, 02:12 PM
This trick requires a new TCP session for each subdomain (IP) meaning several packages must be exchanged before starting to download the image (increased latency) and increased server load and resource usage (much more when using keep alive). The time to resolve the subdomain is the minor problem. I think it is a bad advice.
Posted by funkywizard, 01-05-2011, 04:23 PM
It's really not bad advice if used properly. Yahoo tells you that there is a tradeoff, and they recommend using a total of two domains to load objects from your website, which is not very aggressive. Using two domains would double the number of objects that can be loaded in parallel without creating too much overhead from the issues you're describing. The additional resource usage from multiple open connections is only significant in apache which spawns a thread for each connections. In squid, nginx, lighttpd, or any of the other higher performing web servers, having a few thousand open connections is no problem, whereas with apache, you really start to bog things down with more than a few hundred open connections.
Posted by BuffaloBill, 01-05-2011, 04:25 PM
Once again though... Outage on the west coast is better than being down everywhere. Unicast name server goes down everywhere... Anycast server would go down regionally. Did UltraDNS go down? yes... but it was an attack. No provider can stay up through all size attacks. If you look at the routing tables you will see that UltraDNS has a great network... probably the best out there (other than Verisign of course). Not sure why you think BGP "lies" to resolving name servers. These are actual routes... These are real routes. There are routes that are regional. An electron can only move so fast. Having an electron move from the West Coast to the East Coast will take longer than leaving it on the West Coast to begin with. That is just because they only move so fast..... I respect your passion about trying to prove that IP Anycast is all hype and it does nothing for speed or redundancy. But this is just not true. Putting misleading articles that are not really looking at all aspects of the debate on hand is not doing it justice. Once again... There is a reason that Google, Amazon, Yahoo, Facebook, etc... use CDN and anycast DNS services. There is a reason.... this is not the biggest marketing fluff in history. Once again... we will have to agree to disagree on this point.
Posted by dotHostel, 01-05-2011, 06:05 PM
I understand your point but I disagree. First you are cutting the server peak capacity by 50% just to serve static files. Surely you may put cache servers between the visitors and the server serving dynamic pages but the "edge" servers running Varnish, Squid, Nginx, Lighttpd, you name it, also will have their peak capacity reduced by 50%. If you are talking about some hundreds thousands visitors maybe your half-capacity could be enough but if you have really millions of visitors this trick is not that good. The second reason is hardware load balancing. Take a look at these figures from Softlayer website: Service Monthly Local Load Balancing - 50 Connections $49.99 Local Load Balancing - 100 Connections $99.99 Local Load Balancing - 200 Connections $199.99 Local Load Balancing - 500 Connections $499.99 Local Load Balancing - 1000 Connections $999.99 If you are not using a bunch os Varnish-like front servers to deliver static content but you are using HA provided by hardware load balancers you will have to pay twice LB cost for the same number of visitors. Once again, Yahoo's subdomain advice doesn't look a good advice. Last edited by dotHostel; 01-05-2011 at 06:14 PM.
Posted by funkywizard, 01-05-2011, 06:51 PM
I see what was meant by the popcorn. Wow, I'm sorry I walked into this thread. The amount of stubbornness and cluelessness going on here is so intense that it's not even worth replying to the specific arguments being made. /unsubscribe
Posted by dotHostel, 01-05-2011, 06:59 PM
I couldn't agree more.
Posted by DNSShawn, 01-05-2011, 07:17 PM
Sorry guys. I was hoping to open up dialogue to discuss the value of a distributed dns service. DNS is such a critical piece albeit a small piece of the overall internet infrastructure. I thought some of the feedback here was valuable. I think that if you look at the important web properties that leverage Anycast/BGP DNS service it speaks louder than anything I can say about it. I think that with more companies entering the space it helps to validate the importance of such technology. I really try not to get into combative conversation on who the best provider is. "Best" is determined by the needs of the specific customer. If high availability and/or the need for value added services such as DNS based traffic management tools such as CDN load balancing, failover or geo directional DNS, DDoS mitigation (at the DNS layer)is a priority then there are really are only a handful of companies to choose from. <> Last edited by Harzem; 01-05-2011 at 07:35 PM.
Posted by hhw, 01-05-2011, 10:25 PM
I'd argue that the ideal scenario is a single network, with good geographic coverage, and as many Tier 1 upstreams/peers as possible. This is also the most common scenario for most BGP Anycast solutions out there. Sure, anycast can cause anomalies with caching. So can a number of other things not anycast specific. There's always pros and cons to any solution. At the end of the day, Anycast has advantages that handily outweigh the drawbacks. The vast majority of DNS providers that have the network infrastructure in place to provide anycast, choose to do so for a reason. Out of curiosity, do you actually have any real-world experience working on a properly engineered DNS Anycast solution? Your emphasis on the issues seem to be greatly out of proportion with what's actually seen in real life.
Posted by dotHostel, 01-05-2011, 10:35 PM
Just falacious arguments.
Posted by BuffaloBill, 01-06-2011, 10:05 AM
Here are some links and videos that explains the benefits of IP anycast. http://www.youtube.com/watch?v=14zDA...eature=related http://www.youtube.com/watch?v=LGYxQ...eature=related http://www.youtube.com/watch?v=HJtxF...eature=related http://www.youtube.com/watch?v=n-8uj...eature=related It seems like some people will only value comments if they were written by authors of Oreilly books. Soooo. in the first video is with Cricket Liu, an author of the DNS and BIND books... which are the bibles of DNS for all practical reasons. In the end... IP Anycast is a clear example of a better network for DNS.
Posted by dotHostel, 01-06-2011, 10:20 AM
falacious_arguments = falacious_arguments + 1 Did you read this paper http://dns.measurement-factory.com/w...2004-paper.pdf ?
Posted by BuffaloBill, 01-06-2011, 10:52 AM
You mean falacious_arguments = falacious_arguments + 2 for you? You mean the article that comments nothing on BGP and Anycast and is really an article on how cache name servers work? The one found at? http://dns.measurement-factory.com/w...2004-paper.pdf If you want to grasp at straws it is the same article that states: "Windows 2000 locks on to a single, random nameserver, and Windows 2003 shows an odd, unbalanced distribution." If you are able to process this information and have any idea on what IP Anycast is... THIS is actually stating that IP Anycast DOES increase speeds. It does also state: "Both versions of BIND favor servers with lower round-trip times" Which is great. But IP Anycast will give you the redundancy that you want then. And unless you have one authoritative name server in that area.... IP Anycast will also INCREASE speeds!!! Also for the time it does not "favor" the faster RTT server... IP Anycast does INCREASE speeds! It also states: "DJBDNS always uses a uniform distribution" Which once again if you understand what BGP IP Anycast is it will increase your speeds! So nothing in your article states that IP anycast will slow down queries and make your DNS network less reliable.... It is foolish to think otherwise. Go to a NANOG meeting. State your opinions..... you will be laughed out of the building. Stop taking articles and quotes out of context. Learn all of the facts. Understand the technology. Actually implement the technology. Understand what you are claiming before you post it and try to confuse others. Last edited by BuffaloBill; 01-06-2011 at 10:58 AM.
Posted by joshef, 01-10-2011, 03:01 AM
Hi. The concept is simple. Various Web sites you visit each seek a second identical copy of these libraries. You probably have a couple dozen copies of jQuery in the cache of your browser at this time. It's stupid. We should.
Posted by cloudtweaks, 01-22-2011, 07:24 AM
To save bandwidth, Loading time & CPU usage!!
Posted by plumsauce, 01-29-2011, 12:38 AM
As you note, a ddos can come in varying sizes. Some are survivable and some are not for any given provider capacity. However, the big but for anycast in the situation identified above is that it, the chosen structure, forced a policy decision to take a certain form. It was all or nothing. I did not choose the word "lie". The original author did. Perhaps for effect, although it is apt. A more neutral term might be "external coercion of routing decisions". The assertion is that anycast causes the software to behave in a way that is not optimal for the software. The software in question is the isp cache resolver. If you read back through the multiple threads, you might realise that the assertion is never that anycast is not good. In fact, it is not mentioned at all unless and until someone pipes up with the old saw of "anycast is an absolute must". Only at that point do I start discussing the pros *and* cons. You should not only read the responses as if they were directed at you. At times, there is also mistruth sprinkled about by various snipers who are pro anycast. These snipers do not always stick to provable fact, or offer citations. The articles I posted were from reputable people with illustrious backgrounds who are attached to the very organisations which are at the centre of all things dns. In other words, it is the state of the art in terms of informed opinion. A great deal of care was taken in the citation of the articles and they were posted in good faith as having passed the smell test. The fact that A,B, or C use a technology proves nothing other than the fact that they have decided to deploy it in response to a perceived particular internal goal. That goal may not be germane to anycast at all. It might bless the technology with the halo effect, but it is not in and of itself proof of anything. That's a given. Finally, DME does deploy anycast. As do the other providers in your stable. Whether anyone else does should not impact the salability of the product. Indeed, some clients eyes may glaze over at the technicalities. Their only concern is "will my users get a correct and timely response to a query?" Everything else is irrelevant.
Posted by plumsauce, 01-29-2011, 01:44 AM
This was why my reply has come so late. I saw the reply notification go through with a bunch of links. So, "a bunch of pdf's, well that will take a while". But really? Youtube videos? Sorry, I can't comment because none of my workstations do flash. In any case, Cricket Liu is now an employee with a vested interest. Executive VP at InfoBlox. The videos are no doubt part of the BloxTalks(tm) video series commissioned by and sponsored by InfoBlox. Let's see what they say in their F5/InfoBlox partnership brochure: No mention of the actual nasty implementation details, such as acquiring the ability to announce bgp from multiple ingress points, but oh well it's a sales brochure. And his blog: He's pretty stoked about the mention of anycast, even adding a "!" for emphasis. DNSSEC? not so much. Then he tells his readers to highlight it and drop it on the boss's desk. Any good sales rep would do that. A cautious reader would do well to remember that here is an executive of a company that sells some expensive appliances which incorporate a specific differentiating feature pushing that exact feature. Is he being accurate or a good salesman doing the best for his company?
Posted by plumsauce, 01-29-2011, 02:09 AM
Again with the out of context snippets? It also notes the design goal, and the fact that it has again improved in Windows 2008. BTW, Windows 2000 is EOL, except on my workstation. Furthermore, the *reality* is that very few isp's use Windows DNS Servers as dns caches. They love free as in beer. So mostly, bind. No, anycast will not increase speeds, at best it will remain even. anycast restricts the routing choices made by the client server. Again, no, anycast will not increase the speed for djbdns. A server is X distance away on the wire from the other server, and nothing will change that. If that does not change, and the speed of light does not change, the RTT will not change. As the paper was presented at NANOG and as it remains in public at a site that works closely with NANOG, apparently it is fine with them, and any laughter was directed elsewhere. In conclusion, anycast has a place in dns architectures. Improving RTT is not one of them. Or at least, not one of the valid ones. ##
Posted by tim2718281, 01-29-2011, 06:10 AM
And here's the Yahoo! User Interface Blog confirmation: http://yuiblog.com/blog/2007/04/11/p...search-part-4/ "... In our experiment, we vary the number of aliases: 1, 2, 4, 5, and 10. This increases the number of parallel downloads to 2, 4, 8, 10, and 20 respectively. We fetch 20 smaller-sized images (36 x 36 px) and 20 medium-sized images (116 x 61 px). To our surprise, increasing the number of aliases for loading the medium-size images (116 x 61px) worsens the response times using four or more aliases. Increasing the number of aliases by more than two for smaller-sized images (36 x 36px) doesnt make much of an impact on the overall response time. On average, using two aliases is best. ..."