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

[Ryan Mounce]

On 4 December 2017 at 00:27, Juliusz Chroboczek <jch at irif.fr> 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.
>
> Ok, that's what I thought.  I'm glad we agree that WiFi is a different issue.
>
> A TCP Ack is 40 bytes.  A data packet is up to 1500 bytes.
>
> As far as I know, DOCSIS has an asymmetry factor that is between 4 and 10,
> depending on the deployment.  With worst case asymmetry being 10, this
> means that you can send an Ack for every data packet with 400 byte data
> packets, every second data packet with 200 byte data packets.  If the
> asymmetry is a more reasonable 4, then the figures are 100 and 50
> respectively.
>

Many would kill for a 10:1 DOCSIS connection. 50:1 is not rare, and I
have personally been subscribed to a near 100:1 service.

Either way, the issue is not so much ACKs from downloads on an
otherwise idle link. The real issue is when the ACKs are contending
with a file upload, in this case download speeds will suffer if ACKs
are naively tail-dropped. Recovering extra bandwidth for the file
upload can be a happy side-effect.

You're also only counting IP packet length. The DOCSIS shaper deals
with ethernet frames so 58 / 1518 bytes.

> Try as I might, I fail to see the problem.  Are we advocating deploying
> TCP-aware middleboxes, with all the problems that entails, in order to
> work around a problem that doesn't exist?
>
> -- Juliusz
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


Regards,
Ryan Mounce