[Cake] Pre-print of Cake paper available

[Toke Høiland-Jørgensen]

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

-Toke