Re: [tsvwg] path forward on L4S issue #16

"Holland, Jake" <jholland@akamai.com> Mon, 22 June 2020 19:17 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 5C8E23A10D6 for <tsvwg@ietfa.amsl.com>; Mon, 22 Jun 2020 12:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 bMpNWv-iYN7a for <tsvwg@ietfa.amsl.com>; Mon, 22 Jun 2020 12:17:02 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 F19AE3A10CF for <tsvwg@ietf.org>; Mon, 22 Jun 2020 12:17:01 -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 05MIsN3H027079; Mon, 22 Jun 2020 20:16:00 +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=uZTH0TpSHPljOLtSbY7sih7rjlGz98lNWdBnQdfLixc=; b=hVovX3+FChaHObAB6VkpyQvHn84V2LN+XXzQCQmBitc5jWOSQxTNdPBujUttZ4DXvNMK BRTQnZofgYmGzZV/pQge4KuSS5fLKkWVPKA/qlc732lKoPpnqwSILFRY2Xi7U7jXFVSB XeleujaA9wvApNNPL4yy7yQa5rAOMwPxNlqWDzfIcRxyO7Q9fX4WLQPF4CDsS9LC3fRo yfKsQhAao2YHt5UZnS8iQwr6kY2jdWSRwty15EYJ14gyb1Tn1ZuVQdTxbUccPkymgjNb AIHLu1oxCFRiulfcn1jeAkBYj3Tjyg4+EIf3dNY6AtDdo9F+yc0LgH+rMhLr6uNTbDhF Kw==
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 31svj0rqp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jun 2020 20:16:00 +0100
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05MIV64u009305; Mon, 22 Jun 2020 12:16:00 -0700
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 31sgeb826t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 Jun 2020 12:15:59 -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; Mon, 22 Jun 2020 15:15:59 -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; Mon, 22 Jun 2020 15:15:59 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: Wesley Eddy <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] path forward on L4S issue #16
Thread-Index: AQHWOrJPoJRqhhQ5LEq1EH58/gPNgKjgndWAgASGaoD//8cugA==
Date: Mon, 22 Jun 2020 19:15:58 +0000
Message-ID: <74E1F25C-8659-4445-A7D3-17431951A0AB@akamai.com>
References: <8a8947e1-f852-c489-c85a-be874039f132@mti-systems.com> <CCF60E29-276F-45AA-8045-D14DFE44CDBE@akamai.com> <fb4c3dcf-9487-7199-0b14-a21a3d83db0a@mti-systems.com>
In-Reply-To: <fb4c3dcf-9487-7199-0b14-a21a3d83db0a@mti-systems.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.88.217]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E120E7F0043BFD458582A0943FE30DFD@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-06-22_10:2020-06-22, 2020-06-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006220123
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-22_11:2020-06-22, 2020-06-22 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 priorityscore=1501 impostorscore=0 cotscore=-2147483648 malwarescore=0 clxscore=1011 spamscore=0 mlxscore=0 phishscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006220126
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/fHWhHwTOSjYaFqlyXceVV-Du6hE>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Mon, 22 Jun 2020 19:17:03 -0000

Hi Wes,

Thanks for your comments, I mostly agree with your remarks.

However, there was one point I thought needed a response:

´╗┐On 6/22/20, 8:39 AM, "Wesley Eddy" <wes@mti-systems.com> wrote:
>> 5. operational considerations to recommend policing strategies that can
>>     solve the general case of non-compliant traffic that does not respond
>>     with the expected backoff to AQM congestion signaling.
>> a. Arguably this should be done regardless of L4S, because it seems like
>>     an underdeveloped piece of the puzzle for the general problem of active
>>     queue management in network devices.  However, solving this well and
>>     getting solutions widely deployed or at least available (or somehow
>>     deployed in conjunction with L4S endpoint enablement) could also
>>     potentially address issue 16.
>
> I personally agree with this.  I think it's not specific to L4S at all 
> though.  How bad flows are dealt with in general will also be applicable 
> to a buggy or malicious L4S flow.  So I personally think the gate for 
> L4S work in this regard should simply be WG confidence that the 
> situation is not made substantially worse by L4S flows (whether they are 
> legitimate or not).

I don't think it's right to conflate legitimate and illegitimate flows
here.

There's a difference in kind (and in the reasonable set of responses)
between 1. a one-off buggy or cheating sender, vs. 2. a DDOS attack, vs.
3. a growing population of legitimate endpoints that are by design
incompatible with existing network devices.

There are a number of countermeasures[*] that are completely reasonable
for illegitimate traffic (#'s 1 and 2), but that are much less reasonable
if trouble is caused by a growing population of legitimate endpoints.

So while I agree that this issue is not specific to L4S at all, to me
the reasoning is the other way around:
    Although L4S now seems unsafe to roll out at scale because of its
incompatibility with classic queues, there could be a good set of
solutions to "overburdened AQM response" that could change matters
once deployed.  So digging in this direction might be able to unblock
L4S, in addition to improving AQM operations in general. (But on a
long timeline.)

Or to put my take on it another way:
    L4S flows *would* make the situation substantially worse if they
started rolling out now.  But it might be possible in the future to make
it so they *would not* make things worse, with good solutions to this
other problem.

Best regards,
Jake


[*] to be more specific:
For #1 (a one-off buggy or cheating sender), the easiest and most
common initial response for an operator is "ignore it, it'll go away".
I've certainly run my share of 1-off flow experiments on the internet,
and most of the time nobody notices or cares (and once in a while you
get spanked a bit).

But when you legitimize and start scaling those, it becomes hard or
impossible to distinguish #2 from #3, and it *would* be a problem to
apply some of the common #2 countermeasures to legitimate traffic
(like triggering routing black holes or suchlike).

If it comes up for the L4S case, absent a better solution, this is
exactly how the best response available to an operator ends up
landing on approach #4 (bleach ECT(1) to NECT).

But although I'm not a big fan of bleaching, I would much prefer a
consensus decision that it's the best answer to a consensus decision
that no answer is necessary (leaving bleaching as the undocumented,
yet only sane option available to operators when trouble happens,
and hoping it's the one they choose).