From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CD4823B29E for ; Sun, 12 Apr 2020 05:47:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586684867; bh=6czje6f9THps8sFZ6qGBq0LOC3jnro2sV4WaXEOvaTg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=LUUa9IjxsuxQWaMnUG8K0n2Y7MA/PTw1vC6AAeZ0i5SI4MsrD+kKkAvnsQWi++WBo B2oUTdre/pTP5kaL5sqqv2HFa3IKWRksZzIXtJOj7BR87CNB1e9k/GKqLzte446P+Y 0/L0gG14RApeFWOTHMC4j9PXbVRreWgaLoYZBopY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hms-beagle2.lan ([95.116.245.149]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MV67y-1joPjx0rR8-00SAVI; Sun, 12 Apr 2020 11:47:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 12 Apr 2020 11:47:46 +0200 Cc: Jonathan Morton , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <621590AF-C71F-4FA0-8D5D-29461BEE3AFA@gmx.de> References: <7BD9FB5D-7577-477A-9FF0-7BF90043C27B@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:FTykvCzlb+JEQ5zYCl8qxmOB85rbCGNzaMQH7oOcHTFlhPqmSix PY0J/WHFI+Z3M0eBVI5m2ZzQvwO7mKwa3GxEpGDAGgfnzoT2QgqCna/Cf1eRNmRJ09p/1+C i4q7ngtGv6EWurUb8A/8StbMuOV0ybK0UoKdin763ItRCASONT/7YaGafBD1ZBPFPZOs6qk w2UZP7b2kJFWG/tvW3jnA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:xeM+aEsy0yg=:g37AkhTbLG5MfAyzUki9dH bqs7ZfNVAdc+ImFhfO2XjUOXTqyqxeCvHZWJEKfF/AkvkT8zHUDwfr2+cQoR4IPmHV9wlJdG7 CRmh7xnTi0dkisKB5h2KvC3R1IcdD5tmCkm4o4YsHchaLxTN+EGOxup/qQGPqfJJ2nEpSICgl 00wqNKDP+FPis557qOAI13JUmanY8m5j7zo6B2V1XCfHE9anQDuIv6xgkvkXngxDu65XjMNua bIrnwC5YBqpdi7jKnvZ+nP7Gp4RPnZfGIxCEpIfjNSpB4Bif43EOWVTV82dH2jWQ/HVqyRW+G ih+nR4FSS1IvvJV7KLTBrI2UyLabmW2rr21+o7dkL5UTq6zbuCqqZXlgRaYF8Gt/oCQ3AWcW0 ZPiRp3WRGdwMSEm/3xUmac4cLhkx5UdaLGfUaBUn9XsaswbLMss9qZUAFPv9XPkGds3hBQQT5 SjsqziD5ETPKKjBDVN2OCSRM2JzCZ7NUXijlGvQ5X9XVGDfkkcvZudD/InE00xRWyBlsO0W3Q NJ+HH27q22Z7tK+5ml/9NEbaI4VWGoSX2yY/tBnF4L1h/6X6SJKVxJ2VZg8PMLVsNbu0aHm1T IkxAhchJ8Nb0KiUc8d7ZacqRjuDjebvxY4U/tF64lnp2k+mXo55JMA9/oHbuRqXPxgzxaBhsh pFaBXri2x7aTh3VzPfz6pM5EzEA5XjCCJTyDsd6pmOHKpxvU+ik5eaHuANZrp8owPDvSFcfxH uHpqZJiqjsULfX3Bu+wHIteDYpNcsYXBlSMIrLpNGcMh6rs8bODVzhyEPFpdD1wK5TK6ADXCZ qP9Ov4avdLpfaXDMVl6ilwdBiVuNI2YitF1swU1vqDDh+qkCeaa/0uKr/esYtNmCHL6T/0/Hl qJjSSV6Ptc0hRdiCMXt479AtHX+PUBt23P4Eg93SxgpDq+pcq30O6YV9tm+rK+q3uWx3kJuaA UjlpfOIkJr6I7iLXfGaLaiBduTv5XcUQE0j4y4GnyU9xGxiEDoWnhF5ad1X6Tk5TAtkcAhMJ+ qlSyjgos/N2Y0xwfnnBL/9S6dz+7LmFfiXGOmtewkhdT4kxB/CiI4hZy50XOKgdS2YolYKevq RgMsGkq6LMouTed8mjId82PSYI9DijWBe/s7aUkTiSULF/pjMeGJlFLFdvka+N3babvOxkKQN LhbfLlbfDtOCdw3kGsKzRErgvB2ryfP+eK8HtZ/FAdiY5iDOqmpbUhjgzxEMPGrmOnHZi/pRS ObBADmt0+NuPAFqTa Subject: Re: [Cake] Thinking about ingress shaping & cake X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 09:47:51 -0000 Hi Kevin. > On Apr 12, 2020, at 10:23, Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 >> On 10 Apr 2020, at 15:14, Jonathan Morton = wrote: >>=20 >>=20 >> No. If the dequeue rate is never less than the enqueue rate, then = the backlog remains at zero pretty much all the time. There are some = short-term effects which can result in transient queuing of a small = number of packets, but these will all drain out promptly. >>=20 >> For Cake to actually gain control of the bottleneck queue, it needs = to *become* the bottleneck - which, when downstream of the nominal = bottleneck, can only be achieved by shaping to a slower rate. I would = try 79Mbit for your case. >>=20 >> - Jonathan Morton >>=20 >=20 > Thanks for correcting my erroneous thinking Jonathan! =20 I can not see erroneous thinking here at all, you just = independently discovered the approximate nature of post-bottleneck = traffic shaping ;) As I see it, this theoretical concern made people = ignore ingress shaping for far too long. As the bufferbloat effort = demonstrated even approximate traffic shaping help considerably. And = Jonathan's "ingress" mode for cake make that approximation less = dependent on the number of concurrent flows, so as so often cake turns = it up to eleven ;) > As I was typing it I was thinking =E2=80=9Chow does that actually = work?=E2=80=9D I should have thought more. You identified the core issue of ingress shaping quite = succinctly for the rest there is the mailing list. > I typically run ingress rate as 97.5% of modem sync rate (78000 of = 80000) which is gives me a little wiggle room when the modem doesn=E2=80=99= t quite make the 80000 target (often 79500ish). Egress is easy, 99.5% of = 20000 ie. 19900, all is wonderful. Those were the good old days, when I could just assume the sync = rate would be the limiting factor, over on this side of the channel ISP = pretty much all switched to use traffic shapers at their end (typically = not in the DSLAM which seems to be more or less just a L2 switch with = fancy media-converters for the individual subscriber lines). Getting = reliably information about the setting of these shapers is near = impossible... (And yes, the ISPs also seem to shape my egress, so have = to deal with approximate shaping at their end as well). My current = approach is to make a few speedtests without SQM enabled take my best = estimate of the applicable maximum speed (this is harder than it looks, = as a number of speedtests are really imprecise and try to get = instantaneous rate estimates, which suffer from windowing effects, = resulting in reported speeds higher than a DSL link can theoretically = carry maximally). Then I take this and just plug this net rate into sqm = as gross shaper rate and things should be a decent starting point (plus = my best theoretical estimate of the per-packet-overhead PPO).=20 Since I usually can not help it, I then take my PPO estimate and reverse = the gross rate from the net rate, e.g. for = VDSL2/PTM/PPPoE/IPv4/TCP/RFC1323Timestamps) gross shaper rate =3D net speedtest result * 65/64 * ((1500 + 26) / = (1500 - 8 - 20 -20 -12)) and compare this with my sync rate, if this is <=3D my syncrate I then = set: egress gross shaper rate =3D egress net speedtest result * ((1500 + 26) = / (1500 - 8 - 20 -20 -12)) * 0.995 ingress gross shaper rate =3D ingress net speedtest result * ((1500 + = 26) / (1500 - 8 - 20 -20 -12)) * 0.95 if the calculated rate is > my syncrate I repeat with a different = speedtest, while mumbling and cursing like a sailor... >=20 > I=E2=80=99m wondering what the relationship between actual incoming = rate vs shaped rate and latency peaks is? Good question! My mental image is bound to the water and pipe = model of the internet (series of tubes ;)) if the inrush is too high for = the current bottleneck element/pipe there is going to be "back-spill" = into the buffers upstream of the bottleneck. So, bursts and DOS traffic = will flood back into the ISPs typically under-managed and over-sized = buffers increasing the latency. > My brain can=E2=80=99t compute that but I suspect is related to the = rtt of the flow/s and hence how quickly the signalling manages to = control the incoming rate. I agree. >=20 > I guess ultimately we=E2=80=99re dependent on the upstream (ISP) = shaper configuration, ie if that=E2=80=99s a large buffer and we=E2=80=99v= e an unresponsive flow incoming then no matter what we do, we=E2=80=99re = stuffed, that flow will fill the buffer & induce latency on other flows. Yes, but this is where cake's ingress mode helps, by aiming its = rate target to the ingress side it will effectively send stronger signal = so that the endpoints react faster reducing the likelihood of = back-spill. But in the end, it would be a great help if the ISP's shaper = would have acceptable buffer management... Best Regards Sebastian >=20 >=20 > Cheers, >=20 > Kevin D-B >=20 > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake