Re: [tsvwg] plan for L4S issue #29

Pete Heist <pete@heistp.net> Fri, 31 July 2020 18:53 UTC

Return-Path: <pete@heistp.net>
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 5C4E23A02BE for <tsvwg@ietfa.amsl.com>; Fri, 31 Jul 2020 11:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=heistp.net
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 Zf6oBQR2U8x5 for <tsvwg@ietfa.amsl.com>; Fri, 31 Jul 2020 11:53:00 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 26B513A0143 for <tsvwg@ietf.org>; Fri, 31 Jul 2020 11:52:59 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id 3so10116849wmi.1 for <tsvwg@ietf.org>; Fri, 31 Jul 2020 11:52:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UuOpLfMoOISS6R22sC9ylm+8LD4BBOsv7OeyuVFFSUs=; b=V2o0EAilfHlioQll+v5J9pNz8mH54yYDQXD25pcpXzSQuiyFRJm6wQdpfNFK9zMmKW vLoSSNP9f6q8HiAlrhWAAfzE4lMocb0RjSUR9OcPeOrxeqfGMZHsW/kz0F12SQ4ja/Ja B2RqTJz5rv9E2Smp81F9fs9oDT2BRd2TXWdDtDp/HAlSx8sSXOp6EiHwft9tiJeCxtWT RqsQGys9Zxea+aNBKaeXumKMhXBCKB6ms7NZDfR1yKJV6L77trnUiEGmCscl8hJsKCHj IA0XHvy/mnRoDjnf0urceyXWjvlS2vWBuGmw8xGSuYKkvMLRuE28TsU+DDdA9D0vQRgJ HZGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UuOpLfMoOISS6R22sC9ylm+8LD4BBOsv7OeyuVFFSUs=; b=PRYPOtCvRMty2oydVIO7Rr6W58fHX3/JTlyMsVa/Us13FTMCCXaFLqdkf+GFyJzurl J271m1yDMpt3ziaB1Pn9eav+nCfN13gqPgwEliEiiOkBOo/JG1Aa2vP3givoXuXJabkq 7Y+akMaUEKL1Hvi4trPBamN27YqoKabLSXq1aIfKrzTTdKftenOTv4PqfvZgNTZEPrbv gzEwijLaN8MFUqVvlBKyzb66ZLP6FMU/GDSPwMNk0NoiDbCONAk0qI7YxStuLicZi897 HDDoji1RYiKu1eNf0PkorJB2VKHLhjQg7rnZ1asN86AMmCmr3KdUWSPwewoONxPGTTCI 0sTA==
X-Gm-Message-State: AOAM530k9a9rfFstb4V+tPS+P8ys5Rk8F9adUDkl+UO1DcLiIZfVhOJa 1wwP9BEsgm8cs7XK+YPwfidJf1eRlzKeog==
X-Google-Smtp-Source: ABdhPJwOUkT2OKbcrBIh1QYSLi2ojjIGZUbLS1/+y3yNXqa7FR0cwTj4I5AYQh7dnS+fe9Or/xqJ+A==
X-Received: by 2002:a1c:18e:: with SMTP id 136mr4849321wmb.93.1596221578475; Fri, 31 Jul 2020 11:52:58 -0700 (PDT)
Received: from yoda.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id h13sm14478266wrx.17.2020.07.31.11.52.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 11:52:58 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
From: Pete Heist <pete@heistp.net>
In-Reply-To: <ca8ede0e-53a2-f4ff-751d-f1065cf5e795@mti-systems.com>
Date: Fri, 31 Jul 2020 20:52:56 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0D3EDCE-3633-4E37-A167-3F1E09148ED9@heistp.net>
References: <ca8ede0e-53a2-f4ff-751d-f1065cf5e795@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.3445.9.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/A6scjGx47L5CKHytmYR_dlDDbjo>
Subject: Re: [tsvwg] plan for L4S issue #29
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, 31 Jul 2020 18:53:02 -0000

Hi Wesley,

One thing I noticed during testing was that the current implementation of TCP Prague in Linux allows disabling bottleneck detection through the prague_ecn_fallback kernel module parameter (https://github.com/L4STeam/linux/blob/0e7cf8acb318873c3f61084453f8da15b2e398be/net/ipv4/tcp_prague.c, line 158). I don’t know if that was left in only for testing.

In section 6.3.3 of l4s-arch, there is discussion around classic bottleneck detection. Since I don’t see an explicit MUST that it remain enabled (although I do see the text “an L4S sender will have to fall back to…”), it’s not completely clear to me if it’s actually required to be implemented and permanently enabled in all implementations. If it is, I suppose the implementation should reflect that also.

While I feel it best that detection identifies both types of queues accurately, if bottleneck detection were both an explicit MUST in the text *and* not possible to disable in any implementation, I think that would make the misidentification of L4S queues as classic ECN queues less of a safety concern, since it would be impossible to turn off. It would remain an issue for the architecture overall though.

Hope that helps...

Pete

> On Jul 31, 2020, at 5:41 PM, Wesley Eddy <wes@mti-systems.com> wrote:
> 
> Hello, ticket #29 for the L4S documents is about classic bottleneck detection misidentifying L4S queues as classic ECN queues.
> 
> https://trac.ietf.org/trac/tsvwg/ticket/29
> 
> In contrast to other issues, it doesn't seem like this should block a WGLC on the L4S drafts.
> 
> 	• It is specific to classic bottleneck detection algorithm, which is planned to be worked on in the Prague ICCRG draft.
> 	• The result is sometimes failing to achieve the best possible L4S behavior, but doesn't seem to be an Internet safety issue.  This resulting in people turning off classic bottleneck detection would be a different issue, and something maybe the operator guidelines would address.
> 	• It seems like it can be worked on further in the course of L4S experimentation, without negative effects to others.
> So, I believe we should track this work in the ICCRG, and close the ticket here.  Please let me know in the next week if I've misunderstood any aspect of this and it should remain open.
> 
>