> - 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
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
