IETF Logo Mail Archive

Re: [aqm] ACK Suppression

Christian Huitema <huitema@microsoft.com> Wed, 07 October 2015 21:12 UTC

Return-Path: <huitema@microsoft.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 0C28C1B30F5 for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 14:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 3iu3uaooWhUp for <aqm@ietfa.amsl.com>; Wed, 7 Oct 2015 14:12:48 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192B41B30E2 for <aqm@ietf.org>; Wed, 7 Oct 2015 14:12:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PFtaDWBCBkpS1DPqIpclHLDRzf0CKYjk7C2rnKayVz4=; b=baxlBfxsBnlemdTRrkxeM9BAckTnElJkuXGeQ37g8AB1yoXpZP/CCoUKZaYoJH196glJan7ydphwg0Ivstz7/jF5zuz+goQ4sesLZTRYw9GkSMT4PkRoR1vMmqBQ+SgeSfFOyQTz4RVV6dWbJVaXE3adeZ75dmfN7qHnzOdTq5U=
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) by CY1PR0301MB0649.namprd03.prod.outlook.com (10.160.158.143) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 7 Oct 2015 21:12:27 +0000
Received: from CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) by CY1PR0301MB0649.namprd03.prod.outlook.com ([10.160.158.143]) with mapi id 15.01.0280.017; Wed, 7 Oct 2015 21:12:27 +0000
From: Christian Huitema <huitema@microsoft.com>
To: "dpreed@reed.com" <dpreed@reed.com>, "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: [aqm] ACK Suppression
Thread-Index: AQHRATmy+5PKaFfCu0CCULEBxH9hN55geCaAgAALpACAAADJQA==
Date: Wed, 07 Oct 2015 21:12:27 +0000
Message-ID: <CY1PR0301MB0649DB7A6DDE1840CCB0B485A8360@CY1PR0301MB0649.namprd03.prod.outlook.com>
References: <mailman.1487.1444233956.7953.aqm@ietf.org> <1444247538.3556484@apps.rackspace.com> <alpine.DEB.2.02.1510072200590.8750@uplift.swm.pp.se> <1444251596.768725492@apps.rackspace.com>
In-Reply-To: <1444251596.768725492@apps.rackspace.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com;
x-originating-ip: [131.107.174.39]
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0649; 5:bQoR9+8N8ivbXmJONklYA/NoSek9MS4NEzmWPjf6Dc25GyXx8peu9M1BuoSwigbmACLpdTYOeSc++JZoAHnF64PJEcN5OhhiZP8V3j9gkfBcfmMKEacTMGuq6HUmkMT04Jg7cwERWzCWKYowZxeZow==; 24:rfYiFBdPLpM133f7AlQh18CpXWttO/89V6s0XcRGt94HEIxtN2TlLXb/VGFbTpIn3u+tAFjNEsdjA1+dl705lWMcPUf9/H3jKE+0qCgFhEA=; 20:RHbAFYLaUxn9YdFdvOKhPtSFDucPkXER9w0o7IvUXaZo8Joy44jWdw8SEmGPYwIaPO5HMUTfjO72GE7bUJkioQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0649;
x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-microsoft-antispam-prvs: <CY1PR0301MB06495925304C7FA900FA3793A8360@CY1PR0301MB0649.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(61426024)(61427024); SRVR:CY1PR0301MB0649; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0649;
x-forefront-prvs: 0722981D2A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(24454002)(189002)(5007970100001)(86362001)(93886004)(5001960100002)(2950100001)(5005710100001)(19580405001)(74316001)(122556002)(106116001)(19580395003)(97736004)(10090500001)(87936001)(99286002)(40100003)(106356001)(105586002)(5002640100001)(92566002)(5008740100001)(5003600100002)(46102003)(2501003)(5004730100002)(102836002)(33656002)(50986999)(66066001)(101416001)(11100500001)(5001920100001)(77096005)(54356999)(2900100001)(8990500004)(107886002)(10400500002)(81156007)(76576001)(86612001)(76176999)(64706001)(189998001)(10290500002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0649; H:CY1PR0301MB0649.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2015 21:12:27.5437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0649
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/5lJhoE0xH2x_940GUEa_sQ5OgU8>
Subject: Re: [aqm] 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: Wed, 07 Oct 2015 21:12:50 -0000

On Wednesday, October 7, 2015 2:00 PM, dpreed@reed.com wrote:

> That's the real engineering challenge.  Modularity is your friend when engineering 
> large systems with very broad requirements.  Focusing on a very narrow issue, especially 
> one that assumes way too much about what should be allowed and what traffic "must" 
> look like, misses the point.

This ACK thinning "optimization" obviously does not work with encrypted transports like QUIC. The network may see that some packets are short and some are long, but it cannot tell whether the short
Packets are ACK or some other management data. Quite often, they will be both. 

According to our friends at Google, a fairly large part of the traffic from and to the Chrome browser now uses QUIC. If the uplink in DOCSIS networks is so limited that it would not work without ACK thinning, that would be a problem for QUIC -- and very much an illustration of Dave's "real engineering challenge." I wonder whether QUIC telemetry shows specific issues caused by congestions of the DOCSIS uplinks.

-- Christian Huitema


 

v2.23.0 | Report a Bug | By Email