nanog mailing list archives

Re: Lossy cogent p2p experiences?


From: Saku Ytti <saku () ytti fi>
Date: Fri, 8 Sep 2023 09:29:48 +0300

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


Current thread: