From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 B7B513B29E for ; Tue, 24 Jul 2018 16:11:13 -0400 (EDT) Received: by mail-lj1-x22a.google.com with SMTP id v9-v6so4688880ljk.4 for ; Tue, 24 Jul 2018 13:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yN/yielz5Y2uhobb6IzBIIW7TcfUdoRMb8TfSuO9fxc=; b=W/u7KSCxAuVA1Hz8SiuWwyYwkG8AYts363hriVZYdlkMpCO9d1vJxgqCpL8TOMuVAB Zu5knH9rjOgDzDBlwaGr2BB4K/vgOUQBIqejmshJ6fe8Axi+0yAP27nLbxdh73OJtvpa aA2KT1KgIdD8npV+rEX5VGBfHrdJGBasdZ5sElAb5u60HS1iZte7j+w6FQO1xEFN5c4C 7v+hUKV2sw0VdRsuISQ3AwfZclw18pUR3D3EhpbDxfz66ETT0R8VuTx5bRZoVNZKsKf+ m6Uom0TvX7uRM4BoZEGuM1odPXjk12QGH2g5s1+dMEnUcNFOv/h5tLVtuGfkBYKN7bEv KjGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yN/yielz5Y2uhobb6IzBIIW7TcfUdoRMb8TfSuO9fxc=; b=VQuXblavCATlT9M6vAEsOlq6JNXGnQmurT+031w9pUufGET2cHeY54w1jwA3v6zZtU Nzin6egB2Y6M//Rhnq3KIL6T863Lp3su06xkwlL7u0of6f3Ich562MaeTTb+gDNZE9Qc kFuEJpOr5P4HaNp3M99ePyjD6y8XJ1DHDY6A/U/3dL0vhG7MN7LOsMI/MYhant23luZ2 /HqT9VMIe+bgGeAcrpLHuGjcTUcC5PdBcDL1Kv4pj2EnkKPGIC5IGj2AebULWIr4ecw1 cuGRn8lz+Sxd4mdJy9ovncRXUVSQbgtFx1Tws+eoKIrVwpbxsenyVo4IsdTmiS06YVL4 D1qQ== X-Gm-Message-State: AOUpUlHrAvnzWvR78x04p3QI7CT1GD6EpflIcf3qne7WZ3sPl9AqqEaD KaNibwMANkoXVk1UhMhl+R2zqJbjV5w3bGawS+vgcczw X-Google-Smtp-Source: AAOMgpfHUI27+vmWcojJGA/1EU+p+jWe2oOFGTWSUN/m2dmeAoEm5v0qLefgAbru7xrjQlkJ2CQFac+OVnca1rYqrN0= X-Received: by 2002:a2e:1517:: with SMTP id s23-v6mr13715435ljd.73.1532463072364; Tue, 24 Jul 2018 13:11:12 -0700 (PDT) MIME-Version: 1.0 From: Benjamin Cronce Date: Tue, 24 Jul 2018 15:11:00 -0500 Message-ID: To: bloat Content-Type: multipart/alternative; boundary="0000000000000f4dc70571c45d68" Subject: [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:11:14 -0000 --0000000000000f4dc70571c45d68 Content-Type: text/plain; charset="UTF-8" Maybe the Bobbie idea already would do this, but I did not see it explicitly mentioned on its wiki. The below is all about shaping ingress, not egress. My issue is that my ISP already does a good job with their AQM but nothing is perfect and their implementation of rate limiting has a kind of burst 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 perfect 250Mb/s steady state. 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 backdown by dropping. If I add my own traffic shaping and AQM, I can reduce the reported TCP retransmissions from ~3% to ~0.1%. The problem that I'm getting is by adding my own shaping, a measurable 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 anti-bufferbloat than my ISP is. Fewer latency spices according to DSLReports. 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 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 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. Instead of having backpressure and measuring sojourn time as a function of how long it takes packets to get scheduled, predict an estimated sojourn time based on the observed rate of flow, but allow packets to immediately vacate the queue. The AQM would either mark ECN or drop the packet, but never delay the packet. 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. --0000000000000f4dc70571c45d68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe the Bobbie idea already would do this, but I did not= see it explicitly mentioned on its wiki.

The below is a= ll about shaping ingress, not egress.

My issue is that my ISP alread= y does a good job with their AQM but nothing is perfect and their implement= ation of rate limiting has a kind of burst at the start. According to speed= tests, my 250Mb connection starts off around 500Mb/s and slowly drops over = the next few seconds until a near perfect 250Mb/s steady state.

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 backdown by d= ropping. If I add my own traffic shaping and AQM, I can reduce the reported= TCP retransmissions from ~3% to ~0.1%.

The problem that= I'm getting is by adding my own shaping, a measurable amount of the be= nefit of their AQM is lost. While I am limited to Codel, HFSC+Codel, or Fai= rQ+Codel for now, I am actually doing a worse job of anti-bufferbloat than = my ISP is. Fewer latency spices according to DSLReports.
This also does not touch on that the act of adding back-pressu= re in its nature increases latency. I cannot say if it's a fundamental = requirement in order to better my current situation, but I am curious if th= ere'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 w= ant to aggressively drop packets, but at the same time, I want the packets = that already made the journey to mostly unhindered enter my network.
<= div>
That's when I thought of a backpressure-less AQM. In= stead of having backpressure and measuring=C2=A0sojourn time as a function = of how long it takes packets to get scheduled, predict an estimated=C2=A0so= journ time based on the observed rate of flow, but allow packets to immedia= tely vacate the queue. The AQM would either mark ECN or drop the packet, bu= t never delay the packet.

In summary, my ISP seems= to have better latency with their AQM, but due to their shaper, loss durin= g the burst is much higher than desirable.

Maybe t= his will be mostly moot once I get fq_codel going on pfSense, but I do find= it an interesting issue.
--0000000000000f4dc70571c45d68--