Mikael, Specialized upstream TCP ACK handling (which can include both prioritization and suppression) is a recommended feature in the DOCSIS specification. The details of the implementation are left to the manufacturer, but I don't expect that it is actually done at dequeue (packet processing at dequeue is expensive in cable modems). Rather, I expect that devices identify ACKs at enqueue, and retain (separate from the main service-flow queue) a single ACK for each TCP session. Then, upon receiving a grant, the ACK queue is flushed first, followed by packets from the main queue.
The CM is not permitted to issue bandwidth requests for more data than it has available to send, so bandwidth requests would need to already have ACK suppression taken into account. For this reason (and the above), I doubt that the CM would include suppressed ACKs in its queue depth and queuing latency estimation. AQM in DOCSIS also happens at enqueue. The spec is silent on whether the upstream TCP ACKs are subject to AQM packet drop, but it would be compliant for them (i.e. the one ACK per session) to be protected. -Greg On 10/6/15, 1:20 AM, "aqm on behalf of Mikael Abrahamsson" <[email protected] on behalf of [email protected]> wrote: > >Hi, > >after noticing that some TCP ACKs on my home DOCSIS connection were not >making it to their destination, I after some interaction with cable >Internet people, I found this: > >http://www.cedmagazine.com/article/2006/12/docsis-sub-throughput-optimizat >ion > >"TCP ACK Suppression (TAS)" > >"TCP ACK Suppression overcomes the TRGC limitation without actually >affecting the DOCSIS specification or involving the CMTS. It improves >downstream TCP transmissions by taking advantage of TRGC and only sending >the last ACK it receives when its data grant becomes active. Thus, the >number of TCP ACKs is fewer, but the number of bytes acknowledged by each >TCP ACK is increased." > >So the DOCSIS modem basically looks at all the ACKs in the queue at the >time of transmission (DOCSIS uses a "grant" system to tell a modem when >it's allowed to transmit on the shared medium), and then basically >deletes >all the redundant ACKs (the ones who are just increasing linearly without >indicating packet drop) and keeps the highest ACK only. > >Now, this kind of mechanism, how should it be treated when it comes to >AQM? This mechanism is basically done at de-queue, when a number of >packets are emptied from the queue at one time, which is then allowed to >fill up again until the next transmit opportunity arises. > >Or is this a non-problem because it's likely that any AQM employed here >would use the buffer fill right after a transmit opportunity has finished >(for those that consider buffer fill as a variable), which would mean >that >most likely the TCP ACK purging had already occured so this mechanism >doesn't influence the AQM in any significant manner anyway? > >Just as a data point from my home connection, I have 250/50 (down/up) and >when downloading at 250 megabit/s, the upstream traffic is reduced by >approximately 20x, so instead of sending 10 megabit/s (or so) of ACKs, I >see approximately 500 kilobits/s of ACKs. > >-- >Mikael Abrahamsson email: [email protected] > >_______________________________________________ >aqm mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
