Today ILNP and LISP solutions offer such decoupling in practice.
So now we fully diverged from the original topic :) But anycast was not the original problem anyway ...
Cheers,
R.
R.
On Sun, Aug 8, 2021 at 12:23 AM Töma Gavrichenkov <ximaera@xxxxxxxxx> wrote:
Peace,
On Sun, Aug 8, 2021 at 1:09 AM Robert Raszuk <robert@xxxxxxxxxx> wrote:
> Internet last time I checked uses IP. IP is connection less by design. So is entire Internet architecture.
> Anycast in a connection less fashion - meaning stateless - will work just fine - pretty much in all cases.
> But using connection less forwarding plane and transporting connection oriented protocols (like TCP) only works between solid anchors (read endpoints).
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.
> And this is not only about flow label and hashing. Internet routing continues to churn. Every second routing may decide for you to prefer some other BGP path and your anycast destination may end up in different destination naturally only by following the destination routing paradigm.
Exactly, and you need to get your applications to be aware of that,
and not to shift this responsibility to the network which actually
bears no responsibility, in particular over that.
> PS. Of course there are more smart ways to use anycast for TCP. Those involve attracting packets only for further forwarding to the consistently selected servers/gateways.
I believe this was covered before on the thread, and I don't see any
answers here to the issues raised before.
--
Töma
