Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	ECN-Sane <ecn-sane@lists.bufferbloat.net>,
	tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [Ecn-sane] [tsvwg] Fwd: my backlogged comments on the ECT(1) interim call
Date: Wed, 29 Apr 2020 17:07:18 +0200	[thread overview]
Message-ID: <E8582010-FD1A-430D-A2DA-1C55E90D6671@gmx.de> (raw)
In-Reply-To: <537a840b-4c71-4ad2-8421-32c248eb69fa@bobbriscoe.net>

Hi Bob,

> On Apr 29, 2020, at 15:37, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> [...]
> 3. I should add that I know you personally have tried to address the asymmetric capacity problem with the ACK thinning in CAKE.

ACK thinning in cake happened because Ryan Mounce on a rather unsavory asymmetric DOCSIS link (120/2.5 or 48:1) wanted to free some upstream capacity for data (with cake in the path his DOCSIS-Modem stopped ACK filtering, since it never saw the queue necessary to collect the ACKs to "merge"). Also ACK compression was eating into the downstream rates as well (turns out ACK "clocking" is a rather optimistic concept to rely on once bandwidth get tight and jitter gets high). 
The root cause here was the arguably misconfigured asymmetry of his link by his ISP, and that can unfortunately not be addressed by cake's ACK-filter, just worked-around. 

That said, in your case with the first mover being CableLabs/DOCSIS, I would have assumed that you (or cablelabs) would simply have grandfathered in the ACK filter into the design of the upstream shaper instance. Did you not?

Best Regards
	Sebastian

  reply	other threads:[~2020-04-29 15:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAA93jw5g8vMNEoV899tX=89HzHSG5s2E3sGU1EFVdqRkWryCqw@mail.gmail.com>
2020-04-27 19:26 ` [Ecn-sane] " Dave Taht
2020-04-29  9:31   ` Bob Briscoe
2020-04-29  9:46     ` [Ecn-sane] [tsvwg] " Sebastian Moeller
2020-04-29 10:32       ` Bob Briscoe
2020-04-29 11:21         ` Sebastian Moeller
2020-04-29  9:49     ` [Ecn-sane] " Jonathan Morton
2020-04-29 13:37       ` Bob Briscoe
2020-04-29 15:07         ` Sebastian Moeller [this message]
2020-04-29 16:03         ` Jonathan Morton
2020-05-16 16:32     ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E8582010-FD1A-430D-A2DA-1C55E90D6671@gmx.de \
    --to=moeller0@gmx.de \
    --cc=chromatix99@gmail.com \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=ietf@bobbriscoe.net \
    --cc=tsvwg@ietf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox