Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Jonathan Morton <[e-mail]>]

> On 20 Mar, 2019, at 11:48 pm, Greg White <[e-mail]> wrote:
> 
> the dual queue mechanism is not the only way to support L4S and TCP Prague.  As we’ve mentioned a time or two, an fq_codel system can also support L4S and TCP Prague.  I’m not aware that anyone has implemented it to test it out yet (because so far most interest has been on dual-queue), but I think the simplest version is:
>  
> At dequeue:
> If packet indicates ECT(1):
>                 If sojourn_time > L4S_threshold:
>                                 Set CE*, and forward packet
>                 Else:
>                                 Forward packet
> Else:
>                 Do all the normal CoDel stuff
>  
> In many cases, all of the packets in a single queue will either all be ECT(1) or none of them will.  But, to handle VPNs (where a mix of ECT(1) and non-ECT(1) packets could share a queue), I would think that including the ECN field in the flow hash would keep those packets separate.   
>  
> *a more sophisticated approach would be to mark CE based on a ramp function between a min_thresh and max_thresh, which could be implemented as a random draw, or via a counting function

The above looks remarkably similar to our proof-of-concept for an SCE middlebox.  Essentially:

At dequeue:
	Do all the normal Codel stuff
	If packet (still) carries ECT(0):
		If sojourn_time > SCE_threshold:
			Set SCE
	Forward packet

And yes, a ramp function between 0 and codel_target would work better.  The above gives us something to test against with minimum hassle.

 - Jonathan Morton