[Cake] cake for net-next 4.8

[Andrew Shewmaker]

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

>
> > On 29 Sep, 2016, at 02:26, Dave Taht <dave.taht at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 
Andrew Shewmaker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20160929/6e8bf87e/attachment.html>