On Sun, 3 Dec 2017, Juliusz Chroboczek wrote:
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
I can buy 300/10 megabit/s access from my cable provider. So that's a lot worse. My cable box has 16 downstream channels, and 4 upstream ones. Each channel is TDM based, and there is some kind of scheduler granting sending opportunities for each channel to each modem, as needed. I'm not a DOCSIS expert.
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?
If I understand correctly, DOCSIS has ~1ms sending opportunities upstream. So sending more than 1kPPS of ACKs is meaningless, as these ACKs will just come back to back at wire-speed as the CMTS receives them from the modem in chunks. So instead, the cable modem just deletes all the sequential ACKs and doesn't even send these back-to-back ones.
LTE works the same, it's also frequency divided and TDM, so I can see the same benefit there of culling sequential ACKs sitting there in the buffer. I don't know if this is done though.
I've seen people I think are involved in TCP design. They seem to be under the impression that more ACKs give higher resolution and granularity to TCP. My postulation is that this is commonly false because of how the network access is designed and how also the NICs are designed (the transmit/receive offloading). So sending 35kPPS of ACKs for a gigabit/s transfer is just inefficient and shouldn't be done. I would prefer if end points would send less ACKs instead of the network killing them.
And the network does kill them, as we have seen. Because any novice network access technology designer can say "oh, having 16 sequential ACKs here in my buffer, sitting waiting to get sent, is just useless information. Let's kill the 15 first ones."
-- Mikael Abrahamsson email: swm...@swm.pp.se _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
