On 9/1/18, William Herrin <[email protected]> wrote: > On Sat, Sep 1, 2018 at 4:00 PM, William Herrin <[email protected]> wrote: >> On Sat, Sep 1, 2018 at 2:51 PM, <[email protected]> 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-balancing-requests). >> >> 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
