[Bloat] Congestion control with FQ-Codel/Cake with Multicast?

["Linus Lüssing" <linus.luessing@c0d3.blue>]

Hi,

In the past, flooding a network with multicast packets
was usually the easiest way to jam a (wifi) network,
as IPv6/UDP multicast in contrast to TCP has no native
congestion control. And broadcast/multicast packets on Wifi
would have a linear instead of exponential backoff time compared
to unicast for CSMA-CA, as far as I know.

I was wondering, have there been any tests with multicast on a
recent OpenWrt with FQ-Codel or Cake, do these queueing machanisms
work as a viable, fair congestion control option for multicast,
too? Has anyone looked at / tested this?

Second question: I'm sending an IPv6 multicast
UDP/RTP audio stream with RaptorQ [0] for forward error correction
with gstreamer [1]. I'm using separate IPv6 multicast addresses
for the original and RaptorQ streams, so that a user I might join
individually depending on their network quality. I might also add
more streams for the same data but at lower codec bitrates, as well
as additional RaptorQ streams with different settings in the future. 
I guess FQ-Codel/Cake in OpenWrt would see them as individual
sessions, due to differing IPv6 multicast destination addresses?
Anything I could/should do that they would be seen as one session,
to avoid that they would get an unfairly higher share of the
available bandwidth? What would be an ideal, automized approach,
snooping SDP [2] from SAP [3] messages maybe? (does anyone know how
RaptorQ should be encoded in SDP alongside the original RTP payload?)

Regards,
Linus


[0]: https://www.rfc-editor.org/rfc/rfc6330
[1]: $ gst-launch-1.0 \
    rtpbin name=rtp \
    fec-encoders='fec,0="raptorqenc\ mtu=400\ repair-packets=15\ repair-window=500\ symbol-size=192";' \
    pulsesrc device="radio-station-source-01" \
    ! audio/x-raw,channels=2 ! audioconvert ! audioresample \
    ! opusenc ! queue ! rtpopuspay \
    ! rtp.send_rtp_sink_0 rtp.send_rtp_src_0 \
    ! udpsink host=ff7e:240:2001:67c:2d50:0:545f:5800 port=5000 ttl-mc=64 rtp.send_fec_src_0_0 \
    ! udpsink host=ff7e:240:2001:67c:2d50:0:545f:5802 port=5002 ttl-mc=64 async=false
[2]: https://datatracker.ietf.org/doc/html/rfc8866
[3]: https://datatracker.ietf.org/doc/html/rfc2974