Re: Service provider story about tracking down TCP RSTs

[Lee <ler762 () gmail com>]

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-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