Hi Töma
On Tue, Aug 10, 2021 at 5:55 AM Töma Gavrichenkov <ximaera@xxxxxxxxx> wrote:
Peace,On Tue, Aug 10, 2021, 9:31 AM Gyan Mishra <hayabusagsm@xxxxxxxxx> wrote:a patch that makes default less aggressive by restoring the original default behavior to recompute hash only after multiple RTOs.Let's now talk about hacks, right?A flow is basically a stream of similar data within one or more connections. This is an application layer concept. Architecturally, it may change on a connection if the data flow within the connection changes.
Gyan> Agreed
E.g. we've established a connection to [youtube DNS A entry]:443, downloaded the hypertext, but now we're going to reuse the same established connection to stream video, so the network should better treat that connection somehow differently now.
The flow label was never supposed to be a legitimate control over routing. It shouldn't change over one, two, or a hundred RTOs. It generally only changes when the flow becomes different.I believe this was so obvious to the authors of the original specification in 2003 that they even forgot to actually state it.
Gyan> Very Good point. So let’s say you have an IPv4 or IPv6 TCP Anycast connection you should stay on that proximity routed flow throughout the duration that goes for the long lived TCP. But now with the Linux hack we now shift after the first RTO immediately to try a different BGP anycast path via Linux hack patch and hope for better results in case the first path was congested or having issues. This is definitely an application based network engineering hack by a Linux developer whom had the best intentions of a application network awareness self healing network. From a technical standpoint as a TCP RST has already been receiving and we are re-establishing the connection, I am not understanding why this was such a bad thing understandable that it’s aggressive but the thought process does makes sense. The Linux developers thought was that if you got an RTO, then more then likely that network path is bad and let’s rehash to a different path immediately. I can see the down side is that first Anycast path from a BGP path selection was the best lowest latency path, but now the application thinks it understands the network better then network engineers and thinks it’s better to rehash to a different path immediately. The MAJOR problem with that is as BGP Anycast is proximity based you could end up going half was around the world for the second best path and now voila —> TCP Anycast is now from the Happy Eyeballs (not the RFC 6555) but user perspective is completely broken thus the subject heading “IPv6 Anycast has been killed by Linux patch”.
What Tom proposed is, of course, way better than how it works now. Especially the socket option — yay, Linux is finally going to implement the "MUST" in RFC3697#3! We harbour the hope that other operating systems would do the same good thing.
Gyan> Given what I stated above I would say let the Network do the networking and as CDN makes up 90% plus of the internet traffic being GEO load balanced worldwide, and as we have IETF ALTO WG that does application based traffic optimization BGP-LS / PCEP CDN RSVP / SR aware network optimization based solutions that already exist today, let’s kill the Linux hack all together. As the Linux server is completely unaware of network conditions any rehash is bad thing as that breaks TCP Anycast by sending you clear around the world when you should be “sticky” based on BGP Anycast best path selection stay on the optimization proximity based network path and only shift to alternate BGP path when the path is no longer available. Let routing do it’s routing!!
But the idea I'm trying to drive home is: fixing (temporary) network delivery issues via the control of a strictly application level feature is among the dirtiest of the hacks possible.
Gyan> Firmly agreed
And it kind of amazes me how people call anycast a hack (while it's perfectly the behaviour natural to the Internet, a global self-healing internetwork, as designed in 1970s) and still consider this a legitimate behaviour.
Gyan> Agreed
Gyan> After reading the feedback from Toma can we not rehash at all for the Default Linux patch. See the MAJOR problem that is being created when you try to rehash with BGP Anycast described above and that basically any rehash literally breaks IPv6 flow label based TCP Anycast CDN load balancing.
--Töma
