[Cake] Pre-print of Cake paper available

Tue Apr 24 04:17:47 EDT 2018


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


> 
> - If ‘nat’ is not the default, won’t host isolation not work by default for most home gateways, almost all of which do nat? (Untested assumption.)

	It will for IPv6 out of the box, but for IPv4 it will regress to per flow fairness

> 
> - Not in the paper, but is the ‘wash’ keyword really needed?

	I believe that it would be preferable to have; one use case is not to leak one's internal DSCPs to the ISP as well as to protect the internal network from inapprpriate dscp marks coming from upstream. Why do this  in cake? It turns out cake already has all the required information at hand and setting up another qdisc to do this seems rather comlpicated. From an enduser's persprective it is nice if cake simply offers to do this as well.

> 
> - Is it worth mentioning that when the home gateway’s uplink is WiFi, shaping is hard to do reliably, overhead and framing compensation can’t even be implemented, and that this is all more properly handled in the WiFi specific work?
> 
> - One of the biggest deployment challenges (not unique to cake) is that most people have to use shaping, since deploying cake on their gateway’s external interface isn’t practical. But setting the rate properly for shaping isn’t always straightforward.

	That is true to some degree, but the overall algorithm is not that hard: Set the shaper at 50% of contracted rate and measure the bufferbloat (depending on the expertise of the user either via flent or the dslreports speedtest); if bufferbloat acceptable set shaper higher (by 50% of the remaining difference to 100% contracted rate) or if unaceptable lower. Really just a binary search for the acceptable limits. Now this should be done individually for each shaper direction. The final proof of the pudding is to see how this shaper copes with a bi-directional saturating load (like flent's rrul). (Okay okay, the real test would be a saturating load consisting out of really small packets, but that will be to esoteric for most users and should have only little relevance for normal use as saturating loads typically use larger packets...)

> This is sheer speculation, but could observed latency (obtained by passively measuring TCP RTT, for instance) be used as a signal to control the rate?

	It can to some degree, gargoyle does something like that, but it really is just approximate unless one has reliable robust one-way latency measurements, otherwise increasing RTT could be caused by either ingress, egress or even both making it somewhat hard to decide which rate to reduce. TCP RTT seems okay, as long as the endhost is close enough, as attempting to fix bad peering/transits by shaping on the last mile might be a bit optimistic. (Or rather altruistic as in that case all one gets is less bandwidth but most likely no latency improvement).


> I can only imagine this might be difficult to get right (though I would’ve thought what BBR does is also), so just take this as food for thought...
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1804.07617v1_pete.pdf
Type: application/pdf
Size: 468172 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180424/dd012a71/attachment-0001.pdf>
-------------- next part --------------
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake