Re: [Bloat] benefits of ack filtering

[Dave Taht <dave@taht.net>]

Luca Muscariello <luca.muscariello@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 <moeller0@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 <david@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