Re: [aqm] TCP ACK Suppression
Greg White <g.white@CableLabs.com> Tue, 06 October 2015 16:35 UTC
Return-Path: <g.white@CableLabs.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532AA1ACE12 for <aqm@ietfa.amsl.com>; Tue, 6 Oct 2015 09:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.226
X-Spam-Level:
X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xll7hwVeUTc for <aqm@ietfa.amsl.com>; Tue, 6 Oct 2015 09:35:38 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id EA3461ACE52 for <aqm@ietf.org>; Tue, 6 Oct 2015 09:35:27 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t96GZPq0005170; Tue, 6 Oct 2015 10:35:26 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 06 Oct 2015 10:35:25 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 6 Oct 2015 10:35:24 -0600
From: Greg White <g.white@CableLabs.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>, "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: [aqm] TCP ACK Suppression
Thread-Index: AQHRAAfaJ/73TrlDIUOGwELhN8Uffp5eqfGA
Date: Tue, 06 Oct 2015 16:35:22 +0000
Message-ID: <D2394BB6.548C5%g.white@cablelabs.com>
References: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1510060748480.8750@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-originating-ip: [10.5.0.27]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DF84133968A4D64A8373506274D75B7A@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/Q0xMe1qRnUi8VM_qKLtSnJDtck8>
Subject: Re: [aqm] TCP ACK Suppression
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2015 16:35:39 -0000
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" <aqm-bounces@ietf.org on behalf of swmike@swm.pp.se> 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: swmike@swm.pp.se > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm
- [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression LAUTENSCHLAEGER, Wolfram (Wolfram)
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] TCP ACK Suppression Clark Gaylord
- Re: [aqm] TCP ACK Suppression Steve Bauer
- Re: [aqm] TCP ACK Suppression Francini, Andrea (Andrea)
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression Bless, Roland (TM)
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Richard Scheffenegger
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Greg White
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression Rick Jones
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Christian Huitema
- Re: [aqm] TCP ACK Suppression David Collier-Brown
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Yuchung Cheng
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] TCP ACK Suppression Simon Barber
- Re: [aqm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Dave Taht
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression Simon Barber
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Jonathan Morton
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Mikael Abrahamsson
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression Greg White
- Re: [aqm] [tcpm] TCP ACK Suppression Joe Touch
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang
- Re: [aqm] [tcpm] TCP ACK Suppression David Lang