Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: "Dave Täht" <dave.taht@gmail.com>
Cc: Pete Heist <pete@heistp.net>, Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] lanman2018 cake talk ideas
Date: Thu, 21 Jun 2018 11:42:24 +0200	[thread overview]
Message-ID: <8A0DE58C-5DE6-4490-A90D-CB09761A6833@gmx.de> (raw)
In-Reply-To: <CAA93jw6-RCy8QbFaWiPiP8KiCHxwo8di1X4y=8fJUv1BAXMMpQ@mail.gmail.com>

Hi Dave,



> On Jun 21, 2018, at 05:43, Dave Taht <dave.taht@gmail.com> wrote:
> 
> 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.

	So I like the idea of using traditional transport methods like semitrailers and containerships to illustrate bandwidth versus latency.
I once guesstimated that a semi trailer full of 2TB hardisks across the USA will have around 1Tbps Bandwidth but a one-way delay larger than 43 hours
That IMHO shows the weak linkage between bandwidth and latency and why focussing on bandwidth alone will not work well with interactive use cases.
But this might both be too obvious and too cynic...

Best Regards
	Sebastian




> 
> 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
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


  parent reply	other threads:[~2018-06-21  9:42 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
2018-06-21  7:04     ` Pete Heist
2018-06-21  7:55       ` Jonas Mårtensson
2018-06-21  9:42     ` Sebastian Moeller [this message]
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=8A0DE58C-5DE6-4490-A90D-CB09761A6833@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --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