Re: [Bloat] benefits of ack filtering

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

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

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 <dave@taht.net> wrote:

> 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
>

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