<div dir="ltr">Heh - You _learn_ that Anycast isn't good for TCP, but LinkedIn proved differently. Their website uses TCP (obviously), works almost always, and gracefully recovers when Anycast throws a curve.<div><br></div><div>There's a great interview on Packet Pushers with LinkedIn Global Engineering:<br></div><div><br></div><div>Packet Pushers: Show 286: Busting Anycast TCP Myths</div><div><a href="http://packetpushers.net/podcast/podcasts/show-286-busting-anycast-tcp-myths/">http://packetpushers.net/podcast/podcasts/show-286-busting-anycast-tcp-myths/</a></div><div><div><br></div></div><div>...and a blog post:</div><div><div><a href="https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality">https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality</a><br></div></div><div><br></div><div>-Mike Tewner</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 25, 2016 at 12:14 AM, Amos Shapira <span dir="ltr"><<a href="mailto:amos.shapira@gmail.com" target="_blank">amos.shapira@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Anycast is not suitable for TCP.<div>It IS fantastic for DNS (which uses UDP), which is the first thing a client does most of the time to find the server.<div>Akamai control server groups by allocating per-customer per-object host names, then these can be resolved using their very highly customised DNS servers to the right server (also taking into account dynamic changes like server cluster load or failure).</div><div>Since DNS uses UDP and the traffic consists on one packet in each direction, Anycast is ideal for that scenario.</div></div><div>The actual content transfer (e.g. move streams, which is where I with Akamai for <a href="http://stan.com.au" target="_blank">stan.com.au</a>) doesn't use Anycast.</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 24 November 2016 at 04:06, Shachar Shemesh <span dir="ltr"><<a href="mailto:shachar@shemesh.biz" target="_blank">shachar@shemesh.biz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="direction:ltr" bgcolor="#FFFFFF" text="#000000">
<div class="m_595169681659081714m_5483568710477899544moz-cite-prefix">On 22/11/16 02:19, Amos Shapira wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 21 November 2016 at 18:20, Shachar
Shemesh <span dir="ltr"><<a href="mailto:shachar@shemesh.biz" target="_blank">shachar@shemesh.biz</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="m_595169681659081714m_5483568710477899544gmail-m_-7321374812641881217moz-cite-prefix">The
DNS resolving <a href="http://google.com" target="_blank">google.com</a>
guesses your gegraphical location, and gives you an
answer that is nearest where you are. If you use
another DNS to query the domain, you will get a
different IP:<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>It's not always a "guess your geographic location". The
smarter ones use Anycast to advertise the same IP address
from multiple locations on the Internet and let BGP do its
magic to route your packets to the nearest server, taking
into account any congestion or other transient connection
speed changes. This is how Google's DNS 8.8.8.8 works, or
Akamai's CDN. The nice thing about it is that you get
optimal response even at the host resolution stage. The
DNS server can then take its knowledge of the DNS query
source address into account when it decides which IP
address to resolve to.</div>
<div><br>
</div>
<div>It's pretty neat, personally I find it a fascinating
trick: <a href="https://en.wikipedia.org/wiki/Anycast" target="_blank">https://en.wikipedia.org/wiki/<wbr>Anycast</a></div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
It is, quite fascinating. It is not, unfortunately, as useful as you
make it out to be. Neither Google nor Akamai use it for web traffic,
for example.<br>
<br>
The reason is twofold. First, anycast is poorly equipted to handle
TCP connections. There is a (remote) possibility that the handler of
your IP would change mid-request, which would not play nice with
your connection.<br>
<br>
The second, more pertinent, reason is that , at least for Akamai,
they would like to be able to control which server you reach when
you make a request. The would like to be able to re-route your in
case something bad happens to that server. DNS TTL can be set as low
as 30 or 60 seconds. BGP routes have much longer settle times.<span class="m_595169681659081714HOEnZb"><font color="#888888"><br>
<br>
Shachar<br>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_595169681659081714gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><a href="http://au.linkedin.com/in/gliderflyer" target="_blank"><img src="https://static.licdn.com/scds/common/u/img/webpromo/btn_viewmy_160x25.png"></a><br></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Linux-il mailing list<br>
<a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
<a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" rel="noreferrer" target="_blank">http://mailman.cs.huji.ac.il/<wbr>mailman/listinfo/linux-il</a><br>
<br></blockquote></div><br></div>