[Cake] overhead for double nat VDSL2 connection
Kevin Darbyshire-Bryant
kevin at darbyshire-bryant.me.uk
Sun Dec 17 14:23:40 EST 2017
> 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’. 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 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)
>
> 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.
> 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
GPG fingerprint: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171217/df0289bb/attachment.sig>
More information about the Cake
mailing list