[Cake] new code point proposed

[moeller0]

Hi Jonathan,

> On Apr 5, 2016, at 22:40 , Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 
>> 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.  

	Well, yes but not too trigger happy.

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

	Or rather TCP-friendly flows. My point is a well-behaved UDP (SCTP/whatever) flow might respond just as well as a TCP-flow, so TCP versus other protocols does not seem to be the optimal categorization here.

> Latency-sensitive traffic generally doesn’t use conventional TCP, so the usual assumptions go out of the window.  

	I fear this is not correct. Ssh is mostly using TCP and is latency sensitive (to some degree), I agree that it would not be too well served with LA though.

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

	Okay these are too different beasts: UDP might be too broad a stroke to use here, unresponsive UDP flows maybe. DCTCP will require much tighter target and interval settings anyway and does not seem to be fit for the wider internet (with its assumption of ZERO % ack packet loss). That said, I believe you already made cake fit for short RTT environments (units seems to be micro seconds):
} else if (strcmp(*argv, "datacentre") == 0) {
                        interval = 100;
                        target   =   5;

;)

Regarding UDP the challenge I see is to differentiate between responsive and unresponsive flows. In any case we need to give the endpoint-pair one RTT worth of time to signal packet loss or ECN to the receiver and back to the sender (actually the full true RTT is the shortest time we can expect to see behaviour changes of the sender at the AQM-queue), so reducing interval << RTT will simply prune the flow excessively before the sender can react. If we would know that the sender does not care and will not reduce its rate voluntarily dropping hard early might be a good strategy, but if we see a tcp-friendly udp flow then asking nicely might be better. 
	I fail to see decent heuristics to discriminate between both types (short of keeping a history per flow, and assume each flow to be friendly first and only switch dropping strategy if the flow did not react properly and timely to drops/marks).

Best Regards


> 
> - Jonathan Morton
>