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 <p...@heistp.net> wrote:
>
> On Jun 18, 2018, at 7:44 PM, Dave Taht <dave.t...@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
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Reply via email to