On 9/1/18, William Herrin <bill@herrin.us> wrote:
On Sat, Sep 1, 2018 at 4:00 PM, William Herrin <bill@herrin.us> wrote:
On Sat, Sep 1, 2018 at 2:51 PM, <frnkblk@iname.com> wrote:
pointing out that a single traceroute to a Fastly site was hitting two of their POPs (they use anycast) and because they don’t sync state between POPs the second POP would naturally issue a TCP RST (sidebar: fascinating blog article on Fastly’s infrastructure here: https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balan...).
Better yet, do the job right and build an anycast TCP stack as described here: https://bill.herrin.us/network/anycasttcp.html
BTW, for anyone concerned about an explosion in state management overhead, the TL;DR version is: the anycast node which first accepts the TCP connection encodes its identity in the TCP sequence number where all the other nodes can statelessly find it in the subsequent packets. The exhaustive details for how that actually works are covered in the paper at the URL above, which you'll have to read despite its length if you want to understand.
An explosion in state management would be the least of my worries :) I got as far as your Third hook: and thought of this https://www.jwz.org/doc/worse-is-better.html I had it much easier with anycast in an enterprise setting. With anycast servers in data centers A & B, just make sure no site has an equal cost path to A and B. Any link/ router/ whatever failure & the user can just re-try. Lee