|
After the hash would be recalculated, the flow may be pushed to the same broken link or node. Is probability 50% or 75% to repair problem good enough? (for ECMP to 2 or 4 paths) Should RTO give a chance to IGP to repair the problem in a normal way (1s?) Ed/ From: ietf [mailto:ietf-bounces@xxxxxxxx]
On Behalf Of Töma Gavrichenkov Peace, On Tue, Aug 10, 2021, 9:31 AM Gyan Mishra <hayabusagsm@xxxxxxxxx> wrote:
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. 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. 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. 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. 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. -- Töma |
