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

[Jonathan Morton]

> On 5 Apr, 2016, at 23:28, moeller0 <moeller0 at gmx.de> wrote:
> 
>> 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?

The entire point *is* to make the AQM very trigger-happy for “La" traffic.  By selecting the “La” DSCP (or any other low-latency DSCP, for that matter), the originator of the traffic is requesting that behaviour.  Reduced throughput is an expected side-effect.

Satellite links have nasty effects on latency-sensitive traffic all by themselves.  I don’t think we need to worry too much about that combination.  If the flow uses less than its fair share of bandwidth, the AQM won’t trigger anyway.

In any case, Codel’s behaviour and default parameters are tuned for conventional TCP.  Latency-sensitive traffic generally doesn’t use conventional TCP, so the usual assumptions go out of the window.  I propose retaining the standard “target” parameter on Tin 2 to avoid triggering AQM with a single large packet, but reducing “interval” to make Codel’s behaviour more suitable for UDP and DCTCP traffic.

 - Jonathan Morton