[Cake] lanman2018 cake talk ideas

[Cake] lanman2018 cake talk ideas

[Dave Taht]

I started at the lanman2018 talk (to be given next tuesday), this past
weekend, for "piece of cake" ( https://arxiv.org/abs/1804.07617 )

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 preso.

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.

But ya know, it's always been a group effort and if anyone(s) here
would like to contribute better slides, jokes, text, ideas, graphs,
charts, or whatever, it would be helpful, because I can no longer see
the forest after passing through it. I've oft wished we had the
equivalent of a corp communications department 'cause my attempts at
graphics generally suck.

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

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....




-- 

Dave Täht
CEO, TekLibre, LLC

Re: [Cake] lanman2018 cake talk ideas

[Loganaden Velvindron]

On Mon, Jun 18, 2018 at 9:44 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I started at the lanman2018 talk (to be given next tuesday), this past
> weekend, for "piece of cake" ( https://arxiv.org/abs/1804.07617 )
>
> 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 preso.
>
> 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.
>
> But ya know, it's always been a group effort and if anyone(s) here
> would like to contribute better slides, jokes, text, ideas, graphs,
> charts, or whatever, it would be helpful, because I can no longer see
> the forest after passing through it. I've oft wished we had the
> equivalent of a corp communications department 'cause my attempts at
> graphics generally suck.
>
> What does a ieee lanman2018 audience already grok, what needs to be explained?
>
> 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....
>
>

I thought that BBR solved a number of bufferbloat issues ? Maybe
elaborate on the shortcomings of BBR. Particularly this comment:
"But best case only work within an RTT"

>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] lanman2018 cake talk ideas

[Loganaden Velvindron]

I use cake 24 hours/7 days. From Mauritius to Europe, it's around
250-300ms at worse. To use, it's up to 500ms.

qdisc cake 8035: dev pppoe-wan root refcnt 2 bandwidth 4Mbit diffserv3
triple-isolate rtt 300.0ms raw
 Sent 170109544 bytes 1647933 pkt (dropped 186, overlimits 248108 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 357280b of 4Mb
 capacity estimate: 4Mbit
                 Bulk   Best Effort      Voice
  thresh       250Kbit       4Mbit       1Mbit
  target        72.7ms      15.0ms      18.2ms
  interval     357.7ms     300.0ms      36.3ms
  pk_delay         0us       1.4ms       915us
  av_delay         0us        76us       251us
  sp_delay         0us         6us         9us
  pkts               0     1645098        3021
  bytes              0   169843927      528062
  way_inds           0       82831           0
  way_miss           0       27629         102
  way_cols           0           0           0
  drops              0         186           0
  marks              0           0           0
  sp_flows           0           0           0
  bk_flows           0           1           0
  un_flows           0           0           0
  max_len            0        2900         576

qdisc ingress ffff: dev pppoe-wan parent ffff:fff1 ----------------
 Sent 3237380050 bytes 2510970 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8036: dev ifb4pppoe-wan root refcnt 2 bandwidth 24Mbit
besteffort triple-isolate rtt 300.0ms raw
 Sent 3236131275 bytes 2510117 pkt (dropped 854, overlimits 3210384 requeues 0)
 backlog 1492b 1p requeues 0
 memory used: 2033600b of 4Mb
 capacity estimate: 24Mbit
                 Tin 0
  thresh        24Mbit
  target        15.0ms
  interval     300.0ms
  pk_delay       471us
  av_delay       228us
  sp_delay        12us
  pkts         2510972
  bytes     3237383034
  way_inds       58277
  way_miss       27873
  way_cols           0
  drops            854
  marks              0
  sp_flows           0
  bk_flows           1
  un_flows           0
  max_len         1492

On Mon, Jun 18, 2018 at 9:44 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I started at the lanman2018 talk (to be given next tuesday), this past
> weekend, for "piece of cake" ( https://arxiv.org/abs/1804.07617 )
>
> 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 preso.
>
> 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.
>
> But ya know, it's always been a group effort and if anyone(s) here
> would like to contribute better slides, jokes, text, ideas, graphs,
> charts, or whatever, it would be helpful, because I can no longer see
> the forest after passing through it. I've oft wished we had the
> equivalent of a corp communications department 'cause my attempts at
> graphics generally suck.
>
> What does a ieee lanman2018 audience already grok, what needs to be explained?
>
> 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....
>
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] lanman2018 cake talk ideas

[Luca Muscariello]

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

In my opinion, you should introduce the challenges faced to get to this
point a little bit more.
There has been an historically difficult insertion of packet scheduling in
the Internet.

FQ in the first place has suffered ostracism for a number of reasons, some
acceptable criticism,
some others just driven by ignorance.
You don't make that point at the beginning of the presentation and you
should, IMO.

Let me be a little dramatic for a second.
It's been an odyssey. Really, if we start counting from John Nagle (1985)
and
Ellen Hahne's Ph.D thesis at MIT supervised by Robert Gallager.
And take FQ_codel RFC as another milestone in 2018.

More than 30 years. That's an odyssey. Longer actually as Ulysses stayed
away from home only 20 years!
So cake is really sitting on giant's shoulders.
But the list is long, Jim Roberts, Scott Shenker, Luigi Rizzo and many many
others, sorry the list is too long.

Why so difficult? Was it worthy?
I think you should say that at the conference.
Gook luck!

Ellen L. Hahne:
Round robin scheduling for fair flow control in data communication networks.

Massachusetts Institute of Technology, Cambridge, MA, USA 1986



On Mon, Jun 18, 2018 at 7:44 PM Dave Taht <dave.taht@gmail.com> wrote:

> I started at the lanman2018 talk (to be given next tuesday), this past
> weekend, for "piece of cake" ( https://arxiv.org/abs/1804.07617 )
>
> 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 preso.
>
> 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.
>
> But ya know, it's always been a group effort and if anyone(s) here
> would like to contribute better slides, jokes, text, ideas, graphs,
> charts, or whatever, it would be helpful, because I can no longer see
> the forest after passing through it. I've oft wished we had the
> equivalent of a corp communications department 'cause my attempts at
> graphics generally suck.
>
> What does a ieee lanman2018 audience already grok, what needs to be
> explained?
>
> 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....
>
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

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

Re: [Cake] lanman2018 cake talk ideas

[Pete Heist]

[-- 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 --]

Re: [Cake] lanman2018 cake talk ideas

[Dave Taht]

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

Re: [Cake] lanman2018 cake talk ideas

[Pete Heist]

> On Jun 21, 2018, at 5:43 AM, 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.

Ok, I’ve finally got a few freer days coming up, so I’ll see if I can’t make progress on backed up tasks, then maybe write something up on this. Might retreat from the lists meanwhile.

On slide #4: Ubiquity -> Ubiquiti. And consider adding Verizon. My mother has Verizon Fios (50Mbit symmetric fiber) near Philly and that was the connection I referred to earlier- it just doesn’t feel like 50Mbit symmetric fiber should.

As a side note, Google as a whole seems responsible as far as the big four go when it comes to bloat (and other things). BBR advanced the state of things, and they financed it after all, so it deserves some appreciation, to the devs as well. Worth mentioning in this preso? :)

I like the Cake vs Sonic Fiber slide, and would like to hear the commentary. In case they video the presentation, do post a link. Best of luck!

Re: [Cake] lanman2018 cake talk ideas

[Jonas Mårtensson]

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

On Thu, Jun 21, 2018 at 9:04 AM Pete Heist <pete@heistp.net> wrote:

>
> > On Jun 21, 2018, at 5:43 AM, 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.
>
> Ok, I’ve finally got a few freer days coming up, so I’ll see if I can’t
> make progress on backed up tasks, then maybe write something up on this.
> Might retreat from the lists meanwhile.
>
> On slide #4: Ubiquity -> Ubiquiti. And consider adding Verizon. My mother
> has Verizon Fios (50Mbit symmetric fiber) near Philly and that was the
> connection I referred to earlier- it just doesn’t feel like 50Mbit
> symmetric fiber should.
>
> As a side note, Google as a whole seems responsible as far as the big four
> go when it comes to bloat (and other things). BBR advanced the state of
> things, and they financed it after all, so it deserves some appreciation,
> to the devs as well. Worth mentioning in this preso? :)
>
> I like the Cake vs Sonic Fiber slide, and would like to hear the
> commentary. In case they video the presentation, do post a link. Best of
> luck!
>

I like the slide too but what exactly do you mean by "Cake gets inside the
GPON request/grant loop"?

Now, even more impressive would be a Cake vs Google Fiber plot, showing a
reduction of latency under load from ~2000ms to a few ms.

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

Re: [Cake] lanman2018 cake talk ideas

[Sebastian Moeller]

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

Re: [Cake] lanman2018 cake talk ideas

[Felix Resch]

> ... has no Wikipedia page yet ...

here you go https://en.wikipedia.org/wiki/Draft:Megabit_myth

Re: [Cake] lanman2018 cake talk ideas

[Pete Heist]

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


> On Jun 22, 2018, at 9:45 AM, Felix Resch <fuller@beif.de> wrote:
> 
>> ... has no Wikipedia page yet ...
> 
> here you go https://en.wikipedia.org/wiki/Draft:Megabit_myth <https://en.wikipedia.org/wiki/Draft:Megabit_myth>

Thanks! Now the problem is solved. :)

I only had some second thoughts, and let’s get this right and be consistent, is it:

1) Megabit myth
2) Megabits myth
3) Megabits per second myth

#3 is the accurate one, but in this day and age every syllable can somehow slow an idea down. I’m leaning towards #2. I’ve also heard non-technical people say “how many Megabits is it?” when referring to an Internet connection, as if the “per second” part is already too much to handle. :)


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

Re: [Cake] lanman2018 cake talk ideas

[Dave Taht]

I have to get on the plane tomorrow night at midnight and I've tried
to capture some of your comments and ideas in:

http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp

It's in its usual mess at this point - usually I don't share stuff
this raw! but I'm totally open to text suggestions, graphics, etc,
etc, etc - there's the plane flight and more than a few days left to
pound it into shape and after I get a feel for the conference monday
will end up doing another pass before the talk tuesday. What to say on
each slide is helpful (jokes appreciated, a lot of what I've had to
say so far is dripping with sarcasm which I know doesn't translate
well).

I think focusing on per host fq is probably the strongest point to
develop and I kind of wanted a diagram of a whole bunch
of different host types and graphically illustrating what happens vs
fifo, fq_codel, and cake.

off to pack
On Fri, Jun 22, 2018 at 1:05 AM Pete Heist <pete@heistp.net> wrote:
>
>
> On Jun 22, 2018, at 9:45 AM, Felix Resch <fuller@beif.de> wrote:
>
> ... has no Wikipedia page yet ...
>
>
> here you go https://en.wikipedia.org/wiki/Draft:Megabit_myth
>
>
> Thanks! Now the problem is solved. :)
>
> I only had some second thoughts, and let’s get this right and be consistent, is it:
>
> 1) Megabit myth
> 2) Megabits myth
> 3) Megabits per second myth
>
> #3 is the accurate one, but in this day and age every syllable can somehow slow an idea down. I’m leaning towards #2. I’ve also heard non-technical people say “how many Megabits is it?” when referring to an Internet connection, as if the “per second” part is already too much to handle. :)
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cake] lanman2018 cake talk ideas

[Dave Taht]

doing a self review of what I got before I crash

yes, yes, all the slides are out of order. Yes, I should write down
what I intend to say and not have it on the slide

* cake stores one less packet than htb+fq_codel. Anybody got a 2mbit
result for sqm that shows the resulting induced latency?
(2mbit because I'm irked about that 2mbit broadband study in the uk)
* I'll probably substitute my 50x1 ack-filtering result for the 30x1
in the paper (http://blog.cerowrt.org/post/ack_filtering/ ) and burn
no more than a minute on it because I still hate the idea of ack
filtering
* sch_cake (shaped 1gbit ethernet) v sch_fq bql'd at 1Gbit - for A
week NOW! I thought the bandwidth hit from shaping was 1.7 percent.
And I should know better! I realized about an hour ago that it was
(mostly) because we were getting 20% more measurement flows. I pulled
that data out of flent, but perhaps an irtt result shaped to a gbit
would be better (I didn't have irtt on that test). Also that test was
host to host, not through - which I kind of liked. It would probably
irk eric dumazet somewhat to see that result vs sch_fq :)
* I liked mentioning our most remote test site (mauritius), and wanted
to have something that talked about our development process near the
close
* need a final summary slide
* really hate the cake_dst/src/triple isolate graph and wish we had a
better way to express it. pie chart?
* think zooming into 300 flows with a probability of 0 collisions on
the 8 way set associative slide (and yes, the title needs to be
better)
* not sponsored by still motivates me every time it passes by
* liked explaining diffserv's implementation (bandwidth reservation
rather than drop probability)

I figure we have 25 slides tops

Re: [Cake] lanman2018 cake talk ideas

[Jonathan Morton]

> On 23 Jun, 2018, at 8:35 am, Dave Taht <dave.taht@gmail.com> wrote:
> 
> * really hate the cake_dst/src/triple isolate graph and wish we had a
> better way to express it. pie chart?

Pie chart is a good idea for that one.  Even better if it was a cake chart.

For the "evil" host, I recommend a gaming PC downloading an update through Wargaming's launchers (World of Tanks/Warships/Warplanes).  I believe they use libtorrent, but practically all of the bandwidth is supplied in practice by "web seeds", and the active flow count per downloading host is typically in the hundreds, each to a different IP address in WG's CDN.  At that level, end-to-end congestion control simply does not work without network assistance, which Cake happily provides.

Another local host could be running a videoconference session to two or three remote callers simultaneously, while a third simply downloads something with a single stream.

 - Jonathan Morton

Re: [Cake] lanman2018 cake talk ideas

[Dave Taht]

I got about, I don't know, 5? problematic slides, and it needs to get
to 20 by 9AM EDT, it's 3AM and I'm gonna catch some zs.

http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp

On Fri, Jun 22, 2018 at 10:14 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I have to get on the plane tomorrow night at midnight and I've tried
> to capture some of your comments and ideas in:
>
> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
>
> It's in its usual mess at this point - usually I don't share stuff
> this raw! but I'm totally open to text suggestions, graphics, etc,
> etc, etc - there's the plane flight and more than a few days left to
> pound it into shape and after I get a feel for the conference monday
> will end up doing another pass before the talk tuesday. What to say on
> each slide is helpful (jokes appreciated, a lot of what I've had to
> say so far is dripping with sarcasm which I know doesn't translate
> well).
>
> I think focusing on per host fq is probably the strongest point to
> develop and I kind of wanted a diagram of a whole bunch
> of different host types and graphically illustrating what happens vs
> fifo, fq_codel, and cake.
>
> off to pack
> On Fri, Jun 22, 2018 at 1:05 AM Pete Heist <pete@heistp.net> wrote:
>>
>>
>> On Jun 22, 2018, at 9:45 AM, Felix Resch <fuller@beif.de> wrote:
>>
>> ... has no Wikipedia page yet ...
>>
>>
>> here you go https://en.wikipedia.org/wiki/Draft:Megabit_myth
>>
>>
>> Thanks! Now the problem is solved. :)
>>
>> I only had some second thoughts, and let’s get this right and be consistent, is it:
>>
>> 1) Megabit myth
>> 2) Megabits myth
>> 3) Megabits per second myth
>>
>> #3 is the accurate one, but in this day and age every syllable can somehow slow an idea down. I’m leaning towards #2. I’ve also heard non-technical people say “how many Megabits is it?” when referring to an Internet connection, as if the “per second” part is already too much to handle. :)
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cake] lanman2018 cake talk ideas

[Pete Heist]

> On Jun 26, 2018, at 8:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I got about, I don't know, 5? problematic slides, and it needs to get
> to 20 by 9AM EDT, it's 3AM and I'm gonna catch some zs.
> 
> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
> 
> On Fri, Jun 22, 2018 at 10:14 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> I have to get on the plane tomorrow night at midnight and I've tried
>> to capture some of your comments and ideas in:
>> 
>> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
>> 
>> It's in its usual mess at this point - usually I don't share stuff
>> this raw! but I'm totally open to text suggestions, graphics, etc,
>> etc, etc - there's the plane flight and more than a few days left to
>> pound it into shape and after I get a feel for the conference monday
>> will end up doing another pass before the talk tuesday. What to say on
>> each slide is helpful (jokes appreciated, a lot of what I've had to
>> say so far is dripping with sarcasm which I know doesn't translate
>> well).
>> 
>> I think focusing on per host fq is probably the strongest point to
>> develop and I kind of wanted a diagram of a whole bunch
>> of different host types and graphically illustrating what happens vs
>> fifo, fq_codel, and cake.

Sorry I’ve been heads down testing / writing. It looks like your challenge is 20 minutes for 3+ decades of info. Quick ideas to compress it:

1) Merge and reduce slides 9 (The case for per-host fair queueing) and 11 (The need for host and flow fairness)
2) Slide 14 (comparable to htb+fq_codel) could probably go? doesn’t sell compared to other stuff
3) Merge and reduce slides 17 (Deficit based shaping) and 18 (Achieving near perfect utilization) and reduce content
4) During the presentation, go through slides 1-8 quickly, but without dismissiveness

On the plus side, I think it’s good you re-focused this on fair queueing for this audience. Nice work.

Possible joke: “Tank, I need a pilot program for a B-212 helicopter, and for SQM and Cake..."

Re: [Cake] lanman2018 cake talk ideas

[Toke Høiland-Jørgensen]

Pete Heist <pete@heistp.net> writes:

>> On Jun 26, 2018, at 8:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> I got about, I don't know, 5? problematic slides, and it needs to get
>> to 20 by 9AM EDT, it's 3AM and I'm gonna catch some zs.
>> 
>> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
>> 
>> On Fri, Jun 22, 2018 at 10:14 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>> I have to get on the plane tomorrow night at midnight and I've tried
>>> to capture some of your comments and ideas in:
>>> 
>>> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
>>> 
>>> It's in its usual mess at this point - usually I don't share stuff
>>> this raw! but I'm totally open to text suggestions, graphics, etc,
>>> etc, etc - there's the plane flight and more than a few days left to
>>> pound it into shape and after I get a feel for the conference monday
>>> will end up doing another pass before the talk tuesday. What to say on
>>> each slide is helpful (jokes appreciated, a lot of what I've had to
>>> say so far is dripping with sarcasm which I know doesn't translate
>>> well).
>>> 
>>> I think focusing on per host fq is probably the strongest point to
>>> develop and I kind of wanted a diagram of a whole bunch
>>> of different host types and graphically illustrating what happens vs
>>> fifo, fq_codel, and cake.
>
> Sorry I’ve been heads down testing / writing. It looks like your challenge is 20 minutes for 3+ decades of info. Quick ideas to compress it:
>
> 1) Merge and reduce slides 9 (The case for per-host fair queueing) and 11 (The need for host and flow fairness)
> 2) Slide 14 (comparable to htb+fq_codel) could probably go? doesn’t sell compared to other stuff
> 3) Merge and reduce slides 17 (Deficit based shaping) and 18 (Achieving near perfect utilization) and reduce content
> 4) During the presentation, go through slides 1-8 quickly, but without
> dismissiveness

+1 to all of these. Possibly also nuke slide 13 (or move it to 'extra
slides'). The setup commands are not going to mean anything to those in
the audience (I'm guessing that would be most of the audience) who are
not familiar with Linux/TC.

> On the plus side, I think it’s good you re-focused this on fair
> queueing for this audience. Nice work.

Yeah, I agree. Very nice :)

-Toke

Re: [Cake] lanman2018 cake talk ideas

[Dave Taht]

OK, a version I can live with for today is up at the same url. I still
have an hour to fiddle.

PS I love youse guys.

On Tue, Jun 26, 2018 at 3:52 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Pete Heist <pete@heistp.net> writes:
>
>>> On Jun 26, 2018, at 8:58 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> I got about, I don't know, 5? problematic slides, and it needs to get
>>> to 20 by 9AM EDT, it's 3AM and I'm gonna catch some zs.
>>>
>>> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
>>>
>>> On Fri, Jun 22, 2018 at 10:14 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>> I have to get on the plane tomorrow night at midnight and I've tried
>>>> to capture some of your comments and ideas in:
>>>>
>>>> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
>>>>
>>>> It's in its usual mess at this point - usually I don't share stuff
>>>> this raw! but I'm totally open to text suggestions, graphics, etc,
>>>> etc, etc - there's the plane flight and more than a few days left to
>>>> pound it into shape and after I get a feel for the conference monday
>>>> will end up doing another pass before the talk tuesday. What to say on
>>>> each slide is helpful (jokes appreciated, a lot of what I've had to
>>>> say so far is dripping with sarcasm which I know doesn't translate
>>>> well).
>>>>
>>>> I think focusing on per host fq is probably the strongest point to
>>>> develop and I kind of wanted a diagram of a whole bunch
>>>> of different host types and graphically illustrating what happens vs
>>>> fifo, fq_codel, and cake.
>>
>> Sorry I’ve been heads down testing / writing. It looks like your challenge is 20 minutes for 3+ decades of info. Quick ideas to compress it:
>>
>> 1) Merge and reduce slides 9 (The case for per-host fair queueing) and 11 (The need for host and flow fairness)
>> 2) Slide 14 (comparable to htb+fq_codel) could probably go? doesn’t sell compared to other stuff
>> 3) Merge and reduce slides 17 (Deficit based shaping) and 18 (Achieving near perfect utilization) and reduce content
>> 4) During the presentation, go through slides 1-8 quickly, but without
>> dismissiveness
>
> +1 to all of these. Possibly also nuke slide 13 (or move it to 'extra
> slides'). The setup commands are not going to mean anything to those in
> the audience (I'm guessing that would be most of the audience) who are
> not familiar with Linux/TC.
>
>> On the plus side, I think it’s good you re-focused this on fair
>> queueing for this audience. Nice work.
>
> Yeah, I agree. Very nice :)
>
> -Toke



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cake] lanman2018 cake talk ideas

[Sebastian Moeller]

Hi Dave,

just a few comments:

slide 17: it is not fully clear that this is about downstream only, especially "sch_cake can (with perfect framing) be at the same setpoint as the upstream, while still taking back control of the link, with better queuing." is confusing me. Isn't the  setpoint for each direction determined by the available bandwidth, so having up and downstream at the same setpoint requires a symmetrical link (aka an unicorn link in the context of residential uplinks). Or are you talking about the  same _percentage_ of the setpoint (which with cake's ingress mode should both be close to 100%).
 

slide 24: you might as well add Deutsche Telekom and it is Vodafone not Vodaphone, there see sa comma missing after Zyxel (it might make sense to move Zyxel to the other OEMs ODMs instead of into the ISPs).
Also lowet might be "lowest"?


slide 28 the GPON timeslice is 0.25 ms, it would be super intersting to look at the actual packet arrival/departure times of the latency probes, obviously not by 9 AM ;)

slide 29: not clear what this refers to, the last plot shoed total goodput, which should not care about the number of measurement flows (unless you mean more latency probe packets as these will "eat" into the bandwidth available for data packets) in other words I am confuzed ;)


slide 30: it would be nicer if the left and right plots would use the same axis segments...



> On Jun 26, 2018, at 08:58, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I got about, I don't know, 5? problematic slides, and it needs to get
> to 20 by 9AM EDT, it's 3AM and I'm gonna catch some zs.
> 
> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
> 
> On Fri, Jun 22, 2018 at 10:14 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> I have to get on the plane tomorrow night at midnight and I've tried
>> to capture some of your comments and ideas in:
>> 
>> http://www.taht.net/~d/cake/sch_cake_ieee_lanman2018.odp
>> 
>> It's in its usual mess at this point - usually I don't share stuff
>> this raw! but I'm totally open to text suggestions, graphics, etc,
>> etc, etc - there's the plane flight and more than a few days left to
>> pound it into shape and after I get a feel for the conference monday
>> will end up doing another pass before the talk tuesday. What to say on
>> each slide is helpful (jokes appreciated, a lot of what I've had to
>> say so far is dripping with sarcasm which I know doesn't translate
>> well).
>> 
>> I think focusing on per host fq is probably the strongest point to
>> develop and I kind of wanted a diagram of a whole bunch
>> of different host types and graphically illustrating what happens vs
>> fifo, fq_codel, and cake.
>> 
>> off to pack
>> On Fri, Jun 22, 2018 at 1:05 AM Pete Heist <pete@heistp.net> wrote:
>>> 
>>> 
>>> On Jun 22, 2018, at 9:45 AM, Felix Resch <fuller@beif.de> wrote:
>>> 
>>> ... has no Wikipedia page yet ...
>>> 
>>> 
>>> here you go https://en.wikipedia.org/wiki/Draft:Megabit_myth
>>> 
>>> 
>>> Thanks! Now the problem is solved. :)
>>> 
>>> I only had some second thoughts, and let’s get this right and be consistent, is it:
>>> 
>>> 1) Megabit myth
>>> 2) Megabits myth
>>> 3) Megabits per second myth
>>> 
>>> #3 is the accurate one, but in this day and age every syllable can somehow slow an idea down. I’m leaning towards #2. I’ve also heard non-technical people say “how many Megabits is it?” when referring to an Internet connection, as if the “per second” part is already too much to handle. :)
>>> 
>>> _______________________________________________
>>> Cake mailing list
>>> Cake@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>> 
>> 
>> 
>> --
>> 
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619
> 
> 
> 
> -- 
> 
> 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