Sebastian Moeller <moell...@gmx.de> writes: >> On Apr 24, 2018, at 01:01, Pete Heist <p...@eventide.io> wrote: >> >> >>> On Apr 23, 2018, at 10:39 AM, Toke Høiland-Jørgensen <t...@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 _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
