Re: [tsvwg] Neal Cardwell's rationale for supporting ECT(1) as an input/L4S signal

"Holland, Jake" <jholland@akamai.com> Thu, 28 May 2020 17:19 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 44C9B3A00C3; Thu, 28 May 2020 10:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 n4d9eGQtNqON; Thu, 28 May 2020 10:19:41 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 4F3B33A0899; Thu, 28 May 2020 10:12:23 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04SH3DkX006278; Thu, 28 May 2020 18:11:39 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=O60nwoGxE+0CFaXoyKRb+nQcLFfx4zjtU2fZ8AkPrks=; b=S+pOSXRDEjbWGigi7/gDVSeSpCCfzAuqWI7ZLX4ORf44CDU5KwHg9N5JrJhS7lL44K2V YEEsSwEbKDie6Bo0gy9XFWgmYPkv/jMHgB/k5vA1cgVgF1/2pALvZB3f7sTs8P0/BqdH 9Dg0j6yoQyAXHDcjIETjmDiJBlaaQ6QLE62Zc7aNaQ+jlPfo81bv0vrWhorih1zEIHcc 29TeTTiJEbjL5loJJdE3CDMZFcdQrJpy4ONn1XZ256LTCzNuyac5NWCQJX5BmTyOT5iV 4hBGKf/rnt8S9k+4Squ/Zj7dx738mZrkCd+mjv09RsZnlIZv9Ba0/RA3xDIkFXRpvZ5m fQ==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 316u3h9adw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 May 2020 18:11:39 +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 04SH2aje032665; Thu, 28 May 2020 10:11:37 -0700
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint5.akamai.com with ESMTP id 3171t8v6bd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 May 2020 10:11:37 -0700
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 28 May 2020 13:11:37 -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, 28 May 2020 13:11:36 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>
CC: tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>
Thread-Topic: [tsvwg] Neal Cardwell's rationale for supporting ECT(1) as an input/L4S signal
Thread-Index: AQHWJUxIcCajnIV5gk+TOCWCdAWIaqiei86AgAar9QCAF7n4gIAA7lwA///JGwA=
Date: Thu, 28 May 2020 17:11:36 +0000
Message-ID: <23A53E5E-AE0F-420E-B70D-68DFF8510D6F@akamai.com>
References: <CADVnQy=7f79Mj_GQBU-UsodTRORjB2U6rCPPQ+1Zck_gxr-rww@mail.gmail.com> <A4B43F47-9050-403D-B739-BF12C8F873EB@akamai.com> <CADVnQy=zbFSaJxosicyAjz0sbBRnq_N82LV=SeiCZqCx3BYqwA@mail.gmail.com> <9F3CC7ED-3C9C-4D44-913E-7E8D682A0DF0@akamai.com> <CADVnQymNfE0HXa0M2eGNBTWyU+Zr6f-MLHyD5mpmmRPpsZ9g9g@mail.gmail.com>
In-Reply-To: <CADVnQymNfE0HXa0M2eGNBTWyU+Zr6f-MLHyD5mpmmRPpsZ9g9g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.84.98]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FCE1B5DCC2EE64F898213E8F875B72C@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-28_03:2020-05-28, 2020-05-28 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-2004280000 definitions=main-2005280118
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-05-28_03:2020-05-28, 2020-05-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 lowpriorityscore=0 cotscore=-2147483648 phishscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 suspectscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005280118
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FWkcTSIjJ3Wv6iINZpB8G9k_OeQ>
Subject: Re: [tsvwg] Neal Cardwell's rationale for supporting ECT(1) as an input/L4S signal
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, 28 May 2020 17:19:42 -0000

Hi Neal,

On 5/28/20, 6:28 AM, "Neal Cardwell" <ncardwell=40google.com@dmarc.ietf.org> wrote:
> I'm thinking of a 3rd approach not listed above:
>
> (3) There is no RFC3168 ECN traffic, because the site does not use
> RFC3168 ECN. All TCP/UDP traffic would be allowed to share a queue:
> non-ECN public Internet traffic, L4S public Internet traffic, and
> low-threshold-ECN internal datacenter traffic. During conditions of
> congestion, the switches would mark using shallow-threshold ECN marks,
> and thus the non-ECN public Internet traffic would receive a higher
> share of bandwidth than L4S or internal traffic in that queue, but
> this is deemed acceptable, since public Internet traffic is already
> deemed to be highest-priority. In this approach, the L4S traffic is
> added into the mix using existing queues in existing datacenter switch
> hardware, without introducing new devices, new queues, or dualq.

After a bit of searching, this makes sense to me now.

It looks like this approach can work with multifield classifiers, or
maybe even without if using Juniper's version of WRED which to my
surprise seems to say it doesn't drop NECT at WRED thresholds when the
queue has ECN enabled (and if you don't mind adding delay to the L4S
flows), so TIL:
https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-qfx-series-tail-drop-understanding.html#jd0e290

Cisco and the tc-based ones I'm pretty sure do the thing I think
RFC 3168 describes and drop NECT packets that would have been marked.

Which is why I was at first confused by your explanation, since it
seems like that would wreck the NECT internet traffic in your setup
if you didn't split up the queues.  But now I think I see how it
could work with the right config, and this usage hadn't occurred
to me.

So I very much appreciate the clarification, thanks.

Best regards,
Jake