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

[Linus Lüssing]

And two more things that would be nice, but which are probably not
implemented yet (but I would love to get other people's opinions
on this):

1) On congestion, prefer dropping RaptorQ RTP packets instead of the
original RTP packets?
(the original RTP packets should have a smaller delay and higher
probability for decoding the stream?)

2) Avoid sending a RaptorQ RTP packet from a WiFi AP to an STA in
3 address mode (so where the STA/client is known not to be
bridged) if according RTP packet(s) from the original RTP stream
were successfully transmitted / had a confirming WiFi ACK.

Regards, Linus


On Tue, May 21, 2024 at 04:56:18PM +0200, Linus Lüssing via Bloat wrote:
> 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat