[Make-wifi-fast] [Cake] new code point proposed

[moeller0]

> On Apr 5, 2016, at 22:06 , Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 
>> On 5 Apr, 2016, at 21:57, Dave Taht <dave.taht at gmail.com> wrote:
>> 
>> https://tools.ietf.org/html/draft-you-tsvwg-latency-loss-tradeoff-00
> 
> Interesting.  This is obviously written around the DualQ AQM, but it seems feasible to implement within Cake’s framework.  I’m somewhat pleased that this appears to mark a move away from using ECN alone to describe whether DCTCP is in use or not.
> 
> Some of the requirements are written in a way that assumes a single queue of fixed maximum size for each of “La" and "Lo", rather than a dynamic, flow-isolated system as Cake is.  It might be reasonable to suggest clarifying the language to take these cases into account.
> 
> We can already vary the Codel parameters between tins, which provides an obvious mechanism to make the queue management much more aggressive for “La” traffic, and more relaxed for “Lo” traffic.  I don’t think we need to explicitly limit the queue allocation to “La” traffic as specified.
> 
> Another detail which differs from Cake’s view of the world is that neither La nor Lo have priority over each other.  While Cake does not implement strict priority, it does implement soft priority as part of its effort to minimise latency for the upper tins; the most explicit part of this is that bandwidth consumed by higher tins is removed from lower tins’ allocations.  However, this effect could be hidden by making the two DRR weights equal for the lower tin.
> 
> Obviously, traffic marked with the existing “low latency intent” DSCPs can be treated as “Lo” traffic when there is no admission control in place, without any requirement for re-marking.  This is consistent with what Cake does anyway.
> 
> This seems like a good excuse to overhaul Cake’s Diffserv class allocations.  I could propose a 5-class system:
> 
> Tin 0 = LLT “Lo” traffic (inc. existing low-loss & high-throughput classes), 256/256, 100%, increased target & interval.
> Tin 1 = Best Effort traffic, 256/256, 100%, standard target & interval.
> Tin 2 = LLT “La” traffic (inc. existing low-latency classes), 256/256, 100%, standard target, reduced interval.

	This might back fire, as far as I understand interval is the reaction time window for a flow, this needs to be roughly in the ballpark of the RTT, reducing it (significantly) will make the AQM quite trigger happy. This might be in line with the LA proposal, but what if LA traffic has to cross a satellite link?

Best Regards
	Sebastian


> Tin 3 = Low Priority traffic, 2048/16, 6.25%, standard target & interval.
> Tin 4 = Network Control traffic, 4096/1, 6.25%, increased target & interval.
> 
> Note that Tin 4 is almost, but not quite, strictly admission-controlled, discouraging the use of “network control” DSCPs for general traffic.  Tins 0-2 implement LLT as specified.  Tin 3 takes the unusual and counter-intuitive step of placing “low priority” traffic in a high tin, but the effect should be very similar to existing behaviour, due to the soft-priority system and the low bandwidth allocation.
> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake