[Cake] Pre-print of Cake paper available

[Jonathan Morton]

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

This is covered in the tc-cake manpage:

.B dual-srchost
.br
	Flows are defined by the 5-tuple, and fairness is applied first over
source addresses, then over individual flows.  Good for use on egress traffic
from a LAN to the internet, where it'll prevent any one LAN host from
monopolising the uplink, regardless of the number of flows they use.
.PP
.B dual-dsthost
.br
	Flows are defined by the 5-tuple, and fairness is applied first over
destination addresses, then over individual flows.  Good for use on ingress
traffic to a LAN from the internet, where it'll prevent any one LAN host from
monopolising the downlink, regardless of the number of flows they use.
.PP

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

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

Following on from the above, home gateways tend to have a GUI which can be made to handle this sort of thing more intuitively.  It helps GUI programmers if the API is reasonably stable and orthogonal.

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

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

Sensing the link rate via changes in flow latency is an attractive idea, but there are subtleties which I haven't found a satisfactory solution to yet.  By nature, such an algorithm would need to be very conservative and could not react quickly enough to guarantee QoS.

 - Jonathan Morton