On Mon, 12 Oct 2015, Greg White wrote:
My contention is that since this is already happening, consolidating the ACK
packets into stretched ACKs doesn't make this any worse, and it saves network
bandwidth (and decreases latency to the extent that data is acked faster than
waiting for the entire chain or original ACKs to get through, especially if
that would take multiple transmit windows). As a result, thinning the ACKs is
kinder to the network.
I agree, *iff* they are not DupACKs signalling packet loss. Do existing and
future cable modems take that subtle distinction into account?
I presume that they are not discarding DupACKs or corrupting SACK in some way
(the whole point of specialized ACK handling is to ensure good TCP performance
after all), but since the algorithms are proprietary, for existing cable
modems I don't know. I will contact the developers as well as run some tests
on a few modems to get a better idea (and maybe Mikael already has some data
from his recent testing he could share?). For future modems, I can add an
explicit reference to RFC3449 in the DOCSIS 3.1 spec just in case implementers
aren't aware for some reason.
It should also say that AQM is needed on the downstream side to protect against
transmit bursts.
The suggestion was posted early in this thread (but not in someting I can
quickly find) that to harden the connection against the aggregate ACK being
lost, it should be sent again in a separate transmit window.
I latched onto that and think the right thing to do is to duplicate the
aggregate ACK that's created and put it at the beginning of the queue that
remains after the current transmit window.
If there are more ACKs in the next transmit window, it will get aggregated into
them and not cause any additional traffic.
If there are not any more ACKs in the next transmit window, and the first ACK
was lost, it will replace it with the minimum of delay
If there are not any more ACKs in the next transmit window, and the first ACK
was not lost, we are now transmitting a duplicate ACK, which may be interpreted
as a signal to speed up tranmission (depending on the exact timing of the
arrivials of these two ACKs). While this is not good, we already need to be
protected from transmit bursts, so this is just another possible cause for such
bursts.
David Lang
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
