Lossy cogent p2p experiences?

Saku Ytti saku at ytti.fi
Thu Sep 7 07:51:12 UTC 2023


On Thu, 7 Sept 2023 at 00:00, David Bass <davidbass570 at 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


More information about the NANOG mailing list