[Cake] overhead for double nat VDSL2 connection
Mark Captur
mark.captur at gmail.com
Sun Dec 17 22:56:17 EST 2017
Thank to both of you!
On 17 December 2017 at 23:35, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 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...
>
Yes if i use link layer cake explicitly (option linklayer_advanced ‘1’ &
option linklayer_adaptation_mechanism ‘cake’) it works better i.e. higher
bandwidth with no effect on pings
>
> > 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...
>
I agree i though that by leaving linklayer_advanced off i was allowing it
to choose default i.e. cake! what about max_len below? is that ok?
qdisc cake 802b: dev eth0.1 root refcnt 2 bandwidth 30Mbit diffserv3
dual-dsthost nat rtt 50.0ms noatm overhead 30 via-ethernet total_overhead
30 hard_header_len 14 mpu 64
Sent 169756771 bytes 121528 pkt (dropped 4732, overlimits 118063 requeues
0)
backlog 8352b 6p requeues 0
memory used: 80640b of 4Mb
capacity estimate: 30Mbit
Bulk Best Effort Voice
thresh 1875Kbit 30Mbit 7500Kbit
target 9.7ms 2.5ms 2.5ms
interval 57.2ms 50.0ms 50.0ms
pk_delay 0us 3.2ms 1.6ms
av_delay 0us 2.3ms 283us
sp_delay 0us 324us 18us
pkts 0 125657 609
bytes 0 176142105 205486
way_inds 0 0 0
way_miss 0 61 2
way_cols 0 0 0
drops 0 4732 0
marks 0 0 0
ack_drop 0 0 0
sp_flows 0 0 0
bk_flows 0 1 0
un_flows 0 0 0
max_len 0 3012 2032
qdisc cake 8029: dev eth0.2 root refcnt 2 bandwidth 2440Kbit diffserv3
dual-srchost nat rtt 50.0ms noatm overhead 30 via-ethernet total_overhead
30 hard_header_len 14 mpu 64
Sent 7184293 bytes 74928 pkt (dropped 99, overlimits 46203 requeues 0)
backlog 54b 1p requeues 0
memory used: 155232b of 4Mb
capacity estimate: 2440Kbit
Bulk Best Effort Voice
thresh 152496bit 2440Kbit 610Kbit
target 119.1ms 7.4ms 29.8ms
interval 238.3ms 54.9ms 77.3ms
pk_delay 0us 1.3ms 526us
av_delay 0us 272us 10us
sp_delay 0us 9us 10us
pkts 0 75018 10
bytes 0 7200943 1290
way_inds 0 1 0
way_miss 0 73 8
way_cols 0 0 0
drops 0 99 0
marks 0 0 0
ack_drop 0 0 0
sp_flows 0 1 0
bk_flows 0 1 0
un_flows 0 0 0
max_len 0 3008 288
>
>
> >
> >>
> >> 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
Thanks & regards
Mark
>
> >
> > GPG fingerprint: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171218/7b9408db/attachment-0001.html>
More information about the Cake
mailing list