Re: [Bloat] benefits of ack filtering

[Luca Muscariello <luca.muscariello@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

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.

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.










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
>

[-- Attachment #2: Type: text/html, Size: 4135 bytes --]