From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 C88D53B29E for ; Tue, 24 Jul 2018 18:12:10 -0400 (EDT) Received: by mail-qt0-x22b.google.com with SMTP id c15-v6so5801552qtp.0 for ; Tue, 24 Jul 2018 15:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=34D8GJMfxEyzQYNOaexlCmAi41U2o3KLhMSfG9y4QHE=; b=Xo4hscMPiTwGFMRJQjrqZ8t5IOtMUdkFNpl3AjEd+EXoebvuHItdSf2KiApBsBOGf2 si3jTCT33vHpyyRwVKSeSZEZQcOrQEXFink8D7b9c3LaWkqJUCi4cKY9rIyazmPt44Yn CoNgsQ9gXkqxN0tXSz13yQkwzqc+bGtUayEszTKUs6783cdAB9jQsYaMwxrUqBze6kE4 2T6/q3vIjdpkRJkdygsV+UJWhhyZxEfp3JK+e3GmQWqR9ODZIWbNv+5u12wn3K+1zyzr kMeZdBca9V06PhIp8xNOI8NaKOIpUeEysE+dFS40DT3UHbWCgigM0VBspRo8H8BZJeLr Jaxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=34D8GJMfxEyzQYNOaexlCmAi41U2o3KLhMSfG9y4QHE=; b=h74+ya3PM8jwJA/FEDtZTDNJ3hkYPghZt/nhgW7HATXU98ODb6jFSduvldgUprzN+t lRurGel73niFvU58BCUc1ODfjzI3mQdI7T6p6HsF9tZH5LLeK/HT9nRkzG74sFC9E4rH lKwRZWUIaL9N17uYTjbltf84wqUSngjuNLMpIEUs6munFRo4DLL+TE0cXNTMJiJAd82K Wp9wx9vsMp8oXK2cVflevd78nNQhUVZJGUq52XQ3JSYFMMSmBOZdWeMKYwmxsfqZEW10 CY9oqVTkSdRcTgeBB56sjGeAq5bZYAFmJgC7m6TGUk1mm1+KtfWvZEcSe3IfSCC/QBCT 4P4Q== X-Gm-Message-State: AOUpUlG3VcTJx+PiKTckCC4zlt1fOqE3zTB3FAS7GDhH/wqLZ5LYY4S4 SlcDhtF/atSbkTMAK0w8qd2JbpWqDTSX0g8SGpg= X-Google-Smtp-Source: AAOMgpesZBq5XU5qF11B5RyZwun6hcjKeHsy9UYnYnpa5vdPGp40ST92OqH2iKKB2ikUVjSLyq8QhzeACe8w7om2jGE= X-Received: by 2002:aed:2686:: with SMTP id q6-v6mr18123991qtd.199.1532470330335; Tue, 24 Jul 2018 15:12:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Tue, 24 Jul 2018 15:12:04 -0700 Message-ID: To: Benjamin Cronce Cc: bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] No backpressure "shaper"+AQM X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 22:12:10 -0000 On Tue, Jul 24, 2018 at 2:58 PM Dave Taht wrote: > > On Tue, Jul 24, 2018 at 2:39 PM Benjamin Cronce wrote= : > > > > > > > > On Tue, Jul 24, 2018 at 3:57 PM Dave Taht wrote: > >> > >> On Tue, Jul 24, 2018 at 1:11 PM Benjamin Cronce wr= ote: > >> > > >> > Maybe the Bobbie idea already would do this, but I did not see it ex= plicitly mentioned on its wiki. > >> > >> you are basically correct below. bobbie's core idea was a kinder, > >> gentler, deficit mode policer, with something fq_codel-like aimed at > >> reducing accumulated bytes to below the set rate. > >> > >> this is way different from conventional policers > >> > >> > The below is all about shaping ingress, not egress. > >> > > >> > My issue is that my ISP already does a good job with their AQM but n= othing is perfect and their implementation of rate limiting has a kind of b= urst at the start. According to speedtests, my 250Mb connection starts off = around 500Mb/s and slowly drops over the next few seconds until a near perf= ect 250Mb/s steady state. > >> > >> ideally their htb shaper would use fq_codel as the underlying qdisc. > >> Or at least reduce their burst size to something saner. I hope it's > >> not a policer. > >> > >> You can usually "see" a policer in action. Long strings of packets are > >> dropped in a row. > > > > > > I feel as if this new configuration is not quite a policer as it feels = much less abrupt as the old configuration. It used to have massive loss spi= kes that wrecked havoc on other flows and make the fat TCP flows have a kin= d of rebound. Their newer setup seems to be gentler. While there is an incr= eased rate of loss as it attempt to "slowly" settle at the provisioned rate= , it's not like the cliff it used to be, it actually has a slope. > > well, ask 'em. > > >> > >> > >> > The burst at the beginning adds a certain amount of destabilization = to the TCP flows since the window quickly grows to 500Mb and then has to ba= ckdown by dropping. If I add my own traffic shaping and AQM, I can reduce t= he reported TCP retransmissions from ~3% to ~0.1%. > >> > >> sure. > >> > >> > >> > >> > >> > > >> > The problem that I'm getting is by adding my own shaping, a measurab= le amount of the benefit of their AQM is lost. While I am limited to Codel,= HFSC+Codel, or FairQ+Codel for now, I am actually doing a worse job of ant= i-bufferbloat than my ISP is. Fewer latency spices according to DSLReports. > >> > >> ? measured how. > > > > Just looking visual at the DSLReport graphs, I more normally see maybe = a few 40ms-150ms ping spikes, while my own attempts to shape can get me sev= eral 300ms spikes. I would really need a lot more samples and actually run = the numbers on them, but just causally looking at them, I get the sense tha= t mine is worse. > > too gentle we are perhaps. out of cpu you may be. > > >> > >> > >> > > >> > This also does not touch on that the act of adding back-pressure in = its nature increases latency. I cannot say if it's a fundamental requiremen= t in order to better my current situation, but I am curious if there's a be= tter way. A thought that came to me is that like Bobbie, do a light touch a= s the packets have already made their way and you don't want to aggressivel= y drop packets, but at the same time, I want the packets that already made = the journey to mostly unhindered enter my network. > >> > > >> > That's when I thought of a backpressure-less AQM. > >> > >> I like the restating of what policers do.... > > > > I think I need to look at the definition of a policer. I always through= them as a strict cut-off. I'm not talking about mass dropping packets beyo= nd a rate, just doing something like Codel where a packet here and there ge= t dropped at an increasing rate until the observed rate normalizes. > > bobs below the set rate long enough to drain the queue upstream. s/queue/tbf > > >> > >> > >> >Instead of having backpressure and measuring sojourn time as a functi= on of how long it takes packets to get scheduled, predict an estimated sojo= urn time based on the observed rate of flow, but allow packets to immediate= ly vacate the queue. The AQM would either mark ECN or drop the packet, but = never delay the packet. > >> > >> aqms don't delay packets. shapers do. > > > > My described "AQM" is not a shaper in that it does not schedule packets= (possibly FIFO and at line rate), but does understand bandwidth. It neither= delays packets nor has a strict cut-off. It essentially would allow packet= s to flow through at line rate, but if the "average" rate gets too high, it= may decide to drop/mark the next packet. It might be described as bufferle= ss shaping where the goal is to minimize packet-loss. Shaping purely by a g= entle rate of increasing loss. > > sure. > > > > > Of course this whole thought may be total rubbish, but I figured I'd th= row it out there. > > not rubbish, could be better than policing. > > >> > >> > >> > In summary, my ISP seems to have better latency with their AQM, but = due to their shaper, loss during the burst is much higher than desirable. > >> > > >> > Maybe this will be mostly moot once I get fq_codel going on pfSense,= but I do find it an interesting issue. > >> > >> I thought it's been in there for a while? > > > > Technically, but not practically. It should be easily available via the= UI with 2.4.4 which is slowly nearing release. > >> > >> > >> > _______________________________________________ > >> > Bloat mailing list > >> > Bloat@lists.bufferbloat.net > >> > https://lists.bufferbloat.net/listinfo/bloat > >> > >> > >> > >> -- > >> > >> Dave T=C3=A4ht > >> CEO, TekLibre, LLC > >> http://www.teklibre.com > >> Tel: 1-669-226-2619 > > > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619