[tsvwg] path forward on L4S issue #16

Wesley Eddy <wes@mti-systems.com> Thu, 04 June 2020 20:54 UTC

Return-Path: <wes@mti-systems.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 A3A3B3A0F58 for <tsvwg@ietfa.amsl.com>; Thu, 4 Jun 2020 13:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=mti-systems-com.20150623.gappssmtp.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 HM9j4boNjFvD for <tsvwg@ietfa.amsl.com>; Thu, 4 Jun 2020 13:54:00 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5006F3A0FB6 for <tsvwg@ietf.org>; Thu, 4 Jun 2020 13:53:55 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id w90so6527505qtd.8 for <tsvwg@ietf.org>; Thu, 04 Jun 2020 13:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=W7yvt0wWmpMMGwugcNmk2DcXaYGgvOUV34JiuFQ7s68=; b=Y4lXNyBuRtZwqBemuB9Azh0N9PejCPT4W0eaIT983nfc44gNANWITgbUZhijOvd8WU Vw5CsnGLG5D87FxIALs/jTazVxqH05OtxvephH/uwnQiKSk7lXj2sMNjlq7lt18cicc4 DF2sQB6HLQrlXCanZk2oanUKHob/IRuCMox3UYYtDws7c/HeD8xm1fJSZGgCfLyIKFOp YSWPORQo3wU3OuBghk9mzC9Xifg/uUiCNyUApW0ErDyy1j0HgJgXTxcpQX1/ShcEQKRt 8b2uoJOmjXW2yuLuwZgpsH818pKUszUaCmSVg/27/CsUWTGEWv6cA3pUsNth8PL+aYK4 es/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=W7yvt0wWmpMMGwugcNmk2DcXaYGgvOUV34JiuFQ7s68=; b=UaDP2vrsNvMF91+3Euv2d3c1y2NZDXdDquKZ5zxmdD9R2Ja6zPQwN5RUgxrvMshFGs 8wrobuPGRavB8AnSsQ291duqKlIlRKVcviJC5n9pcWyj/kId33MZnhV8GGGE/XNZFwCk EsWoXPoE3EHHh++D2IHg3pwTYoF+OUn+tH/0KhnmkUI1f09Df8PmWs3Cx6onKs79Ts5P 2zq98+4WXlWPKtB0h7GC+cYSz/y1eOn4OYaZ+oIHVuGVkS/e+PHPQnDeg9Xxjzwbvtgh cSrmDipJ2H627LXSQwaWCL0T1D+YWJ6JSG1ArwWMzhOTlapGRrgg/s9l3U7nZ3kGgpPn pU+w==
X-Gm-Message-State: AOAM5302ePXbYfo3EQqREEAVbzxzvC096iUtFcxzo00BcWqcfwYd+HNg l6n6lawK4oBKL3w4RZZfengDFAUy+XZYSg==
X-Google-Smtp-Source: ABdhPJw1kGoqwmxUcPPMo2idIw8+aK881+3HCpfvPHYXKm9BTUWNn6gSOpiDdVZbC9liEeaJENwSuA==
X-Received: by 2002:aed:3fb4:: with SMTP id s49mr6813366qth.16.1591304034015; Thu, 04 Jun 2020 13:53:54 -0700 (PDT)
Received: from [192.168.1.12] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id m7sm5558704qti.6.2020.06.04.13.53.53 for <tsvwg@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 13:53:53 -0700 (PDT)
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Wesley Eddy <wes@mti-systems.com>
Message-ID: <8a8947e1-f852-c489-c85a-be874039f132@mti-systems.com>
Date: Thu, 4 Jun 2020 16:53:50 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Ot6196Qg42Pr6ZHIwrabMThFVNM>
Subject: [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: Thu, 04 Jun 2020 20:54:02 -0000

I think we should discuss the path forward on L4S issue #16 and what 
people are working on, planning to do, or expecting to see in this regard.

This is the issue on interaction with RFC 3168 ECN AQMs in the network.

I think this is one of the more important ones in many recent 
discussions, so would like to make sure we're agreeing on what it will 
take to complete or what success will look like.

The classic bottleneck detection work is a key part of this.  In that 
vein, I'd like to subsume issue #29 (that it looks like Pete Heist 
opened) under this one and close #29.  Issue #29 shows some cases where 
an L4S queue is misidentified as a classic one.  I think fixing this is 
part of making the classic queue detection and end-host performance 
robust in as many cases as possible when trying to take advantage of L4S 
in the network, but doesn't lead to a safety issue.

Are there any plans or thoughts on how to proceed on issue #16 that 
people can share?