Re: [Bloat] Stab overhead caliculation and mpu for ingress shaping.

[Sebastian Moeller <moeller0@gmx.de>]

Hi Yuta,

> On Mar 1, 2017, at 19:37, Y <intruder_tkyf@yahoo.fr> wrote:
> 
> Hi , all.
> 
> I set root qdisc for traffic shaping like this
> 
> egress
> $tc qdisc add dev $ext_ingress root handle 1: stab overhead -4
> linklayer atm mpu 60 mtu 2048 tsize 256 hfsc default 13
> 
> ingress
> $tc qdisc add dev $ext root handle 1: stab overhead -4 mpu 53 linklayer
> atm mtu 2048 tsize 256 hfsc default 26
> ($ works at script )
> 
> PPPoA WAN - modem/router - Ethernet LAN - My pc 1 interface.
> 
> engress overhead of PPPoA via ethernet is -4

	So that indicates PPPoA VC/Mux, as encapsulation, correct? BUT that -4 assumes that the kernal already silently added 14 bytes to the packet size, which it does for ethernet interfaces. So is the traffic shaper running on the modem-router’s ATM interface directly or on your PC1? I typically would try to run https://github.com/moeller0/ATM_overhead_detector to empirically figure out the per packet overhead (but I note that this has never been tested with PPPoA data as far as I can remember)

> and mpu 53.

	As far as I can tell with the linklayer ATM keyword the kernel will basically increase any runt packet to 53 automatically, so this seems redundant. (Linklayer atm will multiply the packet size by 53/48 and will also make packet size to be integer multiple of ATM cell size)


> This is certain.
> We can think without Ethernet padding at stab.

	No, I disagree, _if_ the PPPoA packets exclude the padding we can ignore it but not otherwise… 

> 
> My asking is whether that This is also correct at ingress shaping or
> not?
> 
> mpu for ingress in myscript = 60.
> Because of minimal ethernet packet size = 60( with padding without FCS)

	I would assume this to be correct in your case

> 
> oevrhead for ingress in myscript = -4.
> Because I want to shape connection , so , must set speed setting * 48 /
> 53.

	No, that is what linklayer atm does for you (and also the accounting for the required padding to always use an integer number of ATM cells per user packet).

Best Regards

> 
> This is certain or not?
> 
> Yuta. 
> 
> For example. 
> see this section (Extensive framing compensation (for DSL/ATM/PPPoe))
> https://www.bufferbloat.net/projects/codel/wiki/Cake/
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat