From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 B52653B29E for ; Tue, 24 Jul 2018 16:57:43 -0400 (EDT) Received: by mail-qt0-x236.google.com with SMTP id m13-v6so5619018qth.1 for ; Tue, 24 Jul 2018 13:57:43 -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=m2jX9yC9j90sPOs/JISLk+C+WWOMacLjpvTauReZjbU=; b=Tan8SRtv29YESe7gJ0spZfd6Nur39S19zwQYBOlOmPem9KjUt/Z9z0/a8gSPDiVkI3 YOXTM4QN5sYFTNxroCC31v8o+L39MmpyXL8nmRwzv6/DS1aCff7kfBoTIOh20BXOmXKf 4gNzdp++jC8vQFR+9IfZjfX6VzMFfPlA1z9X7Gg5H5wBH5xX2Yl5w+jkJyamhZ+EG2l/ yUynk9GqSC4kGHfVAllIbY86cbZmUsc6jsE+ywDgfMeheF8zgvdA8039xaIP/kMVSyLM dEDPyie8JegyY9HYVGjHxZdPnuHAvIvFy+Zoj+gRtlpNfgBxpQl1ws6Do1jk53+MuRT/ SWYg== 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=m2jX9yC9j90sPOs/JISLk+C+WWOMacLjpvTauReZjbU=; b=WDupuqp2+2W9e/TPFSCaSve5tvOzS3V2jGugQVREth2t/BZQK239GEZ6l2Pv1EP3Dn 1Oudou/aR/gaLgdmZjKbQ95dVEqHv1knpe2+I5kUjGcf5N47Qpt7fAvdR4UHUB2xSQgo O9aottF767sPC2L0W9lL8hmSJMlhVWqpAOHQuJR8FvVnzEsNgOgypMWNvHjPx6zYTnUu lCNtSFEmnvrvNzl7DsAGcZEiR3ohXpcQSlXyWgOedDWaTX0kwe3BbsZGqCTshBe439WB X++7jL+Vrip5yDLXJYxeFvUYaYbjK6/Q6vZT1EyLXGpxJC3uLzZH3nSinq/Emrj8ukhC LPXA== X-Gm-Message-State: AOUpUlGVEFrPjqkPVL86FOGvIzopexI9NybIkxYnr9ai3Wc5Jc+Gjv6Z TfVu5jDSAIkDOjhLiZ95qenOM1Y0qTWHX5YOe7Y= X-Google-Smtp-Source: AAOMgpdyzJwSK+Ti9J/8nJs4NS+muwn3oghZqgrLxpcmsZX5Y51IZ+mltLhY4wd31i2f/GRnfloQ4wXUNpKj8GfcGvo= X-Received: by 2002:ac8:31cd:: with SMTP id i13-v6mr18072748qte.144.1532465863254; Tue, 24 Jul 2018 13:57:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Tue, 24 Jul 2018 13:57:31 -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 20:57:43 -0000 On Tue, Jul 24, 2018 at 1:11 PM Benjamin Cronce wrote: > > Maybe the Bobbie idea already would do this, but I did not see it explici= tly 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 nothin= g is perfect and their implementation of rate limiting has a kind of burst = at the start. According to speedtests, my 250Mb connection starts off aroun= d 500Mb/s and slowly drops over the next few seconds until a near perfect 2= 50Mb/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. > The burst at the beginning adds a certain amount of destabilization to th= e TCP flows since the window quickly grows to 500Mb and then has to backdow= n by dropping. If I add my own traffic shaping and AQM, I can reduce the re= ported TCP retransmissions from ~3% to ~0.1%. sure. > > The problem that I'm getting is by adding my own shaping, a measurable am= ount 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 anti-buf= ferbloat than my ISP is. Fewer latency spices according to DSLReports. ? measured how. > > This also does not touch on that the act of adding back-pressure in its n= ature increases latency. I cannot say if it's a fundamental requirement in = order to better my current situation, but I am curious if there's a better = way. A thought that came to me is that like Bobbie, do a light touch as the= packets have already made their way and you don't want to aggressively dro= p packets, but at the same time, I want the packets that already made the j= ourney to mostly unhindered enter my network. > > That's when I thought of a backpressure-less AQM. I like the restating of what policers do.... >Instead of having backpressure and measuring sojourn time as a function of= how long it takes packets to get scheduled, predict an estimated sojourn t= ime based on the observed rate of flow, but allow packets to immediately va= cate the queue. The AQM would either mark ECN or drop the packet, but never= delay the packet. aqms don't delay packets. shapers do. > In summary, my ISP seems to have better latency with their AQM, but due t= o 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? > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619