[Cake] Pre-print of Cake paper available
toke at toke.dk
Tue Apr 24 04:47:50 EDT 2018
Sebastian Moeller <moeller0 at gmx.de> writes:
>> On Apr 24, 2018, at 01:01, Pete Heist <pete at eventide.io> wrote:
>>> 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.
>> - 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?
> The challenge is to find a heuristic that covers all reasonable
> use cases and does no harm in unexpected cases. I could envision
> setting up a cake instance on the upstream end of say a
> microwave link, there "ingress" seems like the appropriate
> keyword (as the goal would be to keep the link non-congested),
> but for customer fairness "dual-srchost" would be the
> appropriate keyword (or just srchost if all the ISP cares for is
> inter-customer fairness). Sure this will not work with IPv6 (for
> that we would either need to llok at the MACs or IMHO preferably
> the IPv6 prefix (or the partially masked IPv6 IP-address, I
> believe this to be better than MAC adresses as the ISP can
> easily control the prefix, but I digress)).
I don't think we can make assumptions on ISP deployments. The shaper may
or may not be at the point of NAT, and per-customer prefix size can
vary. To properly support the ISP per-customer fairness use case, we'd
probably need to support arbitrary filtering (like what FQ-CoDel
supports with 'tc filter'). And I think, if we wanted to support the ISP
case, that a per-customer *shaper* is more useful...
More information about the Cake