From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 CFB2C3B29E for ; Tue, 24 Jul 2018 16:48:47 -0400 (EDT) Received: by mail-lf1-x12e.google.com with SMTP id u202-v6so3907837lff.9 for ; Tue, 24 Jul 2018 13:48:47 -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; bh=+mzQQG7eq7vCXbaj2n0qkQ2hxZ2jxUM8/8bC9ukTJEI=; b=IRC+cbUBKTfNSVoFZIPU0GTy7jQd/QkXHf6lNNRlryb8cWthI2qyrhbT79QCUtGsxJ RL3tCoNXZbH4y8CEK0+79xsHRw0FN+ZO75O88m1a+MDIZbvwLDhCCF+XUnewgWEJ/JdL Gmtt1I7QCi+GBijah4lXxP9/xA1lD0gO6hbGexa3WcJt9ppXuofsG2oKQ6NRzv0sP2hk JAJCM/Z2v/jbtcbVLERPC19oaKqBntcv1ECC6zNAJElb2Plz4wKQoOjvyW+ASRFUqcw6 PF2BaZVsrwK/yyq3hDky5gcYNGI3VcA5iO7/QMyJawDdT0Rm/fW0HfAy6ixPV+xBTe2t VN2g== 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; bh=+mzQQG7eq7vCXbaj2n0qkQ2hxZ2jxUM8/8bC9ukTJEI=; b=B1DSgzFzqQ5alKVy8y0tkSBzohQ2a7Te4xwcuJQbNFdBpfdGu2hi1dGabnj2W0A5rB Wun9Xd4jHAj+tSDbGxJd9KYbzBCmYoRUlvllbAmO1OFQKuPJjn4/hz17c0QvsGY0knF1 FuKL2UD0qfmfaWCztHRNkICGBXWg5ckXH/GixwPBi877Y93OhPDHAsa57ww7uQ+DFv0O KC4AdnPrZs9NW3+NTzYVv3a5kY52jW7A6BfWRq6N0CbFmH1znr1WtwnMK8Nb5S5lCgYl Po/p1GzE1uhjmHpcy3CNwb7U0FlA2mlcGb5Ihx/DUfzN60ziHhZJNCW/9Wl3SVbcV9lU iJOw== X-Gm-Message-State: AOUpUlGta3NV1McRsdpTmph/GG0UyTl/Imb3WOeUaIG6mnjXRLwSDPUO LfURZAmROHnvepHYerIfJkKezMJBNLpWPX71U48= X-Google-Smtp-Source: AAOMgpemz/B80LzwOBGUB+m8nj1jOBDesXduL0CXQJI38hIvZ2NI0QAfC83VDzpyVx+n0ZAet+N61k3SPytgeyOUNss= X-Received: by 2002:a19:c403:: with SMTP id u3-v6mr10684443lff.87.1532465326723; Tue, 24 Jul 2018 13:48:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Benjamin Cronce Date: Tue, 24 Jul 2018 15:48:35 -0500 Message-ID: To: Jonathan Morton Cc: bloat Content-Type: multipart/alternative; boundary="0000000000006e19c00571c4e38d" 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:48:48 -0000 --0000000000006e19c00571c4e38d Content-Type: text/plain; charset="UTF-8" On Tue, Jul 24, 2018 at 3:33 PM Jonathan Morton wrote: > > On 24 Jul, 2018, at 11:11 pm, Benjamin Cronce wrote: > > > > 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. > > We do know that applying SQM at the entry to the bottleneck link works > much better than at the exit. It's a fundamental principle. > > > 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. > > It's a reasonable idea. The key point is to use a deficit-mode > scheduler/shaper, rather than the credit-mode ones that are common (mainly > TBF/HTB). The latter are why you have such a big, uncontrolled burst from > the ISP in the first place. > > - Jonathan Morton > >From what I understand, the ISP is shaping on the core router and they're using whatever algorithm so happens to be implemented. It has been a few years since I last talked to anyone from there and it does seem to be acting differently, so I am not sure if they purposefully made any changes, but when I did talk to them last time, they said they did not do any purposeful configurations to combat bufferbloat and whatever I was seeing was entirely arbitrary. When their shaping was worse, it very much acted like a sliding window in that it pretty much like line rate 1Gb/s through until ~200ms, at which point it started to clamp down very quickly and reach a healthy steady state in ~2 seconds. But during that transition, loss spikes were pretty bad. Now it feels like the window is just much larger. I no longer see it hitting line rate anymore, but it does seems to be capped around 2x provisioned. When I was at 150Mb, It maxed out around 300Mb/s and slowly dropped to 150Mb. Now it maxed out about 500Mb and roughly the same slope down to 250Mb. Here is an example of what I'm seeing https://www.dslreports.com/speedtest/36310277 While there are a few spikes on the download, when running many tests in a row, I see fewer and smaller spikes than if I do my own shaping. --0000000000006e19c00571c4e38d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Jul 24, 2018 at 3:33 PM Jonathan Morton <chromatix99@gmail.com> wrote:
> On 24 Jul, 2018, at 11:11 pm, Benjami= n Cronce <bcronce= @gmail.com> wrote:
>
> The problem that I'm getting is by adding my own shaping, a measur= able amount of the benefit of their AQM is lost. While I am limited to Code= l, HFSC+Codel, or FairQ+Codel for now, I am actually doing a worse job of a= nti-bufferbloat than my ISP is. Fewer latency spices according to DSLReport= s.

We do know that applying SQM at the entry to the bottleneck link works much= better than at the exit.=C2=A0 It's a fundamental principle.

> That's when I thought of a backpressure-less AQM. Instead of havin= g backpressure and measuring sojourn time as a function of how long it take= s packets to get scheduled, predict an estimated sojourn time based on the = observed rate of flow, but allow packets to immediately vacate the queue. T= he AQM would either mark ECN or drop the packet, but never delay the packet= .

It's a reasonable idea.=C2=A0 The key point is to use a deficit-mode sc= heduler/shaper, rather than the credit-mode ones that are common (mainly TB= F/HTB).=C2=A0 The latter are why you have such a big, uncontrolled burst fr= om the ISP in the first place.

=C2=A0- Jonathan Morton

From what I und= erstand, the ISP is shaping on the core router and they're using whatev= er algorithm so happens to be implemented. It has been a few years since I = last talked to anyone from there and it does seem to be acting differently,= so I am not sure if they purposefully made any changes, but when I did tal= k to them last time, they said they did not do any purposeful configuration= s to combat bufferbloat and whatever I was seeing was entirely arbitrary. W= hen their shaping was worse, it very much acted like a sliding window in th= at it pretty much like line rate 1Gb/s through until ~200ms, at which point= it started to clamp down very quickly and reach a healthy steady state in = ~2 seconds. But during that transition, loss spikes were pretty bad. Now it= feels like the window is just much larger. I no longer see it hitting line= rate anymore, but it does seems to be capped around 2x provisioned. When I= was at 150Mb, It maxed out around 300Mb/s and slowly dropped to 150Mb. Now= it maxed out about 500Mb and roughly the same slope down to 250Mb.

Here is an example of what I'm seeing=C2=A0https://www.dslreports.com/= speedtest/36310277
While there are a few spikes on the downlo= ad, when running many tests in a row, I see fewer and smaller spikes than i= f I do my own shaping.=C2=A0
--0000000000006e19c00571c4e38d--