https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html
On Fri 1 Dec 2017 at 19:43, Dave Taht <d...@taht.net> wrote: > Luca Muscariello <luca.muscarie...@gmail.com> writes: > > > For highly asymmetric links, but also shared media like wifi, QUIC might > be a > > better playground for optimisations. > > Not pervasive as TCP though and maybe off topic in this thread. > > I happen to really like QUIC, but a netperf-style tool did not exist for > it when I last looked, last year. > > Also getting to emulating DASH traffic is on my list. > > > > > If the downlink is what one want to optimise, using FEC in the > downstream, in > > conjunction with flow control could be very effective. > > No need to send ACK frequently and having something like FQ_codel in the > > downstream would avoid fairness problems that might > > happen though. I don't know if FEC is still in QUIC and used. > > > > BTW, for wifi, the ACK stream can be compressed in aggregate of frames > and sent > > in bursts. This is similar to DOCSIS upstream. > > I wonder if this is a phenomenon that is visible in recent WiFi or just > > negligible. > > My guess is meraki deployed something and I think they are in in the top > 5 in the enterprise market. > > I see ubnt added airtime fairness (of some sort), recently. > > > > > On Fri, Dec 1, 2017 at 9:45 AM, Sebastian Moeller <moell...@gmx.de> > wrote: > > > > Hi All, > > > > 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 ;) ) > > > > Best Regards > > Sebastian > > > > > > > > > On Dec 1, 2017, at 01:28, David Lang <da...@lang.hm> wrote: > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > Stop thinking in terms of single-flow benchmarks and near idle > 'upstream' > > paths. > > > > > > David Lang > > > _______________________________________________ > > > Bloat mailing list > > > Bloat@lists.bufferbloat.net > > > https://lists.bufferbloat.net/listinfo/bloat > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > > > > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat >
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat