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

[moeller0]

Hi Jonathan,

> On Apr 6, 2016, at 19:16 , Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 
>> On 6 Apr, 2016, at 13:30, moeller0 <moeller0 at gmx.de> wrote:
>> 
>>> 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.
> 
> SSH is not so latency-sensitive as to require “La” service; round-trip response times of a quarter second are acceptable, though multiple seconds are not.  With flow isolation, best-effort service is sufficient.
> 
> Even in the best-effort tin, Cake provides flow isolation and host isolation, so any remaining latency (assuming we’re not in severe overload) is self-induced by the flow itself.  LLT, as I read it, allows traffic to explicitly indicate that even self-induced latency is unacceptable, using the “La” codepoint.  Hence the more aggressive AQM setting.
> 
> However, SSH will work quite happily in an “La” class if ECN is used.  The marking rate may be high in some circumstances, but packets will not be dropped, so application latency remains low.  Some applications may benefit from this behaviour.

	Okay, thanks.

> 
>> Regarding UDP the challenge I see is to differentiate between responsive and unresponsive flows.
> 
> Which we fundamentally can’t do quickly enough to control the queue to “La” standards, so it’s not worth trying for this purpose.
> 
> So we should pessimistically assume that “La” marked traffic is unresponsive, and control all of it aggressively.  Responsive traffic which uses an “La” mark will run at lower throughput, which is exactly the expected tradeoff.

	Color me sceptic here.as all the other DSCPs this will only ever work reliable on egress (and in lab settings). I like the implied trade-offs of LA and LO, but I guess they will get as much exposure/distribution as all the other DSCP schemes (namely, not universal enough to be really useful). I looks like a “cute” new mode to teach cake though to allow actual testing.

> 
>> 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).
> 
> This is actually a very good point.  

	Sorry, that was an accident then ;)

> DualQ is supposedly designed to allow DCTCP to coexist with conventional traffic, and LLT is essentially a spec for DualQ.  But to maintain minimum latency for DCTCP, both the forward and reverse paths need to be marked “La”.  So if DCTCP really assumes zero reverse-path loss, it will incur a higher round-trip delay due to the reverse path being marked “Lo”.

	But the DCTCP traffic is assumed to not leave the building, so to speak?

Best Regards
	Sebastian

> 
> I do sometimes wonder what those guys are smoking.
> 
> - Jonathan Morton
>