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

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Sebastian Moeller <moeller0@gmx.de> writes:

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

Well I just meant that there are many ways to deploy a shaper in an ISP
context (centrally in the network, at the next hop from the customer,
etc).

Looking at those threads, they seem to be increasing the number of
queues. Not sure they need to, but, well, there's nothing in principle
that says this couldn't be configurable (it is in FQ-CoDel). It would
need a bit of a reorg of the current code, though, so that would be a
thing for later I guess...

-Toke