<div><a href="https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html">https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html</a></div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div>On Fri 1 Dec 2017 at 19:43, Dave Taht <<a href="mailto:dave@taht.net">dave@taht.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Luca Muscariello <<a href="mailto:luca.muscariello@gmail.com" target="_blank">luca.muscariello@gmail.com</a>> writes:<br>
<br>
> For highly asymmetric links, but also shared media like wifi, QUIC might be a<br>
> better playground for optimisations.<br>
> Not pervasive as TCP though and maybe off topic in this thread.<br>
<br>
I happen to really like QUIC, but a netperf-style tool did not exist for<br>
it when I last looked, last year.<br>
<br>
Also getting to emulating DASH traffic is on my list.<br>
<br>
><br>
> If the downlink is what one want to optimise, using FEC in the downstream, in<br>
> conjunction with flow control could be very effective.<br>
> No need to send ACK frequently and having something like FQ_codel in the<br>
> downstream would avoid fairness problems that might<br>
> happen though. I don't know if FEC is still in QUIC and used.<br>
><br>
> BTW, for wifi, the ACK stream can be compressed in aggregate of frames and sent<br>
> in bursts. This is similar to DOCSIS upstream.<br>
> I wonder if this is a phenomenon that is visible in recent WiFi or just<br>
> negligible.<br>
<br>
My guess is meraki deployed something and I think they are in in the top<br>
5 in the enterprise market.<br>
<br>
I see ubnt added airtime fairness (of some sort), recently.<br>
<br>
><br>
> On Fri, Dec 1, 2017 at 9:45 AM, Sebastian Moeller <<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>> wrote:<br>
><br>
>     Hi All,<br>
><br>
>     you do realize that the worst case is going to stay at 35KPPS? If we assume<br>
>     simply that the 100Mbps download rate is not created by a single flow but by<br>
>     many flows (say 70K flows) the discussed ACK frequency reduction schemes<br>
>     will not work that well. So ACK thinning is a nice optimization, but will<br>
>     not help the fact that some ISPs/link technologies simply are asymmetric and<br>
>     the user will suffer under some traffic conditions. Now the 70K flow example<br>
>     is too extreme, but the fact is at hight flow number with sparse flows (so<br>
>     fewer ACKs per flow in the queue and fewer ACKs per flow reaching the end<br>
>     NIC in a GRO-collection interval (I naively assume there is a somewhat fixed<br>
>     but small interval in which packets of the same flow are collected for GRO))<br>
>     there will be problems. (Again, I am all for allowing the end user to<br>
>     configure ACK filtering thinning, but I would rather see ISPs sell less<br>
>     imbalanced links ;) )<br>
><br>
>     Best Regards<br>
>     Sebastian<br>
><br>
><br>
><br>
>     > On Dec 1, 2017, at 01:28, David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>> wrote:<br>
>     ><br>
>     > 35K PPS of acks is insane, one ack every ms is FAR more than enough to do<br>
>     'fast recovery', and outside the datacenter, one ack per 10ms is probably<br>
>     more than enough.<br>
>     ><br>
>     > Assuming something that's not too assymetric, thinning out the acks may<br>
>     not make any difference in the transfer rate of a single data flow in one<br>
>     direction, but if you step back and realize that there may be a need to<br>
>     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<br>
>     direction, going from 35K PPs of aks competing with data packets and gonig<br>
>     down to 1k PPS or 100 PPS (or 10 PPS) would result in a noticable<br>
>     improvement in the flow that the acks are competing against.<br>
>     ><br>
>     > Stop thinking in terms of single-flow benchmarks and near idle 'upstream'<br>
>     paths.<br>
>     ><br>
>     > David Lang<br>
>     > _______________________________________________<br>
>     > Bloat mailing list<br>
>     > <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
>     > <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
><br>
>     _______________________________________________<br>
>     Bloat mailing list<br>
>     <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
>     <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div></div>