IETF Logo Mail Archive

Re: [tsvwg] Decomposing the question

"Holland, Jake" <jholland@akamai.com> Fri, 08 May 2020 20:39 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 27C4A3A0DD7 for <tsvwg@ietfa.amsl.com>; Fri, 8 May 2020 13:39:14 -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=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 Bd09aOE7f-ee for <tsvwg@ietfa.amsl.com>; Fri, 8 May 2020 13:39:12 -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 DED4A3A0CFB for <tsvwg@ietf.org>; Fri, 8 May 2020 13:39:11 -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 048KYLl2024603 for <tsvwg@ietf.org>; Fri, 8 May 2020 21:39:11 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=uraYe2NmNWUgq2oqgA1hLJYTUROJyfZa09jdJdtL3Ys=; b=RxBKFtLoldcKw3nLWH6lG18ln944VT11QHVt3nbs/KMH1NkJxLK0mW8yqYvlOOqbPKRm 0eZvDxsb+F65f+xPhiYnV/XP2+p+X+C0jsa8uVLsjWA6qOLpSCnDvTqu8vsa5cmKcjZC nWyldo5VRgj8kkpf69OzGpV2RCOVBfEB4oBmOBwxNRKklYt8/I9OqNkVsxq00rAjAhWk I6607YgsgNFhiJduSO3VseSPspJ77UfEbKzqTdOzvyO4vD7dBVI4cGs1g3dkdEbkmWzQ AxBk5J7XQqddSVBHbzgVUqoeoxa8ZQ/CZIJQhZ38CAt11yqSW6zh2i/otPilcrRZ9UEp Zg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 30vtcjvh6v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Fri, 08 May 2020 21:39:10 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 048KX4SB005176 for <tsvwg@ietf.org>; Fri, 8 May 2020 16:39:10 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 30s46x95k4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Fri, 08 May 2020 16:39:09 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 16:39:09 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 16:39:09 -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; Fri, 8 May 2020 16:39:09 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: TSVWG <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Decomposing the question
Thread-Index: AQHWI6XLp0/QLHS/wkeHHWxHqfCC+qied9qA
Date: Fri, 08 May 2020 20:39:09 +0000
Message-ID: <2647BEAE-9EC8-4CC8-8424-344E819EF00F@akamai.com>
References: <CAJU8_nX4nRwoztb_js=Pp2R0L_s2qCQ=2wdcThcHCSrM+aiBHQ@mail.gmail.com>
In-Reply-To: <CAJU8_nX4nRwoztb_js=Pp2R0L_s2qCQ=2wdcThcHCSrM+aiBHQ@mail.gmail.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.130]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D11FFAF6DF5B054B96C8D8F3EF481BF5@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.676 definitions=2020-05-08_18:2020-05-08, 2020-05-08 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-2005080174
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_18:2020-05-08, 2020-05-08 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 spamscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 priorityscore=1501 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005080174
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/zV-m7NNyHDwCWN6alEr-o-SbGq4>
Subject: Re: [tsvwg] Decomposing the question
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: Fri, 08 May 2020 20:39:15 -0000

+1 to most of Kyle's remarks.

I think the chairs made a noble attempt to crystallize the best question
to ask in "input or output", but in the end it now seems to me it's beside
the point, particularly because of the way it was framed as roughly a proxy
for "L4S: is it sufficiently safe, or no?".

However, I will disagree that the 2 options Kyle suggested are the only ways
forward (those being: update RFC3168 more strongly than 8311 or demonstrate
much better robustness for detection).  I believe there's at least one more
way, which I've tried to outline here:
https://mailarchive.ietf.org/arch/msg/tsvwg/vW8eEt7V58SWPoLIJ5dklCG4WqM/


I think Neal's recent suggestion to recommend bleaching is 4th possible
way forward:
https://mailarchive.ietf.org/arch/msg/tsvwg/kyDZ7vYLeOk1V15nZfNXGmaUNxk/

However, I'll give a strong +1 to all David's remarks on how unfortunate
that would be from his message here:
https://mailarchive.ietf.org/arch/msg/tsvwg/JVdZm1heomcZg5YXBQ9GAMVWKic/

I'd add that it also would work against the success of existing or under-way
deployments of RFC 3168 queues by imposing a new bleaching requirement that
may not be trivial for all networks with marking queues.

(Even so, I agree it’s a worthwhile mitigation that should be mentioned
in the L4S docs, if I'm in the rough and we land on choosing not to support
robust RFC 3168 compatibility.)

Best,
Jake

v2.23.0 | Report a Bug | By Email