Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation

[Sebastian Moeller <[e-mail]>]

> On Apr 4, 2019, at 11:40, Greg White <[e-mail]> wrote:
> 
> 
> 
> On 4/4/19, 1:28 AM, "Jonathan Morton" <[e-mail]> wrote:
> [...]    
>    The present out-of-tree version of Cake supports an L4S-style high-fidelity ECN marking method, simultaneously with conventional ECN marking.  It does so using the SCE signalling method, with ECT(1) being an output rather than an input.  This is, in fact, the running code we had at the time of our TSVWG presentation.
> 
> [GW] Has any progress been made on a variant of Cake that utilizes the L4S ECT(1) semantic?  It would be useful for comparison purposes.  
> 
> [...]    
>> Alternatively, if fq_codel/CAKE were to treat ECT(1) as non-ECT (or implement the L4S style ECN) this would again not be an issue, I believe.
> 
>    Perhaps, but I thought FQ AQMs weren't much of a problem to begin with - aside from the ingress-queuing problem?  
> 
> [GW] Well, a goal would be for FQ AQMs to provide appropriate high-fidelity congestion signals to L4S flows so that they can achieve all four Ls and the S.  Failing that, to not provide weaker congestion signals for L4S flows as compared to classic TCP.  It isn't a problem from a fairness perspective, but the goal is low latency after all.    This seems like a fairly simple change to FQ.
> 
>    I'm also reluctant to interpret ECT(1) or CE incompatibly with RFC-3168, unless given very good reason - and I currently have a good counter-argument.  If I may quote from that document, it does specifically contemplate use of the fourth codepoint to signal "mild congestion":
> 
>>   One possibility might have been for the data sender to use the fourth
>>   ECN codepoint to indicate an alternate semantics for ECN.  However,
>>   this seems to us more appropriate to be signaled using a
>>   differentiated services codepoint in the DS field.
>> 
>>   A second possible use for the fourth ECN codepoint would have been to
>>   give the router two separate codepoints for the indication of
>>   congestion, CE(0) and CE(1), for mild and severe congestion
>>   respectively.
> 
> [GW] I don't believe that the RFCs are on your side here.   RFC 3168 contemplates, and rejects, that definition of ECT(1),

[SM I believe this to be caused by not considering pulse modulation though, as the argument is that a single code-point might not be "rich" enough to signal graded congestion information, but IMHO DCTCP shows that this is solved. In any way RFC 3168 seems a bit dated for this discussion as all agree to go beyond it, no?


> so I'm not sure how you read it as supporting the use. RFC 3168 explicitly defines ECT(1) as being a transport sender signal that it is "ECN Capable Transport".  I don't see how you can claim adherence to RFC 3168, yet use ECT(1) to mean (S)CE.  Moreover, RFC 3168 has been updated by (Standards-Track) RFC 8311, which enables the L4S experiments, and which the SCE approach also violates.  
> 
> [...] 
>    I can't help noticing, meanwhile, that DualQ seems to be designed for use wherever a single-queue AQM would normally fit (though I have my doubts that it will work on much hardware already deployed at crucial locations).  
> 
> [GW] We have worked very closely with all of the DOCSIS equipment vendors to ensure that Low Latency DOCSIS (including dual-queue) is implementable via a firmware update to ALL existing DOCSIS 3.1 CMs and CMTS that are in the field today.  In some markets that is more than 90% of deployed CMTSs. I obviously can't speak to other access network technologies, but to the extent that forwarding architectures are similar, I would presume that doubling the number of queues is significantly simpler than multiplying by 1000.

	But why, in the end memory is linear and your proposed mandatory "Annex P Queue Protection Algorithm (Normative") seems to care all the costs of tracking flows already, so why is that considerably cheaper than using that information also for scheduling purposes?

> 
>    Yet at the same time, you claim such single-queue AQMs are presently (and will remain) so rare that you haven't even developed a method of reliably detecting them.  This seems like an important discrepancy.
> 
> [GW] The concern would be single-queue *ECN* AQMs. Single-queue packet drop AQMs do exist.

[SM] What about my hobby-horse "ingress-ECN-aware-fq-AQM"?


> 
>    Meanwhile, work continues.
> 
> [GW] Why?  It seems to me that the L4S approach can be implemented easily in fq_codel and CAKE, as well as in systems that can only realistically support dual-queue.

[SM] if that system has memory and a CPU it _can_ support fq as well, that is a _choice_ not an _impossibility_. It might be un-economically, sure. But again, why will such a device be able to do Queue Protection then?


>  It has been demonstrated to provide scalable throughput and ultra-low loss and queuing delay

Which sounds greater than it is since most applications care for end-to-end latency, and L4S basically moves (a part of) the queueing delay from the bottleneck AQM back into the sending application, it does not remove that latency completely.

> (which, I think, is the goal of SCE as well), and has quite a bit of support and momentum behind it. The philosophical debate as to which is better, dualq-coupled-aqm or FQ, can continue and implementers can choose whichever they like.  I don't doubt that the SCE signaling method could be used in a variant of DCTCP, but the *huge* downside is that it can only work on bottleneck links that are able (or willing) to support FQ,

[SM] Why, the AQM will simply supply all ECN enabled with the graded information about the queueing load of the AQM, it is up to the endpoints to make sense out of this.

> which will be precious few.  In 2-3 years' time, 10s of millions of actual bottleneck links in broadband networks will be supporting dual-queue.

[SM]	I guess most bottlenecks nowadays support a variant of RED but support dies not equal exercise it. But sure I like how the DOCSIS standards-process  can influence a large swath of critical bottleneck links, more power to you.

>  It seems that the only real argument in favor of the SCE signaling method is the fallback in presence of single-queue classic ECN (unless you think blocking implementers from supporting dual-queue is some kind of perverse benefit).  

[SM] I see the SCE proposal as the better more evolutionary approach forward, the L4S approach basically spells, the current state is unrecoverable and we need to start fresh, but then does no much of that sort (re-using PIE and DCTCP is also nicely evolutionary).

> Help analyzing (and addressing if need be) that situation would be the most effective way of achieving the shared goal of low latency scalable congestion control.  Continuing to push for (or worse, deploy) an incompatible solution just increases the risk that no one will be able to achieve that goal.

[SM] these wise words typically apply to both sides of a discussion and have just as much merits one way or he other. I note that in reality we often see something else, alternative approaches duking it out and driving their evolution exactly because they are not the only game in town....


Best Regards
	Sebastian