Re: Multicast packet reordering

[Etienne Champetier <champetier.etienne@gmail.com>]

Le 02/12/2022 à 08:46, Andrew Lunn a écrit :
> On Thu, Dec 01, 2022 at 11:45:53PM -0500, Etienne Champetier wrote:
>> Hello all,
>>
>> I'm investigating random multicast packet reordering between 2 containers
>> even under moderate traffic (16 video multicast, ~80mbps total) on Alma 8.
> Have you tried plain unicast UDP?

Just did on Fedora 37, and same results, if I don't enable RPS I get a bit of reordering from time to time
for i in {1..10}; do
   iperf -s -u --port $((5000+i)) -i 1 &
done
iperf -c 127.0.0.1 -u -i 1 -b 2G -l 1316 -P 10 --incr-dstport -t0

> There is nothing in the UDP standard which says UDP has to arrive in
> order. Your application needs to handle reordering. So your time might
> be better spent optimizing your application for when it happens.

I a big believer in fixing where things are broken, but it's not always the easiest path (or even possible).

I'm in the video industry and working on an "appliance" that host multiple applications each as separate containers.
Some applications are from our R&D, some from third party. The default protocol that everyone supports
to pass video around is MPEG TS over udp multicast, and this requires reliable network (no drops/no reordering).
A good number of those application supports RTP, which has a reorder buffer and optionally FEC,
but sadly not all, and having third party implement new features can take years.

When running all applications on separate separate servers reordering has never been an issue,
ie physical NIC and switch do a better job at keeping packets in order than virtual interface it seems.

I understand if we trade off non strict ordering for performance, but is it the case ?
I'm fine enabling RPS and calling it a day, I was mostly looking for comments if it's expected Linux behavior.

Etienne

> 	Andrew