On 4 December 2017 at 00:27, Juliusz Chroboczek <j...@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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat Regards, Ryan Mounce _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat