Re: [aqm] [tcpm] ACK Suppression

[Mikael Abrahamsson <[e-mail]>]

On Thu, 8 Oct 2015, David Lang wrote:

> Ok, so it turns out that what we are talking about here is talked about 
> explicitly in section 5.2.1 of RFC3449. It warns of increased sender 
> burst sizes, but I really question if that's a valid concern in the 
> cases that we are talking about here. The choice in these cases isn't to 
> send more acks spaced out, but rather to send a lot of acks back to back 
> in one transmit slot vs one stretch ack per transmit slot.

Exactly. And in my specific case, we're talking 20kPPS of data down, and 
10kPPS of ACKs, over a medium that allows the modem to send a bunch of 
packets only once every few milliseconds.

So there are two alternatives:

You get approx 10-60 ACKs as a "train of ACKs" within 0.3 milliseconds, 
every 1-4 milliseconds.

You get 1-3 ACKs within 0.1ms, every 2-3 milliseconds. These ACKs will 
acknowledge 16-32 packets at a time.

By the nature of the beast, I'd say that this kind of medium implicitly 
will be able to handle the "bursts" we're talking about here, if you ACK 
24-48kilobyte of data per ACK (when a middle box does ACK Suppression to 
remove intermediate ACKs), it's implicit that the medium designers know 
that they can handle a wirespeed burst of data that is the result of the 
ACKing of these fairly large number of bytes.

But again, I question the wisdom in ACKing every 2 packets when the 
congestion window is in the hundreds of kilobytes and you're sending tens 
of thousands of packets per second.

I suggested in another part of the thread that perhaps the host itself 
should do ACK suppression and don't send ACKs more closely together than 
once per millisecond or 1/10th RTT, whatever is lower. Perhaps the RTT 
value needs to be even lower, 1/25 of RTT or something.

In my specific test, using once per millisecond or 1/25 of RTT would cut 
down the number of ACKs to around 2kpps instead of the 10kpps ACKs I see 
now, but it wouldn't cut it down to the around 500-1000 ACKs per second 
that the DOCSIS modem is cutting it down to...

I think that as bandwidths go up, there are changes to TCP that can be 
done to make it work better, and reducing the frequency of ACKs sent 
depending on RTT and different window sizes might be a way forward. I 
fully believe there are cases where ACKing every 2 packets is exactly the 
right way to go, but when you're sending 1 gigabit/s over 100ms RTT and 
the medium itself clumps the packets together because that's what it does, 
then these ACKs don't carry the same information anymore and some of them 
could be optimized away (preferrably by the host stack) to spare upstream 
bandwidth and transmit opportunities.

-- 
Mikael Abrahamsson    email: [e-mail]