On 10/12/15, 8:57 PM, "aqm on behalf of Simon Barber" <[email protected] on behalf of [email protected]> wrote:
>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. You've got it right. Also, consider cases where there is other upstream traffic. AFAIK ACK thinning is only implemented along with ACK prioritization. One could imagine only doing prioritization, without thinning. In that case, if other upstream traffic were present, you may be able to get some of the latency reduction benefits by allowing the newly arrived ACKs to be sent as a burst in a grant that had been sized to carry some other packets, but then you are delaying the other traffic by (at least) one grant cycle. Thinning in combination with prioritization reduces ACK latency with less impact on other applications. _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
