Hi Toke,
> On Apr 24, 2018, at 10:47, Toke Høiland-Jørgensen <[email protected]> wrote: > > Sebastian Moeller <[email protected]> writes: > >>> On Apr 24, 2018, at 01:01, Pete Heist <[email protected]> wrote: >>> >>> >>>> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
