Re: [Cake] Pre-print of Cake paper available

[Pete Heist <pete@eventide.io>]

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


> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen <toke@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.

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.

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

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

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


[-- Attachment #2: 1804.07617v1_pete.pdf --]
[-- Type: application/pdf, Size: 468172 bytes --]