On Wed, Sep 28, 2016 at 5:34 PM, Jonathan Morton <chromatix99@gmail.com> wrote:

> On 29 Sep, 2016, at 02:26, Dave Taht <dave.taht@gmail.com> 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.

I agree that there's some big potential advantages to that. But I wouldn't say the congestion window calculation should be moved to the receiver, so much as duplicated by the receiver. Here's a link to a receiver-side congestion control patch I've been working on:

https://github.com/systemslab/tcp_inigo/tree/master/inigo_receiver

It uses TCP timestamps to keep track of the accumulated differences in one way delays, and adjusts the receive window similarly to DCTCP.

The mininet tests I've run show some promise making CUBIC and Reno share more fairly and tightening up their RTT distribution, but I need to do a lot more testing.

I'm looking forward to Eric Dumazet's usec resolution time stamp support being upstreamed so that my receiver-side technique might become useful in data centers.


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
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake



--
Andrew Shewmaker