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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
