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

Reply via email to