Re: [aqm] [tcpm] TCP ACK Suppression

Greg White <g.white@CableLabs.com> Mon, 12 October 2015 23:08 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 7D75E1B2B84; Mon, 12 Oct 2015 16:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.227
X-Spam-Level:
X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 QVTlHugHjc0o; Mon, 12 Oct 2015 16:08:50 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2C48A1B2B7C; Mon, 12 Oct 2015 16:08:50 -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 t9CN8jAp013300; Mon, 12 Oct 2015 17:08:45 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 12 Oct 2015 17:08:45 -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; Mon, 12 Oct 2015 17:08:42 -0600
From: Greg White <g.white@CableLabs.com>
To: Jonathan Morton <chromatix99@gmail.com>, David Lang <david@lang.hm>
Thread-Topic: [aqm] [tcpm] TCP ACK Suppression
Thread-Index: AQHRAuFHTV+VD6RCtU2qgvWw5c3NuZ5kIzsAgAACOACAAA69gIAACDeAgAAF9oCAAAS3AIAAGpuAgAAiyYCAABu/AIAABycAgAEGRICAAAclgIAACxeAgABNnoCAABiMAIABDYgAgAACy4CAABafgIAADKqAgAEmiIA=
Date: Mon, 12 Oct 2015 23:08:41 +0000
Message-ID: <D2419657.54F70%g.white@cablelabs.com>
References: <5618005A.8070303@isi.edu> <70335.1444421059@lawyers.icir.org> <D23D8CA5.54DF5%g.white@cablelabs.com> <56183B49.4000506@isi.edu> <alpine.DEB.2.02.1510091511540.3717@nftneq.ynat.uz> <56183E93.1010308@isi.edu> <alpine.DEB.2.02.1510091528320.3717@nftneq.ynat.uz> <5618420E.9040609@isi.edu> <alpine.DEB.2.02.1510091628010.3717@nftneq.ynat.uz> <5618554F.3080103@isi.edu> <alpine.DEB.2.02.1510091716100.3717@nftneq.ynat.uz> <56185E44.9050702@isi.edu> <alpine.DEB.2.02.1510091910170.3717@nftneq.ynat.uz> <561891C3.90004@isi.edu> <alpine.DEB.2.02.1510092134190.15683@nftneq.ynat.uz> <5618AF0A.4010101@isi.edu> <alpine.DEB.2.02.1510101439090.1856@nftneq.ynat.uz> <alpine.DEB.2.02.1510101525170.1856@nftneq.ynat.uz> <F62FF3E5-EC9E-4534-B005-2A987C63C41D@gmail.com> <alpine.DEB.2.02.1510102042280.1856@nftneq.ynat.uz> <5619F00A.2040009@isi.edu> <alpine.DEB.2.02.1510111358310.2053@nftneq.ynat.uz> <561AD47B.9030602@isi.edu> <alpine.DEB.2.02.1510111526050.10958@nftneq.ynat.uz> <CAJq5cE1KM-wxTB8nB_AbXcniLbCbHn6M=4bM0uaLRY2s=YNUjQ@mail.gmail.com>
In-Reply-To: <CAJq5cE1KM-wxTB8nB_AbXcniLbCbHn6M=4bM0uaLRY2s=YNUjQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.6.150930
x-originating-ip: [10.4.11.26]
Content-Type: multipart/alternative; boundary="_000_D241965754F70gwhitecablelabscom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/dI0Mz8QFZRiZCelHVEN9rHvC6sY>
Cc: "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <wolfram.lautenschlaeger@alcatel-lucent.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>, "aqm@ietf.org" <aqm@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [aqm] [tcpm] 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: Mon, 12 Oct 2015 23:08:51 -0000

> 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.