[Bloat] [Make-wifi-fast] benefits of ack filtering

Dave Taht dave at taht.net
Sun Dec 3 22:44:27 EST 2017


Jan Ceuleers <jan.ceuleers at gmail.com> writes:

> On 03/12/17 11:35, Juliusz Chroboczek wrote:
>> I'm lost here.  What exact problem is the ACK hack supposed to work
>> around?  Ridiculous amount of asymmetry in the last-hop WiFi link, or
>> outrageous amounts of asymmetry in a transit link beyond the last hop?
>
> My understanding is that the issue that gave rise to this discussion was
> concerned with upstream bandwidth conservation in the uplink of a DOCSIS
> network by the cable modem dropping a large percentage of upstream TCP ACKs.
>
> One element of that discussion was the question as to whether it was OK
> for middleboxes (such as in this case cable modems) to reduce the number
> of TCP ACKs, or whether instead the TCP stacks in the endpoints should
> be made to send fewer such ACKs in the first place.
>
> I then added more confusion by saying that in the case of wifi-connected
> endpoints the upstream TCP ACKs also compete for airtime with the
> downstream flow. Of course this no longer has anything to do with the
> cable modem.

More generally, the case where you have a queue containing acks, stored
up for whatever reason (congestion, media access, asymmetry), is a
chance for a middlebox or host to do something "smarter" to thin them
out.

Acks don't respond to conventional congestion control mechanisms anyway.

There is another case (that I don't support) where you would try to
filter out acks on the fly without a queue (similar to how a policer
works). The flaws of this approach are many, including tail loss,
which the concept of filtering down (reducing?) a queue, doesn't have.

fq_codel has a tendency to gather up flows into a quantum (usually 1514
bytes), which translates out to 22 ipv4 acks before it will switch flows.

The cake implementation will always deliver the lastmost ack packet, and
also has some compensations for stuff in slow start.

(it could use a more formal state machine, and perhaps tuning out the
 sparse flow optimization, and more testing. It certainly is not fast
 code, but still cheaper than the hashing bits in cake)

> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


More information about the Bloat mailing list