netdev - Re: tc-cake(8) needs to explain a common mistake

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAN_LGv2ujqBWQv_f5Co0-hMtBedgCcqRRzpJ7mc1DMW+FaqhqA@mail.gmail.com>
Date:   Fri, 3 Apr 2020 23:55:48 +0500
From:   "Alexander E. Patrakov" <patrakov@...il.com>
To:     netdev@...r.kernel.org
Subject: Re: tc-cake(8) needs to explain a common mistake

On Fri, Apr 3, 2020 at 11:44 PM Alexander E. Patrakov
<patrakov@...il.com> wrote:
>
> Hello,
>
> there is a recurring cargo cult pattern in many forums (e.g. OpenWRT):
> people keep suggesting various overhead compensation parameters to
> tc-cake without checking what's the bottleneck. They just assume that
> it is always related to the link-layer technology of the connection.
>
> This assumption is mostly incorrect, and this needs to be explained in
> the manual page to stop the cargo cult. E.g., here in Russia, in the
> past year, I had a 1Gbit/s link (1000BASE-X) but they shaped my
> connection down to 500 Mbit/s because that's the bandwidth that I paid
> for. I.e. the link from my router to the ISP equipment was not the
> bottleneck, it was the ISP's shaper.
>
> How about the following addition to the tc-cake(8) manual page, just
> before "Manual Overhead Specification"? Feel free to edit.
>
> General considerations
> -------------------------------
>
> Do not blindly set the overhead compensation parameters to match the
> internet connection link type and protocols running on it. Doing so
> makes sense only if that link (and not something further in the path,
> like the ISP's shaper) is indeed the bottleneck.
>
> Example 1: the ADSL modem connects at 18 Mbit/s, but the ISP further
> throttles the speed to 15 Mbit/s because that's what the user pays
> for, and does so with a shaper that has bufferbloat. Then, the "adsl"
> keyword is likely not appropriate, because the ISP's shaper operates
> on the IP level. The bandwidth needs to be set slightly below 15
> Mbit/s.

Self-correction: there is no "adsl" keyword. Let's replace it with
"pppoe-llcsnap" (the most common setup), or: "ADSL overhead keywords
are likely not appropriate".


> Example 2: the ADSL modem connects at 18 Mbit/s, and the user pays for
> "as fast as the modem can get" connection. Then, the "adsl" keyword is
> relevant, and the bandwidth needs to be set to 18 Mbit/s.

Same here: "one of the ADSL overhead keywords is relevant".

> Example 3: the user has a 100BASE-TX Ethernet connection, and pays for
> the full 100 Mbit/s bandwidth (i.e. there is no shaper further up).
> Then, the "ethernet" keyword is relevant, and the bandwidth needs to
> be set to 100 Mbit/s.
>
> --
> Alexander E. Patrakov
> CV: http://pc.cd/PLz7



-- 
Alexander E. Patrakov
CV: http://pc.cd/PLz7