Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
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

  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