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

Wesley Eddy <> Wed, 17 June 2020 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C51D83A0ADB for <>; Wed, 17 Jun 2020 13:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hwWaGMsMlhR7 for <>; Wed, 17 Jun 2020 13:51:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 245E63A0AD5 for <>; Wed, 17 Jun 2020 13:51:58 -0700 (PDT)
Received: by with SMTP id i16so2720741qtr.7 for <>; Wed, 17 Jun 2020 13:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=AovFh0gk9Znjh5lIJVhSrwaNnylHaPEqbVbghN7IB0g=; b=BvD2LRwwUyzakdMTSmpRh6rzAHmpIFq/+gxvS+mITi4peZ3ODFRxuzvt9t26fi4F/i Uu+tzhhTOawKMEbBGZZJD14+0cbvnm7vx1WoM6VMlu8gapxyjG7cHieU4lsUuzufkztE LeC7rc4iQ/Q+FElRTx6Alg96zLUmp2VLyZg0tX8j45djPlu3YzIQkyn0oJNGuy5UqVLU 1vrUL+cxypR4IpqRnmu0O+T5KK7GVyvU8oiIDOxw6seCImCOIgGNYnV0Qg9xkiN35Bik 9tRLUHl+mEOikqR8H9gCyd72SARds2E6T03ZH3pE6NNMnDPWSaDGsYmGwBpEM5EFsg7i 0PQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AovFh0gk9Znjh5lIJVhSrwaNnylHaPEqbVbghN7IB0g=; b=TuwUsI3T6CqDe/leOkp4FHfbiZAnG8iC5pdNSFwcKZNyilDK41wGDJYlWdHuZaK8QL 8WImB5ogUNTRrPo+x7wFU2Cx09oPPcKe6hXuUZx2dndhFWBn/W7bVhynPevBmD1gOcmz +xf0ECVY5ysxVFQ1yuYESgCxuTZkhBi2z2ayiOQ0H/R9uvuC22O7jHZkkUOynO+il3Br f2U33ox9jampVkopK3A9C+2Pkbt/d6Es1xgJ213+DkQXRuNTOvPNaR3e7LVfqH8q/IFo wzybaNXQfnD4i5PHgitT8L8sywO7HBXAxqMgHYdaQO4Wt71oD3E4cKJlnuHPlZxDU1K/ rs1g==
X-Gm-Message-State: AOAM533Q/FIMXktmwY2yphN9b02EtuY2WyauAaatsLSy7tscUwWtdMeZ WoIf9NGfYsshrxKeitN9vOBiQaVCJ0/Ayw==
X-Google-Smtp-Source: ABdhPJyCTIbYONsJ1jXZRG8WABNy8sM4uZYLILPA94dzwcKZZX5dtZajaaPlRkgoaRTRW/LccIt5Vw==
X-Received: by 2002:ac8:518c:: with SMTP id c12mr1082506qtn.108.1592427116974; Wed, 17 Jun 2020 13:51:56 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id k22sm1105958qke.33.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jun 2020 13:51:56 -0700 (PDT)
To: Sebastian Moeller <>
References: <> <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Wed, 17 Jun 2020 16:51:53 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------63B94849D532A15B8AF7F8D1"
Content-Language: en-US
Archived-At: <>
Subject: Re: [tsvwg] path forward on L4S issue #16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jun 2020 20:52:00 -0000

(I'm at least for now ignoring the parts of this not related to this 
thread on issue #16.)

On 6/17/2020 3:25 PM, Sebastian Moeller wrote:
>> (and if more emerge, they can be dispositioned and added if needed).  This particular thread is about agreeing on a path forward on the one labelled "issue #16" in the tracker.  Suggestions and discussion about that are good and welcome; repeatedly accusing others of bad intentions is not.
> 	[SM] In the spirit of progress, how about team L4S either accepts rfc3168 compatibility to be a hard requirement and we start to discuss what kind of properties the L4S solution needs to achieve (degree of flow imbalance, temporal fidelity of the detection, false negative rates, ...) or team L4S lays out a plan how to assess the position Ingemar (and Bob in the past) seem to take that rfc3168 AQMs are sufficiently rare in the real world to allow ignoring them. I would expect that we then discuss how to measure this** and decide on what thresholds we consider for significance before hand.

This is already a requirement.  In the L4S I-D draft, there is a 

A.1.4 Fall back to Reno-friendly congestion control on classic ECN

    Description: A scalable congestion control needs to react to ECN
    marking from a non-L4S, but ECN-capable, bottleneck in a way that
    will coexist with a TCP Reno congestion control [RFC5681].

Again, the point of this thread is to figure out what the working group 
needs to do to achieve this.  Looking at it as a co-chair, I'm seeing 
basic agreement that the classic bottleneck detection algorithm will 
likely never be perfect.  I don't think there's agreement (or even very 
specific suggestions) about how good it needs to be.  There might be 
agreement that in any case, operators should not expect that all flows 
using ECT(1) will succeed in being nice to classic flows.  Along the 
lines of some of Paul Vixie's comments in earlier threads, protection 
from unfriendly or lying flows is important, and this should be true 
even without regard to whether an operator deploys L4S in their network, 
or if traffic is using ECT(1).  David has suggested to focus on 
operational guidelines that would help to avoid ECT(1) bleaching, and I 
think many agree that such bleaching would be undesirable.

So, it seems at the moment like we should be working on this in parallel 
to any improvements on classic bottleneck detection, because it will be 
important in any case.