[Cake] overhead for double nat VDSL2 connection

[Sebastian Moeller]

Hi Kevin, hi Mark,

Kevin is 100% right!

> On Dec 17, 2017, at 20:23, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
> 
> 
> 
>> On 17 Dec 2017, at 15:23, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>> Hi Mark,
>> 
>>> On Dec 17, 2017, at 11:45, Mark Captur <mark.captur at gmail.com> wrote:
>>> 
>>> My setup is as follows
>>> 
>>> vdsl2 modem doing pppoe itself and nat to 10.x.x.x -> lede master eth0.2 (wan static ip in modem's DMZ) eth0.1 (lan) doing nat to 192.168.1.x
>>> 
>>> Here is my current SQM config
>>> config queue 'eth1'
>>>       option debug_logging '0'
>>>       option verbosity '5'
>>>       option qdisc 'cake'
>>>       option qdisc_advanced '1'
>>>       option ingress_ecn 'ECN'
>>>       option egress_ecn 'NOECN'
>>>       option qdisc_really_really_advanced '1'
>>>       option script 'layer_cake.qos'
>>>       option interface 'eth0.2'
>>>       option enabled '1'
>>>       option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-srchost diffserv4'
>>>       option upload '2400'
>>>       option linklayer 'ethernet'
>>>       option overhead '8'
>>>       option squash_dscp '1'
>>>       option squash_ingress '1'
>>>       option iqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost'
>>>       option download '0'
>>> 
>>> config queue
>>>       option debug_logging '0'
>>>       option verbosity '5'
>>>       option download '0'
>>>       option qdisc 'cake'
>>>       option script 'layer_cake.qos'
>>>       option qdisc_advanced '1'
>>>       option squash_dscp '0'
>>>       option squash_ingress '0'
>>>       option ingress_ecn 'ECN'
>>>       option qdisc_really_really_advanced '1'
>>>       option egress_ecn 'ECN'
>>>       option interface 'eth0.1'
>>>       option enabled '1'
>>>       option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost diffserv4'
>>>       option upload '30000'
>>>       option linklayer 'ethernet'
>>>       option overhead '8'
>>> 
>>> Is the overhead correct? should i use the bridged-ptm keyword (or should i use pppoe-ptm).
> 
> 
> Beware of using  option linklayer ‘ethernet’ without option linklayer_advanced ‘1’ & option linklayer_adaptation_mechanism ‘default’.  Or use linklayer ‘none’.  

I guess "linklayer cake" would be better than none...

> Failure to do so will make sqm-scripts use STAB for the link accounting (in essence it lies to cake about the size of packets being passed through it).  Better to use cake’s built-in compensation - fewer modules, less code.

	I agree, even though for ptm this is less dire than for ATM; still use linklayer default or linklayer cake.

> 
> I was bitten by this myself very recently, lost 4 hours of my life & many recompiles before I realised an innocent looking setting (linklayer_advanced) was messing with the packet size (seen by looking at max_len from tc)

	I am beginning to wonder whether the attempt to hide complexity behind linklayer_advanced is not simply misguided and should be jettisoned...



> 
>> 
>> 	The overhead certainly seems confusing. Personally, I dislike the overhead related compound keywords like *-ptm and would recommend the following:
>> 1) remove the bridged-ptm from the eqdisc/iqdisc fields
>> 2) add "mpu 64" to the eqdisc/iqdisc fields
>> 3) set overhad to 8+18+4 = 30 bytes (you will need to account for everything added on the bottleneck, so your packets will be MTU 1492, to leave room for the PPPoE header that the modem adds).
> MTU 1492 ain’t necessarily so - some vdsl modems in bridge mode support RFC 4638 with baby jumbo frames, thus supporting the normal ethernet MTU of 1500 (and obviating the need to TCP MSS clamping) - ie. if you can do it, you should ;-).  You still need to account for the 8 byte PPPOE overhead of course.

	And again, Kevin is correct; my rationale might have been faulty but the recommendation still was correct though ;)...


>> 4) DO not set the ptm keyword at all, instead make sure to set the shaper bandwidth to <= sync bandwidth * 64/65 = sync bandwidth * 0.984615384615 (to account for ptm's 64/65 encoding _without_ incurring needless operations per packet).
>> 
>> 4) tell us about your ISP and plan ;)
>> 
> Cheers,
> 
> Kevin D-B

Thanks for your input, as always very much appreciated!

Best Regards
	Sebastian


> 
> GPG fingerprint: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A