Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Pete Heist <pete@heistp.net>
To: Dave Taht <dave.taht@gmail.com>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] lanman2018 cake talk ideas
Date: Wed, 20 Jun 2018 17:45:31 +0200	[thread overview]
Message-ID: <FADDB336-9AB5-485A-A15F-9FDCF3F5F6B2@heistp.net> (raw)
In-Reply-To: <CAA93jw7B5DJ-jaRF18z6sCLrB9ubCrb2bdnewTBG=ZHVp8FENA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3670 bytes --]


> On Jun 18, 2018, at 7:44 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Try as I might, finding a memorable narrative hook to fit into 20
> minutes eludes me. There's so much to cake! There's no room for me to
> break out a guitar or carry a case of water bottles into this press.

To me, explaining this stuff is about trying to connect the technology with relatable human experience, and asserting/showing that the continued focus on throughput is misplaced. Is this audience already aware of that, or not? Maybe test them up front to see how much you need to talk about it. If you assume they know this and they don’t, the blank stares will start a minute or two into the talk...

If at least some people in the audience need an explanation, or even if you just want to hammer it home, for this type of crowd (should at least be somewhat technical), why not make an analogy with the “Megahertz myth <https://en.wikipedia.org/wiki/Megahertz_myth>”? That finally died in 2005 with the Pentium Extreme Edition (with the “Extreme” part not describing its speed, but rather its flirtation with thermal limits), when AMD came out with a “slower” CPU that was actually faster. Finally there was an awareness that ah, it’s not just clock speed, it’s pipelines, it’s caching, it’s branch prediction, it’s the instruction set, it’s…complicated, and there’s no getting around it.

Let’s start arguing that there’s an analogous “Megabit myth” that has no Wikipedia page yet because it persists to this day. Analogous to the megahertz myth, it’s not just “megabits per second”, but it’s inter-flow latency, it’s intra-flow latency, it’s fairness, it’s IPDV, it’s all of this under dynamic loads, it’s…complicated. And because it’s a complicated problem, Cake has a number of solutions built into it, which you’ll talk about... Perhaps Cake’s mascot should be a multi-headed creature of some kind (the monster that Eric referred to), maybe a hydra. Cake is definitely multi-headed. :)

If this audience is aware of this already, just move beyond it more quickly, but it’s worth hammering it home at least a bit, because again, where’s that "Megabit myth" Wikipedia page? It doesnt exist, because it hasn’t yet sunk in to the general consciousness that hey, why are we paying for 50Mbit symmetric fiber connections that can feel like 5Mbit ADSL?

Will the abandonment of network neutrality finally be the “Pentium Extreme Edition” that brings the megabit myth to a head?

> A principal complaint of the reviewers of the paper  was the lack of
> real world tests, so I snuck in a couple sides for that and am working
> on incorporating the graphs and other text from the paper.

I hadn’t noticed that complaint, but it’s legit. RRUL tests are interesting and point out what “should” happen, but long-term “before and after” tests on real networks and backhauls would be real proof. This doesn’t help you at this late stage in the game, but let’s take that comment to heart in the future. Meanwhile, do we have any quotes from users on how it improved their experience, or is that too anecdotal? or quotes from people in the field?

> What does a ieee lanman2018 audience already grok, what needs to be explained?

That’s a key question, you’ll probably have to feel the audience out unless someone knows the conference already?

> I will be periodically updating the currently very raw
> 
> http://www.taht.net/~d/cake/ieee.odp
> 
> as we go along. Please share your thoughts....

Will do, or also write if you’re in need of something specific…


[-- Attachment #2: Type: text/html, Size: 4847 bytes --]

  parent reply	other threads:[~2018-06-20 15:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 17:44 Dave Taht
2018-06-18 17:50 ` Loganaden Velvindron
2018-06-18 17:52 ` Loganaden Velvindron
2018-06-20  8:25 ` Luca Muscariello
2018-06-20 15:45 ` Pete Heist [this message]
2018-06-21  3:43   ` Dave Taht
2018-06-21  7:04     ` Pete Heist
2018-06-21  7:55       ` Jonas Mårtensson
2018-06-21  9:42     ` Sebastian Moeller
2018-06-22  7:45 Felix Resch
2018-06-22  8:05 ` Pete Heist
2018-06-23  5:14   ` Dave Taht
2018-06-23  5:35     ` Dave Taht
2018-06-23  7:12       ` Jonathan Morton
2018-06-26  6:58     ` Dave Taht
2018-06-26  8:33       ` Pete Heist
2018-06-26 10:52         ` Toke Høiland-Jørgensen
2018-06-26 13:13           ` Dave Taht
2018-06-26  8:34       ` 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/cake.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=FADDB336-9AB5-485A-A15F-9FDCF3F5F6B2@heistp.net \
    --to=pete@heistp.net \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave.taht@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