[tsvwg] CE-marking observations
"Holland, Jake" <jholland@akamai.com> Thu, 30 April 2020 17:01 UTC
Return-Path: <jholland@akamai.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4761B3A0CA7 for <tsvwg@ietfa.amsl.com>; Thu, 30 Apr 2020 10:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 ZfbTtGQHLvPL for <tsvwg@ietfa.amsl.com>; Thu, 30 Apr 2020 10:01:56 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0253A0CA6 for <tsvwg@ietf.org>; Thu, 30 Apr 2020 10:01:56 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 03UGwvK0009931 for <tsvwg@ietf.org>; Thu, 30 Apr 2020 18:01:55 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+ZoP9fey1C6MEFKloaHO/d2RvLbeM/xZcnvnNgddVXM=; b=V+TzndOC2cIb+V7VBBFd5+Zw90mqPcvtPMXt2jrR1i3CoyWrMOK9j4Bqb1FxP1JjsAKY vKnIECQS6vSx3qdX0YzNWt4RY6n8pwqU9A9pcdq1D/GeTJQ9seq43scvMJGUElyBpHjT 1ysdklZyp0TkysiSKdj2LtDMR1ZgkUWHJMP2exVub9E33OFUcGyPgdzcEr0MQ9xsq/v6 T8pYZDD1nZUx2AkBkYb4ukxoMMTOlQJmIsIAzm5pyXaLf2ZkaNBiOmt5tvZ/iF2iroFy XZiYTbXLyqZtpaDUmLAEdjS3te4jx5vYjf1Ne30byMcW8ikS4ryAgCA5eO1G5JCYXWwd hQ==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 30mdm9xyqt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Thu, 30 Apr 2020 18:01:55 +0100
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 03UGlGHR015149 for <tsvwg@ietf.org>; Thu, 30 Apr 2020 10:01:54 -0700
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 30mk68x5qn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Thu, 30 Apr 2020 10:01:54 -0700
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Apr 2020 13:01:53 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1497.006; Thu, 30 Apr 2020 13:01:52 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: CE-marking observations
Thread-Index: AQHWHxEH81/ON5xSv02nPnNug9VlzA==
Date: Thu, 30 Apr 2020 17:01:45 +0000
Message-ID: <17A553AD-C4E3-4504-95CD-315C95991917@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.89.201]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D5BC8E6760D16246AF74BD623A9EE7DD@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-30_11:2020-04-30, 2020-04-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004300133
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-30_11:2020-04-30, 2020-04-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 mlxlogscore=999 impostorscore=0 malwarescore=0 mlxscore=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004300134
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2tbRHphJ8K_CE6is9n7iQy-VAZM>
Subject: [tsvwg] CE-marking observations
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2020 17:02:01 -0000
Hi everyone, I have a few numbers to report about some CE-marking queue deployment observations over the last few months. I've urged that we not break normal ECN, and I'll repeat that urging here. To me this looks like the early stages of rollout of a technology that's finally getting a little bit of traction, and breaking it over the next couple of years seems like a mistake, and worth avoiding if possible. (I still think regular AQM deployed in the right places solves most of the problem, and that ECN helps plenty at the application level for TCP, so starting a rollout of something incompatible right when it finally starts happening would be harmful to the goal of improving latency, regardless of the potential benefits.) This is all based on observations from production traffic to end users, since we've turned on ECN support by default since mid-February. There were 3 regional consumer ISPs with strong evidence of ubiquitous marking queue deployment (above 65% of their IPs). One of these 3 may have deployed something within the last month, as we saw no such evidence from late February, but it was clearly present in late March (it also could have been higher congestion that wasn't ever hit in Feb, since there was substantially more traffic as well). There were 7 such ISPs that had marking queues on at least about 15% of their IPs. Those numbers seemed to me probably ISP-deployed, and could plausibly be either shared queue devices or a managed deployment of CPEs with something like the cake/codel implementations. I have no visibility at this point into which they used, only that there were notably more CE-marking IPs within the AS than what's expected from individuals buying home gateways with ECN support. There were 70 or so ASs with observed marking capability prevalence above 5% across their client IPs, and 30 or so ASs with observed marking capability over 10%, but many of these were quite small. I again have no visibility into whether they were shared queues or no, and at the lower end it's much harder to make a good guess at whether it's a managed deployment or individual actions that happen to have some coherence. There might be a mix, especially across the lower end of the 70, of AS-owned vs. not. Globally I saw a lower bound on client IPs that exhibit marking at about 0.1%. The vast majority seemed isolated individuals most likely using one of the various available home router installs for their gateway, so to me the more interesting part was the early edge of ISPs that seem to be doing something that might end up scaling. All these are lower bounds, in that I can only tell it's marking if we saw CE or ECE, and in some cases we plausibly never had congestion during the observation periods I used. Also, it of course only has a chance to get marked when the clients have it enabled, which happens at quite a small rate in some areas. These numbers also have a chance at being falsely low for the general case because it was filtered to nearby connections with enough connections to usefully examine their latency variation. But it's at least something of a lower bound. HTH. -Jake
- [tsvwg] CE-marking observations Holland, Jake
- Re: [tsvwg] CE-marking observations Dave Taht
- Re: [tsvwg] CE-marking observations Dave Taht