From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Mark Captur <mark.captur@gmail.com>,
"cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] overhead for double nat VDSL2 connection
Date: Sun, 17 Dec 2017 19:23:40 +0000 [thread overview]
Message-ID: <0FF17103-0A62-4645-98AC-E1680C4711E8@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <73C84EA7-2ADD-4914-BBDE-92E8408C106F@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 3701 bytes --]
> On 17 Dec 2017, at 15:23, Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Hi Mark,
>
>> On Dec 17, 2017, at 11:45, Mark Captur <mark.captur@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
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-12-17 19:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-17 10:45 Mark Captur
2017-12-17 15:23 ` Sebastian Moeller
2017-12-17 16:00 ` Mark Captur
2017-12-17 22:30 ` Sebastian Moeller
2017-12-17 19:23 ` Kevin Darbyshire-Bryant [this message]
2017-12-17 22:35 ` Sebastian Moeller
2017-12-18 3:56 ` Mark Captur
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0FF17103-0A62-4645-98AC-E1680C4711E8@darbyshire-bryant.me.uk \
--to=kevin@darbyshire-bryant.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=mark.captur@gmail.com \
--cc=moeller0@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox