> On 20 Mar, 2019, at 11:48 pm, Greg White <g.wh...@cablelabs.com> 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 Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat