The issue here is that the hosts don't know how the medium is going to
do the clumping, so thinning the ACKs at the host may add additional delay.
From what I understand from Greg's earlier message the cable modem must
request uplink bandwidth in advance, so if it had to send multiple ACKs,
it would send the first one, then request bandwidth the the additional
ones that had arrived since the first one (please correct me if I'm
wrong) - in this case collapsing/thinning the ACKs will reduce latency
by one grant cycle.
WiFi is quite different - there is no need to request bandwidth in
advance, so there is less pressure to collapse the ACKs - just send them
all and they will be burst out when the medium becomes available.
Simon
On 10/8/2015 11:43 PM, Mikael Abrahamsson wrote:
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.
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm