Hi Jonathan,
> On Jan 15, 2016, at 01:05 , Jonathan Morton <[email protected]> wrote: > > >> On 14 Jan, 2016, at 20:53, moeller0 <[email protected]> wrote: >> >> So I have not grokked the triple algorithm fully (aka not at all), but I >> already know that what user’s are looking for is fairness by internal host >> IPs. Now, since as I explained before ingress and egress really are too >> flexible to use as direction pointers, I assume we are looking for some >> configuration parameter that contains a direction; so as long as “triple” >> allows to request fairness by source IP or by destination IP (since these >> might change depending on the interface cake is running on) all will be >> fine. I just do not see how a simple unidirectional parameter like >> “triple-iso” will allow to take the fact into account that ingress and >> egress are only relative to the sqm interface and do not necessarily align >> with the internal/WAN ingress and egress… But as I said before I do not >> claim I understand what triple-iso intends to accomplish in detail. > > The short version is that, in theory at least, I’ve found a way to ensure > fairness without needing to know which side of the interface is which. Could you please explain the fairness you are talking about here? I still want to test cake in my environment and will do a much better job if I know what behavior to expect, and frankly I am unsure what triple-iso is supposed to guarantee (I know this is my own responsibility, but getting a high level description seems more efficient than trying to deduce this from the implementation, especially given that you are not fully satisfied withe the current implementation). Thanks in advance. > By accounting for *both* source and destination host fairness at the same > time, and not placing one above the other in importance, it should all work > out in the end. The method by which I do so is probably interesting enough > to write a paper about, once I’ve got it working in practice. > > At this point, I strongly suspect I’ve made an implementation blunder, since > even single-stepping through the theoretical algorithm’s behaviour, packet by > packet, produces approximately the desired results - which are however not > reproduced in actual measurements on my LAN. Time to add more stats to the > multitude already present! > > If you want to be explicit about directionality, that’s what the two new > “dual” modes are for. The “triple isolation” algorithm is still used, but > the undesired attribute is ignored. The “triple” mode combines their effects. This is the part I can not get my head around: fairness by internal host IP (what people seem to request, with, as you alluded to before, DSCP tiers per internal host IP and per flow fairness in each tier) basically will not generally allow fairness by external IP. E.g. three internal hosts talk to 6 external hosts, fairness by internal IP will try to give 1/3 of the bandwidth to the internal hosts, fairness by external IP will give 1/6, now unless the connections are symmetric (each internal IP talks to the same number of external IPs) the actual bandwidth distribution will deviate from either 1/3 or 1/6, so what level of fairness will triple-iso aim for? With explicit directionality I can easily see how to enforce either 1/3 or 1/6 in the example... Best Regards Sebastian > > - Jonathan Morton > _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
