[dns-operations] Who Ignores TTLs ?

[Patrick W. Gilmore]

On Feb 21, 2011, at 8:19 PM, Paul Vixie wrote:

>> From: Warren Kumari <warren at kumari.net>
>> Date: Mon, 21 Feb 2011 19:29:09 -0500
>> 

>> ...but for folk who have lots of short lived connections this adds up
>> *real* quick. It also requires a single (or small number) of central
>> locations that need to a: be really really reliable and b: able to
>> perform a huge number of redirects, doesn't it?
> 
> ...no.  if a web site's internal links are relative, then the first
> redirect will affect all the other fetches as wel.  furthermore,
> http/1.1 means you'll tend to fetch a lot of objects over each tcp/80
> session.  so even if a browser opens multiple tcp/80 sessions to the
> "web server" in order to parallelize, the number of redirects will
> be much lower than the number of objects.

Your "no" only applies to "b" above, and even then it is not completely correct.  For large systems, just because the number of redirects will be lower than the number of objects doesn't mean the central site will not perform a huge number of redirects.

A is still valid.  Plus what you suggest requires the central site to serve at least some of the HTML, which will affect performance.  And the time for the 302s does add up.

You can calculate the number of "central" nodes you need to make the redirects work as fast as heterogenous A record mapping, and it ain't pretty.  Plus you need to anycast those central sites since the point you are trying to push is use of homogeneous A recored.  As stated up thread, anycast does not work as well as heterogenous A record mapping[*], even if you have as many anycast sites as CDN sites - which is obviously not going to happen.

So you end up with a slower central site plus added time for the redirect.  It just doesn't work out.

In summary, HTTP redirects may work for mirror sites, but for large systems which require high performance, they simply are not an option.  Since most of the traffic on the 'Net today is mapped via heterogenous A records, I think that qualifies as a "large system".


> noting that tcpct (RFC 6013) offers the possibility of additional
> savings in the important "time to first eyeball" metric, even greater
> than the best possible results from any conceivable non-tcpct cdn
> technology.  i hope this means our grandchildren will have a cleaner
> design to work with.

I have not seen this RFC (published last month!).  I read the abstract & intro, and I don't immediately see how it can do what you say - but it is past 3 AM here and there was drinking involved tonight. :)

If it really does perform better, -everyone- will be using it as quickly as they can.  The Internet is a business, and business decisions are made on things like performance & reliability.  If this works, it will get used.

That said, I'm not terribly sanguine about the proposed technology's chances of out-performing a well run CDN.  Time will tell if my initial impression is wrong or right, and probably very quickly.

-- 
TTFN,
patrick

[*] Remember, BGP has -nothing- to do with performance, only reachability.  We've all seen users cross an ocean to reach an anycasted server.  Doesn't matter how many servers you have that are closer, BGP doesn't know - or care - about latency.  Using heterogenous A records, you can ensure that happens far less often.

It is physically impossible to control user mapping with anycast the way you can with heterogenous A records.  And we haven't even started to discuss things like failover, overflow, mapping different customers dynamically, etc.  What happens if one server is getting full in an anycast node?  You can't direct some users away and keep others with BGP.  With DNS mapping, you can change the next DNS query, but the previous users will not have their TCP sessions interrupted.  Of course, this is a ridiculously trivial example of what can be done with heterogenous A records that cannot be done with BGP/anycast, things get far, far more complex.  (That is a small part of the answer Jim wanted.)