[Bloat] benefits of ack filtering

[Dave Taht]

On Fri, Dec 1, 2017 at 10:57 AM, Luca Muscariello
<luca.muscariello at gmail.com> wrote:
> https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html
>

Good news all over. I wonder what happens on cisco against the suite
of tests toke made available here:

https://www.cs.kau.se/tohojo/airtime-fairness/

People are getting some good results with this stuff:
https://forum.lede-project.org/t/ubiquiti-unifi-ac-mesh/4499/4
(however, I currently have 6 bricked ones that I need to recover, and
am having way more fun in simulation that I imagined I could ever
have)....

> On Fri 1 Dec 2017 at 19:43, Dave Taht <dave at taht.net> wrote:
>>
>> Luca Muscariello <luca.muscariello at 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 at 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 at 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 at lists.bufferbloat.net
>> >     > https://lists.bufferbloat.net/listinfo/bloat
>> >
>> >     _______________________________________________
>> >     Bloat mailing list
>> >     Bloat at lists.bufferbloat.net
>> >     https://lists.bufferbloat.net/listinfo/bloat
>> >
>> >
>> >
>> > _______________________________________________
>> > Bloat mailing list
>> > Bloat at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619