<div dir="ltr">For highly asymmetric links, but also shared media like wifi, QUIC might be a better playground for optimisations.<div><div>Not pervasive as TCP though and maybe off topic in this thread.</div><div><br></div><div><div>If the downlink is what one want to optimise, using FEC in the downstream, in conjunction with flow control could be very effective.</div><div>No need to send ACK frequently and having something like FQ_codel in the downstream would avoid fairness problems that might</div><div>happen though. I don't know if FEC is still in QUIC and used.</div></div><div><br></div><div><br></div><div>BTW, for wifi, the ACK stream can be compressed in aggregate of frames and sent in bursts. This is similar to DOCSIS upstream.</div><div>I wonder if this is a phenomenon that is visible in recent  WiFi or just negligible.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 1, 2017 at 9:45 AM, Sebastian Moeller <span dir="ltr"><<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
you do realize that the worst case is going to stay at 35KPPS? If we assume simply that the 100Mbps download rate is not created by a single flow but by many flows (say 70K flows) the discussed ACK frequency reduction schemes will not work that well. So ACK thinning is a nice optimization, but will not help the fact that some ISPs/link technologies simply are asymmetric and the user will suffer under some traffic conditions. Now the 70K flow example is too extreme, but the fact is at hight flow number with sparse flows (so fewer ACKs per flow in the queue and fewer ACKs per flow reaching the end NIC in a GRO-collection interval (I naively assume there is a somewhat fixed but small interval in which packets of the same flow are collected for GRO)) there will be problems. (Again, I am all for allowing the end user to configure ACK filtering thinning, but I would rather see ISPs sell less imbalanced links ;) )<br>
<br>
Best Regards<br>
<span class="HOEnZb"><font color="#888888">        Sebastian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Dec 1, 2017, at 01:28, David Lang <<a href="mailto:david@lang.hm">david@lang.hm</a>> wrote:<br>
><br>
> 35K PPS of acks is insane, one ack every ms is FAR more than enough to do 'fast recovery', and outside the datacenter, one ack per 10ms is probably more than enough.<br>
><br>
> Assuming something that's not too assymetric, thinning out the acks may not make any difference in the transfer rate of a single data flow in one direction, but if you step back and realize that there may be a need to transfer data in the other direction, things change here.<br>
><br>
> If you have a fully symmetrical link, and are maxing it out in both direction, going from 35K PPs of aks competing with data packets and gonig down to 1k PPS or 100 PPS (or 10 PPS) would result in a noticable improvement in the flow that the acks are competing against.<br>
><br>
> Stop thinking in terms of single-flow benchmarks and near idle 'upstream' paths.<br>
><br>
> David Lang<br>
> ______________________________<wbr>_________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
<br>
______________________________<wbr>_________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
</div></div></blockquote></div><br></div>