[Cake] Pre-print of Cake paper available

[Toke Høiland-Jørgensen]

Pete Heist <pete at eventide.io> writes:

>> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> 
>> Last week we submitted an academic paper describing Cake. A pre-print is
>> now available on arXiv: https://arxiv.org/abs/1804.07617
>> 
>> Comments welcome, of course :)
>
>
> Nice work overall… :) Below is some feedback on content, and attached
> is a marked up PDF with some feedback on grammar and wording. Click
> the vanilla squares to show the notes.

Thanks! A lot of those should have been fixed before submission; boy,
did I make a mess of verb tenses... Ah well, I'll incorporate your
fixes, so they will be fixed for the camera ready (assuming it gets
accepted) :)

> Content:
>
> - I wish there were some reference on how widespread of a problem
> bufferbloat actually is on the current Internet. That would bolster
> the initial assertion in the introduction.

Hmm, I do actually have a paper of my own that I could cite for this ;)
The trouble is that we have a pretty tight page limit, and adding
another reference takes us over that, meaning we would have to cut
something else. And I think we can do without in an academic paper
context at least...

> - Thank you, I finally “get" triple-isolate. :) But I find it easier
> to understand the behavior of dual-srchost and dual-dsthost, and I
> think most would prefer its behavior, despite the fact that it needs
> to be configured manually. Just a thought, knowing that cake currently
> targets home gateways, and that there are now the egress and ingress
> keywords, could host isolation default to dual-srchost for egress mode
> and dual-dsthost for ingress mode? Or since using the keywords would
> be fragile, is there a better way to know the proper sense for
> dual-srchost and dual-dsthost?
>
> - If ‘nat’ is not the default, won’t host isolation not work by
> default for most home gateways, almost all of which do nat? (Untested
> assumption.)

I think these questions are actually better handled as userspace policy
issues. For instance, in sqm-scripts we could reasonably default to
dual-srchost on egress and dual-dsthost on ingress, as we know which is
which.

> - Not in the paper, but is the ‘wash’ keyword really needed?

Is anything really *needed*? ;) It's useful in settings where you want to
clear diffserv markings, and not in other places...

> - Is it worth mentioning that when the home gateway’s uplink is WiFi,
> shaping is hard to do reliably, overhead and framing compensation
> can’t even be implemented, and that this is all more properly handled
> in the WiFi specific work?
>
> - One of the biggest deployment challenges (not unique to cake) is
> that most people have to use shaping, since deploying cake on their
> gateway’s external interface isn’t practical. But setting the rate
> properly for shaping isn’t always straightforward. This is sheer
> speculation, but could observed latency (obtained by passively
> measuring TCP RTT, for instance) be used as a signal to control the
> rate? I can only imagine this might be difficult to get right (though
> I would’ve thought what BBR does is also), so just take this as food
> for thought...

I'd categorise these as relevant issues that we don't have space to
discuss in the paper ;)

-Toke