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