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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Toke,



> On Apr 24, 2018, at 10:47, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>>> On Apr 24, 2018, at 01:01, Pete Heist <pete@eventide.io> wrote:
>>> 
>>> 
>>>> 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?
>> 
>> 	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.

Sure we do not really need to: https://forum.lede-project.org/t/transparent-cake-box/2161/4?u=moeller0 and https://forum.lede-project.org/t/lede-as-a-dedicated-qos-bufferbloat-appliance/1861/14?u=moeller0
so it looks like one person already use cake in an small ISP context. Now 1 is not a very convincing number, but certainly larger than zero... 


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

Yes, I assume though that these would need to run on the boxes ISPs use to terminate the customer lines; but cake might still make sense for fair sharing of bottlenecks.

Best Regards
	Sebastian

> 
> -Toke