On Tue, Sep 27, 2016 at 11:56 AM, Jonathan Morton <[email protected]> wrote: > >> On 27 Sep, 2016, at 21:18, Dave Taht <[email protected]> wrote: >> >>> On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton <[email protected]> >>> wrote: >>> >>>> On 25 Sep, 2016, at 21:30, Dave Taht <[email protected]> wrote: >>>> >>>> Judging from me tearing apart how TCP BBR works (presently) with ecn, >>>> it looks like we need to add the equivalent to fq_codel ce_threshold >>>> behaviors as well. >>> >>> If I’m reading the legend correctly, you are setting ce_threshold to 1ms to >>> get the better-controlled result. But that effectively disables the codel >>> algorithm and turns it into a simple “mark all packets over 1ms sojourn” >>> for ECN capable traffic, because it’s a tighter limit than codel’s target. >>> That’s too aggressive for non-BBR traffic. >> >> Yes it is. :) However the consensus appears to be that ECN should be >> an earlier signal than drop, and the work over on the tcp-prague list >> centers around repurposing ECT(1) as more like a DCTCP multi-bit >> signal. > > My interpretation of the consensus is more subtle: we need a signal earlier > than we currently do, and with a weaker meaning, but we still need the > strong, later signal. > > I don’t think we should use CE for that; it has a long-established and > widely-deployed meaning. We *can* use ECT(1), which is presently unused in > practice.
I have been avoiding the tcp-prague, l4s, etc debates, for health reasons, and it's possible I've misunderstood something. All along I'd been assuming that a specialized TCP of some new flavor yet-to-be-agreed-upon would negotiate ECN and most/all its packets would be marked ECT(1), rather than ECT(0), and a new AQM would treat a flow like that differently, but still mark that flow with a CE that the endpoint would interpret differently. Are you saying ECT(1) would, instead, be used as a "weaker or harder" CE? >> I'm really not sure if what I've seen with ce_threshold is the >> desired behavior, vs a vs BBR, thus far - but I'd like to see the >> option for it enter cake. > > Before I even consider doing that, could you add a comparable run with the > current version of cake to that graph? COBALT is not quite identical to > Codel, and this looks like a case where one of the differences could be > important. > > - Jonathan Morton > -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
