Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: George Amanakis <gamanakis@gmail.com>,
	Cake List <cake@lists.bufferbloat.net>,
	cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno
Date: Sat, 21 Jul 2018 23:24:11 +0300	[thread overview]
Message-ID: <F0DAD487-29CC-4162-9592-207B4D4BA538@gmail.com> (raw)
In-Reply-To: <CAA93jw6HWDidWqfV-Ykx3jNfQeC-v7u9kgFmAcc4mYEVC0iuNA@mail.gmail.com>

> On 21 Jul, 2018, at 11:01 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> The cmts buffer fills more rapidly, particularly in slow start, while
> presenting packets to the inbound shaper at 100mbit. cake starts
> signalling, late, trying to achieve  but at that point the apparent
> RTTs are still growing rapidly (because of the buffer building up in
> the cmts inflicting that RTT), so as fast as we signal, we've got such
> a big buffer built up in the CMTS that tcp only sees one signal per
> RTT which is mismatched against what cake is trying to thwart. The
> pathology persists.
> 
> the idea for bobbie was that the goal for codel is wrong for inbound
> shaping, that instead of aiming for a rate, we needed to sum all the
> overage over our rate and reduce that until it all drains from cmts
> shaper.

Another possibility, which I've previously mentioned but haven't got around to implementing, is to give ECN more flexibility in signalling - so that it can indicate impending congestion as well as actual congestion.

That is, as well as the present CE mark meaning "back off now", there may be softer signals carried on the dual encodings of ECT, meaning "ramp down now", "don't ramp up", and "ramp up only with caution".  These signals can be given without delay, according to instantaneous conditions at the bottleneck, without needing to estimate path RTT.  You could think of it as a version of DCTCP that can actually be deployed in the internet, because it doesn't destroy the existing meaning of CE.

The main problem is with getting the endpoints (both receiver and sender) to recognise these new signals and react appropriately to them.  Producing these signals at the AQM is relatively easy.  I think I worked out a way to do it with the two padding bytes that normally accompany the Timestamp option in TCP - this requires replacing the Timestamp option with one that has the same semantics, but also carries the extra data about recent ECT marks, and doesn't require padding to be naturally aligned in the packet.

This would give a way to halt slow-start when it reaches roughly the correct window size, instead of having it overshoot first.  It would also give a way to gently control the cwnd to the ideal value while in steady-state, instead of oscillating around it.

 - Jonathan Morton


  reply	other threads:[~2018-07-21 20:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-21 16:09 [Cerowrt-devel] " Dave Taht
2018-07-21 17:20 ` [Cerowrt-devel] [Cake] " Georgios Amanakis
2018-07-21 17:23   ` Jonathan Morton
2018-07-21 17:44     ` Georgios Amanakis
2018-07-21 17:47       ` Dave Taht
2018-07-21 18:18         ` Georgios Amanakis
2018-07-21 18:20           ` Dave Taht
2018-07-21 18:23             ` Georgios Amanakis
2018-07-21 20:01           ` Dave Taht
2018-07-21 20:24             ` Jonathan Morton [this message]
2018-07-21 20:36               ` Dave Taht
2018-07-21 17:24   ` Arie
2018-07-21 17:27     ` Dave Taht
2018-07-21 17:28   ` Georgios Amanakis
2018-07-21 17:42     ` Dave Taht
2018-07-21 19:57       ` Toke Høiland-Jørgensen
2018-07-24  2:36   ` Dave Taht
2018-07-24  4:17     ` Georgios Amanakis
2018-07-22  9:57 ` Pete Heist
2018-07-22 10:29   ` Sebastian Moeller

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/cerowrt-devel.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=F0DAD487-29CC-4162-9592-207B4D4BA538@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=gamanakis@gmail.com \
    /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