<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 5:34 PM, Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
> On 29 Sep, 2016, at 02:26, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br>
><br>
> All along I'd been assuming<br>
> that a specialized TCP of some new flavor yet-to-be-agreed-upon would<br>
> negotiate ECN and most/all its packets would be marked ECT(1), rather<br>
> than ECT(0), and a new AQM would treat a flow like that differently,<br>
> but still mark that flow with a CE that the endpoint would interpret<br>
> differently.<br>
><br>
> Are you saying ECT(1) would, instead, be used as a "weaker or harder" CE?<br>
<br>
</span>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.<br>
<br>
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><a href="https://github.com/systemslab/tcp_inigo/tree/master/inigo_receiver" target="_blank">https://github.com/systemslab/<wbr>tcp_inigo/tree/master/inigo_<wbr>receiver</a></font><br></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">It uses TCP timestamps to keep track of the accumulated differences in one way delays, and adjusts the receive window similarly to DCTCP.</font></div><div class="gmail_default"><br></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">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.</font></div></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">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.</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
You may remember my description of ELR.  I started documenting it more formally, and then got distracted by something more urgent...<br>
<span><font color="#888888"><br>
 - Jonathan Morton<br>
</font></span><div><div><br>
______________________________<wbr>_________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Andrew Shewmaker</div>
</div></div>