[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