Töma Gavrichenkov <ximaera@xxxxxxxxx> wrote: > The entire idea that there are any "solid" anchors on the Internet > kinda defeats the purpose of the Internet, doesn't it? > > We're now accustomed to the Internet where the _packet_flows_ are > kinda stable. This is how it works, in practice, 95% of the time b/c > of giant intercontinental fiber lines, b/c ISPs have their SLAs, etc. > > This is probably the shiny moment in time this is true, but it's not > supposed to stay for much longer, in part because the ISPs are > merging, the controlling entities want some control over that, > peerings break, but mainly because it was never supposed to go this > way, since the Internet is _inherently_peer_to_peer_, with no > guarantee over the paths, with no SLAs over the paths and the RTTs. > > It's not the anycast that doesn't meet the concept of long-living > stable connections, it's the concept of stable connections that > doesn't fit into the architecture of the Internet. Perhaps it's me missing something here, but I don't follow you. Surely a globally unique address is a "solid anchor" in that (unless something has gone badly wrong), that will belong to one and only one node* - and it will remain belonging to that one node for as long as the admins keep it that way. So ignoring anycast, we send a packet to <some address> and "somehow" it arrives at <some address> and hence the one node that own that address. In general we don't care how it gets there, but hopefully it does. We don't care if one packet goes direct via a short route, while another packet goes all round the world, either the protocol (TCP) or the application level re-assembles the packets into the order they are needed, or some get dropped if time is more important than completeness (e.g. real-time audio stream). I've certainly had SSH sessions running for long times (sometimes days), even when I know that there's been a temporary failure (e.g. our local DSL line has dropped), though in the latter case, it's reliant on either not sending any packets while there is no available path, or the network becoming available again within the timeout limit for the protocols involved. More often I've had to add keepalives to deal with aggressive NAT gateways (IPv4) that drop inactive mappings even if they are TCP and the gateway has not seen it teared down. Of course anycast changes that - if routing changes then the other end may change. But I would not consider an anycast address to be a "solid anchor" for a long lived connection unless the protocols concerned don't care if the other end node gets swapped part way through a session. * If that address happens to be something like a load balancer then that doesn't really matter since it's down to the operator of that cluster of devices to manage things so that remote devices can establish long lived (where "'long lived" will be different for different connections involved) connections without the load balancer switching nodes on it - and thus give the outward appearance of there being "one node". Simon
