From: Dave Taht <dave.taht@gmail.com>
To: ECN-Sane <ecn-sane@lists.bufferbloat.net>
Cc: kaichen@cse.ust.hk, webai@microsoft.com
Subject: Re: [Ecn-sane] comments: "Enabling ECN for Datacenter Networks with RTT Variations"
Date: Sat, 4 Jan 2020 14:01:42 -0800 [thread overview]
Message-ID: <CAA93jw7W5mGro4f5Dk0aCfTTjV+qLdR-69tztrvui52xqGLdZg@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw6cu_9cDrSfr=bvCvwqinUk_n9DVs=n9gUkERaHOA=grg@mail.gmail.com>
On Sun, Dec 29, 2019 at 8:02 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> this ecn# & codel in p4 paper had probably of most interest to me four points:
>
> 1) Codel like algorithm on a tofino switch, implemented in p4
> 2) with some source code published... Not the p4 code, darn it...
> unless I missed it?
> but a detailed description of how they used the timestamp field was neat
> 3 Honestly I'd never thought about how much rtt variation a dc had,
> nor do I know if this model is correct
> 3) Not really clear what parameters the used for codel
For CoDel, the interval is set to 240µs while target is set to 10µs.
> https://resource.hpisys.com/seminar-papers/2019/paper/20191108_CoNEXT2019_Enabling%20ECN%20for%20Datacenter%20Networks%20with%20RTT%20Variations.pdf
>
> "Despite being successful, prior ECN-based transports have an
> important drawback: they adopt a fxed RTT value in calculating
> instantaneous ECN marking threshold while overlooking the RTT
> variations in practice. In this paper, we reveal that the current
> practice of using a fxed high-percentile RTT for ECN threshold
> calculation can lead to persistent queue buildups, signifcantly
> increasing packet latency. On the other hand, directly adopting lower
> percentile RTTs results in throughput degradation. To handle the
> problem, we introduce ECN!, a simple yet efective solution to enable
> ECN for RTT variations. At its heart, ECN! inherits the current
> instantaneous ECN marking (based on a high-percentile RTT) to achieve
> high throughput and burst tolerance, while further marking packets
> (conservatively) upon detecting long-term queue buildups to eliminate
> unnecessary queueing delay without degrading throughput. We implement
> ECN! on a Barefoot Tofno switch"
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
--
Make Music, Not War
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
prev parent reply other threads:[~2020-01-04 22:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-30 4:02 Dave Taht
2019-12-31 1:56 ` [Ecn-sane] [EXTERNAL] " Wei Bai
2020-01-04 22:01 ` Dave Taht [this message]
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=CAA93jw7W5mGro4f5Dk0aCfTTjV+qLdR-69tztrvui52xqGLdZg@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=kaichen@cse.ust.hk \
--cc=webai@microsoft.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