On Fri, 8 Sept 2023 at 09:17, Mark Tinka <mark@tinka.africa> wrote:
Unfortunately that is not strict round-robin load balancing.
Oh? What is it then, if it's not spraying successive packets across member links?
I believe the suggestion is that round-robin out-performs random spray. Random spray is what the HPC world is asking, not round-robin. Now I've not operated such network where per-packet is useful, so I'm not sure why you'd want round-robin over random spray, but I can see easily why you'd want either a) random traffic or b) random spray, if neither are true, if you have strict round-robin and you have non-random traffic, say every other packet is big data delivery, every other packet is small ACK, you can easily synchronise one link to 100% util, and and another near 0%, if you do true round-robin, but not of you do random spray. I don't see downside random spray would have over round-robin, but I wouldn't be shocked if there is one. I see this thread is mostly starting to loop around two debates 1) Reordering is not a problem - if you control the application, you can make it 0 problem - if you use TCP shipping in Androids, iOS, macOS, Windows, Linux, BSD reordering is in practice as bad as packet loss. - people who know this in the list, don't know it because they read it, they know it, because they got caught pants down and learned it, because they had reordering and tcp performance was destroyed, even at very low reorder rates - we could design TCP congestion control that is very tolerant to reordering, but I cannot say if it would be overall win or loss 2) Reordering won't happen in per-packet, if there is no congestion and latencies are equal - the receiving distributed router (~all of them) do not have global synchronisation, they do not make any guarantees that ingress order is honored for egress, when ingress is >1 interface, the amount of reordering this alone causes will destroy customer expectation of TCP performance - we could quite easily guarantee order as long as interfaces are in same hardware complex, but it would be very difficult to guarantee between hardware complexes -- ++ytti