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

[Mikael Abrahamsson <swmike@swm.pp.se>]

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: swmike@swm.pp.se