> On 20 Mar, 2019, at 11:48 pm, Greg White <[email protected]> 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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
