[detaro]

ECMP typically doesn't split a single flow over both connections, and due to hashing might very well try to send multiple flows over one connection while underutilizing the other. Typical ECMP as far as I know also doesn't handle links of different speeds very well.

[technimad]

Indeed, ECMP uses some kind of hashing (dependant on the implementation) to do the distribution and doesn't take different line speeds into account at all. Great improvement if this project does take this into account.

[realloc]

The C in ECMP stands for “cost”, which is usually calculated as the number of hops or intermediate nodes to the destination. If you were to use link speed as the “cost”, links of unequal speed wouldn’t be equal cost anymore. You can certainly use ECMP over links of different speeds, but as you said bandwidth doesn’t scale for a single connection, so any TCP connections that end up on the slower link perform at the speed of the slower link and it’s difficult to figure out why.

This is intentional: TCP treats packets received out-of-order as representative of an overloaded network. There’s generally a guarantee that packets sent in-order over a single link will be received in that order, but no such guarantee exists for packets sent through two completely independent links/networks. You need something on the receiving end (either at the destination or at the point where the separate paths converge) that will coalesce and re-order packets, such as an MPTCP or PPP implementation.