On Thu, 7 Sept 2023 at 00:00, David Bass <davidbass570@gmail.com> wrote:
Per packet LB is one of those ideas that at a conceptual level are great, but in practice are obvious that they’re out of touch with reality. Kind of like the EIGRP protocol from Cisco and using the load, reliability, and MTU metrics.
Those multi metrics are in ISIS as well (if you don't use wide). And I agree those are not for common cases, but I wouldn't be shocked if someone has legitimate MTR use-case where different metric-type topologies are very useful. But as long as we keep context as the Internet, true. 100% reordering does not work for the Internet, not without changing all end hosts. And by changing those, it's not immediately obvious how we end-up in better place, like if we wait bit longer to signal packet-loss, likely we end up in worse place, as reordering just is so dang rare today, because congestion control choices have made sure no one reorders, or customers will yell at you, yet packet-loss remains common. Perhaps if congestion control used latency or FEC instead of loss, we could tolerate reordering while not underperforming under loss, but I'm sure in decades following that decision we'd learn new ways how we don't understand any of this. But for non-internet applications, where you control hosts, per-packet is used and needed, I think HPC applications, and GPU farms etc. are the users who asked JNPR to implement this. -- ++ytti