From: "Holland, Jake" <jholland@akamai.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>,
Jonathan Morton <chromatix99@gmail.com>
Cc: "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Ecn-sane] can we setup a "how to get this into existing networks" get-together in Prague coming week?
Date: Tue, 26 Mar 2019 11:06:38 +0000 [thread overview]
Message-ID: <4E263690-FF7C-41C4-BCB6-464763000351@akamai.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1903232009260.3161@uplift.swm.pp.se>
Hi Mikael,
Any operator nibbles on making this meeting happen?
I'm not sure how useful I can be, but if there's any network
operators reading, I would love to hear the questions and
concerns from your side, and I'm happy to explain anything
I can help explain.
(Of course if it's just going to be vendors and/or implementors
getting together to agree ECN is a good idea, we might as well
bring plenty of beer...)
-Jake
On 2019-03-23, 20:12, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
On Sat, 23 Mar 2019, Jonathan Morton wrote:
> Heated agreement from over here, despite my preference for flow
> isolation. Plain old AQM can be orders of magnitude better than a dumb
> FIFO.
In my testing, FIFO with RED was already huge improvement over just plain
FIFO.
Configuring 1GE shaping with FIFO yielded 100ms buffering just by naive
configuration, adding one line of random-detect config brought this down
to 10-15ms without any loss of actual throughput.
On Thu, 21 Mar 2019, Mikael Abrahamsson wrote:
Btw, I reached out to some people here at the BBF about doing
anti-bufferbloat in this context and getting this into the documents, and
there is no reason why this can't be introduced.
Now, the proposal needs to be "reasonable" and implementable, so if
someone would be interested in work like that I'd like to hear from you. I
have taken initiative in trying to come up with configuration guidance for
operators for their existing equipment, and that could be a way forward.
...
I'll be at the IETF meeting monday-friday coming week, can we set up a
meeting with some interested parties and actually have a "how do we get
this into networks" kind of meeting. It would not be "my mechanism is
better than yours" meeting, I'm not interested in that in this context.
next prev parent reply other threads:[~2019-03-26 11:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 10:31 [Bloat] " Mikael Abrahamsson
2019-03-23 6:00 ` [Bloat] [Ecn-sane] " Holland, Jake
2019-03-23 19:01 ` Jonathan Morton
2019-03-23 19:12 ` Mikael Abrahamsson
2019-03-26 11:06 ` Holland, Jake [this message]
2019-03-26 13:20 ` Mikael Abrahamsson
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E263690-FF7C-41C4-BCB6-464763000351@akamai.com \
--to=jholland@akamai.com \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=swmike@swm.pp.se \
/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