Re: IFB-based ingress shaping causes serialized throughput across multiple APs

[Ramon Fontes]

> Could this behavior be due to the IFB mechanism being global at the kernel level (i.e., a shared workqueue among all IFB devices)?
I don't think so.

> Are IFB devices truly independent in Mininet-WiFi, or do they share a single kernel namespace for packet scheduling?
They are independent.

> What would be, in your opinion, the most correct way to achieve ingress shaping per AP (for example, replacing IFB with veth pairs, or using tc-mirred differently)?
Firstly, you have to make sure that this is related to ingress shaping.

Finally, could there be any formal limitation in Mininet-WiFi or the
Linux traffic control subsystem that explains this serialized
throughput?
I've never experienced such behavior.

I believe the most appropriate way to verify this is by checking it
hop by hop. I don’t have information about the network topology, but
the issue may be related to it or possibly to the flow tables.

Em ter., 21 de out. de 2025 às 12:33, ELENA VENTURA
<eleve...@gmail.com> escreveu:
>
> Hello,
>
> I am currently conducting Wi-Fi slicing experiments on Mininet-WiFi using 10 Access Points (APs) and 10 corresponding wired hosts.
>
> I have implemented a real-time controller that dynamically edits and applies a .sh script to each AP, in order to update the HTB/IFB slicing configuration based on the current priority of each vehicle in the simulation.
> Since my topology includes multiple Access Points, a separate controller instance is created for each AP.
> This mechanism successfully generates and applies per-AP slicing configurations in real time.
>
> However, during experiments I have noticed that the throughput of several APs occasionally drops to zero, even though the per-AP scripts are being applied correctly.
> When running the same setup with only one AP, the system works perfectly and the throughput remains stable.
> This led me to suspect that the issue may be related to the use of multiple IFB interfaces across APs, which might not be fully isolated between namespaces.
>
> Below is an example of what happens when I start the controller for ap10 without any station connected (only the default slice is configured).
>
> #!/bin/bash
>
> echo "[+] Inizializzo HTB su ap10-wlan1 (egress)"
>
> # Pulizia configurazioni precedenti
>
> tc qdisc del dev ap10-wlan1 root 2>/dev/null
> tc qdisc del dev ap10-wlan1 ingress 2>/dev/null
> tc qdisc del dev ifb_ap10 root 2>/dev/null
> ip link set ifb_ap10 down 2>/dev/null
> ip link delete ifb_ap10 type ifb 2>/dev/null
>
> # Parte 1: traffico in uscita da {IF}
>
> tc qdisc add dev ap10-wlan1 root handle 1: htb default 30
> tc class add dev ap10-wlan1 parent 1: classid 1:1 htb rate 7mbit ceil 7mbit
>
> # DEFAULT slice
> tc class add dev ap10-wlan1 parent 1:1 classid 1:30 htb rate 7mbit ceil 7mbit
> tc qdisc add dev ap10-wlan1 parent 1:30 handle 30: pfifo limit 100
>
> # Filter per traffico in uscita (server -> stazioni)
>
>
> echo "[+] Configuro IFB per ingress shaping su ap10-wlan1"
>
> # Parte 2: traffico in ingresso su ap10-wlan1
>
> modprobe ifb
> ip link add ifb_ap10 type ifb
> ip link set ifb_ap10 up
>
> # Redirige tutto l'ingresso di ap10-wlan1 su ifb_ap10
>
> tc qdisc add dev ap10-wlan1 ingress
> tc filter add dev ap10-wlan1 parent ffff: protocol ip u32 match u32 0 0 \
> action mirred egress redirect dev ifb_ap10
>
> # Shaping su {IFB} (traffico da stazioni verso server)
>
> tc qdisc add dev ifb_ap10 root handle 2: htb default 10
> tc class add dev ifb_ap10 parent 2: classid 2:1 htb rate 7mbit ceil 7mbit
>
> # Slice 2:20 unica per tutte le stazioni
> tc class add dev ifb_ap10 parent 2:1 classid 2:20 htb rate 7mbit ceil 7mbit
> tc qdisc add dev ifb_ap10 parent 2:20 handle 20: pfifo limit 100
>
>
> echo "Configurazione completa (egress + ingress con IFB)"
>
> Some APs begin to transmit normally, while others remain at 0 Mbps until the first group finishes — as if the traffic were serialized across APs.
>
> I would like to ask:
>
> Could this behavior be due to the IFB mechanism being global at the kernel level (i.e., a shared workqueue among all IFB devices)?
>
> Are IFB devices truly independent in Mininet-WiFi, or do they share a single kernel namespace for packet scheduling?
>
> What would be, in your opinion, the most correct way to achieve ingress shaping per AP (for example, replacing IFB with veth pairs, or using tc-mirred differently)?
>
> Finally, could there be any formal limitation in Mininet-WiFi or the Linux traffic control subsystem that explains this serialized throughput?
>
> Any clarification or insight on this IFB behavior would be very helpful, Thank you very much
>
> Best regards,
> Elena
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/mininet-wifi-discuss/0d116a59-73a8-450b-8972-f85888933157n%40googlegroups.com.

[ELENA VENTURA]

Hi Ramon,
I’ve realized the problem wasn’t actually what I thought. Thanks a lot for your reply!