> On 29 Sep, 2016, at 02:26, Dave Taht <[email protected]> wrote: > > 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?
The former appears to be the solution TCP Prague are keen on. It doesn’t seem like a robust, deployable solution to me, despite the tremendous amount of effort that’s gone into that class of solutions. The latter is my suggestion - to use the distinction between ECT(0) and ECT(1) as a hint, rather than a command, to slow down. I also think we should move computation of the congestion window to the receiver, as that greatly simplifies the reverse-path signalling problem. You may remember my description of ELR. I started documenting it more formally, and then got distracted by something more urgent... - Jonathan Morton _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
