[Cake] Pre-print of Cake paper available

[Pete Heist]

> On Apr 24, 2018, at 1:31 AM, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> Or since using the keywords would be fragile, is there a better way to know the proper sense for dual-srchost and dual-dsthost?
> 
> This is covered in the tc-cake manage: …

Oops, poor wording on my part. I meant is there a way for cake to detect which of the two modes is most likely intended automatically and default to one of them? I do understand why triple-isolate is an attractive default, and since a typical home gateway routes a few source IPs to many destination IPs, it will usually do what people expect without any configuration (except for when two clients are communicating with the same server, when it may not). It's just feedback that one of the first things I do for a cake setup is set dual-srchost / dual-dsthost as appropriate, and I was just searching for ways to make my personal preference automatic. So yeah, leave it. :)

> I'm not terribly keen on overloading the ingress and egress keywords as you suggest; certain people tend to get a bit worked up about it, and it could be confusing unless done very carefully.  Already, for the command-line interface, we have to explain what "ingress" and "egress" mean in themselves, when some of the target audience might have trouble setting the clock on their VCR.  (Also, they still have a VCR!)

I’m not either. This (along with ’nat’) were part of an overall wish that ‘cake’ without any keywords would do the “right thing” by default as often as possible, even if it means adding auto-detection logic. I don’t expect keyword changes at this point unless it’s really clear how to implement something. I’m old enough to get the VCR joke, and to remember my tiny H and M buttons with substandard tactile qualities...

>> - Not in the paper, but is the ‘wash’ keyword really needed?
> 
> You'll have to ask Dave about that - he's the one who insists on having it!  The only coherent explanation I can immediately think of is to bypass wifi's builtin medium-grant prioritization.

There’s an recommendation in the man page about Comcast that I didn’t follow, but that that second one is also true. I was experimenting with sending traffic over IPIP tunnels, which hides the original markings from the WiFi stack, which might be desirable in a WiFi backhaul, for example. ‘wash' would be another way to do that, although then the original markings wouldn’t be preserved, so the end result is a bit different.

>> - 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?
> 
> Wifi *or* 3G, etc.  I'm very conscious of this problem, but it's hard to solve in the qdisc itself.  It's definitely better to solve it at the upstream end of the link and with real-time medium awareness.  Wifi can have that today, with the right hardware, but good luck getting the 2G/3G/4G vendors on side.

It might still be worth mentioning in an academic paper, but this (all of this) is only feedback… :)