From: Dave Taht <dave.taht@gmail.com>
To: Pete Heist <pete@heistp.net>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] lanman2018 cake talk ideas
Date: Wed, 20 Jun 2018 20:43:35 -0700 [thread overview]
Message-ID: <CAA93jw6-RCy8QbFaWiPiP8KiCHxwo8di1X4y=8fJUv1BAXMMpQ@mail.gmail.com> (raw)
In-Reply-To: <FADDB336-9AB5-485A-A15F-9FDCF3F5F6B2@heistp.net>
I think your "megabit myth" idea (and language) would be a very
powerful paper and/or talk to try and hammer home in multiple venues.
I might spend a slide on it at this conference, but it deserves more
focus than that.
On Wed, Jun 20, 2018 at 8:45 AM, Pete Heist <pete@heistp.net> wrote:
>
> 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”? 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…
>
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
next prev parent reply other threads:[~2018-06-21 3:43 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
2018-06-21 3:43 ` Dave Taht [this message]
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='CAA93jw6-RCy8QbFaWiPiP8KiCHxwo8di1X4y=8fJUv1BAXMMpQ@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=pete@heistp.net \
/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