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. ce_threshold 1ms is more like signaling loudly - "this is a solid indicator of your real OWD" and "you should fiddle with your TCP's 'gain' to compensate for it" - and it's certainly a lot simpler than codel to do it this way. I haven't got around to fully evaluating a comparison between BBR with ce_threshold and a non-ecn enabled TCP vs codel, concurrently (or implementing different behaviors for ECT(1) in the TCP negotiation step) ... and... 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. Also, in doing in my network this way, it became apparent to me that - like several ecn encapsulation rfcs suggest - that when a packet is already marked CE, and we want to also mark it CE, that the rightest answer is to drop the packet - not giving pre-CE-marked flows a free ride. > In these cases, I think you have to relax and let the FQ action take care of > it. And yes, FQ handles it nicely. Got pics of that somewhere. I did do a test with ce_threshold + ecn + bbr, vs no ecn and cubic, with the usual lovely fq'd result. > - 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
