Re: [tsvwg] plan for L4S issue #29

Sebastian Moeller <moeller0@gmx.de> Wed, 30 September 2020 11:21 UTC

Return-Path: <moeller0@gmx.de>
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 C00AC3A0BFA; Wed, 30 Sep 2020 04:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 O1aiDRt-O9f5; Wed, 30 Sep 2020 04:21:25 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 EDBB33A0B97; Wed, 30 Sep 2020 04:21:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1601464881; bh=LeBMy88YTE/5TmSgBNKJHgYicjBFgsRZzw0FwY1EwTc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=k3bNsWGsdmfyD1RlYa/R7C1xxr6WwINQESVsKhqXPR3Q1NGzec+GNeGOzusoi5oxs Q7r/rXfSvWtS6G0dJTkpkRNiHFSa0zGgvcxpEP4lZVSUcoAg0nj4cuRnR2npWH3xyc YLWn5xSXebKL9Z+ChoMAL8tmkJf44dWmiTX3rsJ0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MMGRK-1k5Mpj2n6U-00JJH3; Wed, 30 Sep 2020 13:21:21 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <alpine.DEB.2.20.2009301256260.20021@uplift.swm.pp.se>
Date: Wed, 30 Sep 2020 13:21:20 +0200
Cc: Ruediger.Geib@telekom.de, ingemar.s.johansson=40ericsson.com@dmarc.ietf.org, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <966A30EB-3494-4EB4-89C6-502BFA964D8A@gmx.de>
References: <HE1PR0701MB2876EE4CE6B71EEFA88A912AC2330@HE1PR0701MB2876.eurprd07.prod.outlook.com> <LEJPR01MB1116D7DFFADC28995CB6965F9C330@LEJPR01MB1116.DEUPRD01.PROD.OUTLOOK.DE> <alpine.DEB.2.20.2009301256260.20021@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:yE0F73DvYIQvZrnmGmG5cnNWl2VgRzxN8GWxEElIOCuQbPfB3YA cxTeTqfcYSaspu5iRnDjhNfv8YF57ivx1Na+hD74paHERWX0jTlY4XXtaEw+4V268cjihVr xgjIQ0Bzs6DRCT9HchL//ug8T1RlgZJ/Pbw36hHJ11Bz+CLp71+YF+C9xO0jXxQvMbsHDyf vg83sNvBW8abz2anhaNCw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:+glnBopwxAg=:8np1SB0YtyY+rmnWdV6z4G CZ8qDlS7TO8Qq6k5vAgF7vc9caba/3g/3Gk2bStIqpvjbdeEwxw96SXtMIvtxdy28w2X3+evc CvAd40fN+sMCa21XVrTEd+CJpp9VlaSskVl1/EhggmEeldqGg9OpCWYPoXuyPcIKb4BkBoPWS 0Ta+Lkg47XGJ+jhaELVwkaiVUVM0SdtJvtHGa1bVJcyrUBMGC4OkmTh5UwpvgC72+PKqgwkBN rouMFVyz+MhsLX+k10pEZanAgyKrj+5wHpSaH95o/Ab87wwvGWG5E6iRbcqIUm294ANE/smY9 1xmzaYYKWFtE+TZ+u9R/DNf0clxLhKq58yVkhmcMApZd+JhQwNIqHqt94pv42fdORkzSHlCJj +J/0hMKomB/ouGycvYL07evP7CAjU8LIGMtThY/LxbqhnzVTMFgXVjwxxCRCOzQhStmrGo4wG uXX2+3pwDcFFMIm3E6LINZWalaJeIj9SqaiqNgbpvzmVnH5s9RDQ6smXDREiVvnFIa92zM6yn LqPCA6tiQHhER3vjx0vj6dmkZyPrXPtgl1WQlSFrWZxprCVBhH+u2KiajXauslv35SqHpM1jM JLec/3ETBefAvgTtSZwPqKmCreN7AdowVoNv+rGMOLPLUGyFfxP+4ZiQuIxoV9tnkQ32a20H4 xbFF4v6l3aYbwe1k9LXSK14h4qwqVA6NHn4/RmKbCACyIF8VmwXP59DpQ9kCPfybL2RT3DTTr K8hUucROcOjBy3a821VQZJrr86rFNK0gWWFfM7MmrqafyIzNbK74ud0I35JOcYK52i518A7zJ qH/7mzpmR72HlEfIrobfesnYos+1egiUU5PEEg+GLBljns8XDjey/Bn02hRPYmHujjneq0dnl 6aCZkWmQN5g6bNviZ53EeCtiYGNpC3OqYWY9zmCL7dTVh/EE+LLY2hnvsJ8Fahtl2YqI2mw5q 02uPeU58vv1azTNGa52c6M6teamMscjpcKCSaDUR66MJXMx+sbk0xIRnj2IrlxhX4vF9qO1RI p6y9pdxVUnh6ihkQbkTCkVl6nYohpmPbSD7zfvj8/up+F5H4aBk05xkkvXUUjhqw72gz+iLCF VrWMLG9BYk/LCdsSyQdhefn2+ARQ8msjb0jxSKX9A/dNml6NjxHDXxtIAQPadOfRVoYrX4HAH RIbsyLw0rfcXA9pU1KM+SnP9HfVG8j0kEbf3BQfXVT5nTT45OALnYm5jEbD14rAqXwOq4BvAK ns8P8iFOxYN7hvazA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/VXy6Cxnnq8b7_Np_C_Yj2pWHSGg>
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: Wed, 30 Sep 2020 11:21:27 -0000

Hi Mikael,

these are good points, that could be actionable for team L4S, see below.


> On Sep 30, 2020, at 13:06, Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org> wrote:
> 
> On Wed, 30 Sep 2020, Ruediger.Geib@telekom.de wrote:
> 
>> players may be useful too (e.g., I don't know whether an access router
>> vendor offers an L4S implementation, and availability of applications or
>> content expected to benefit from L4S transport certainly would be very
>> helpful).
> 
> I participated in FQ_CODEL / CAKE evaluation which was easy to do because it was developed using a fork of OpenWrt which had readily available platforms/code/compilation environment etc and it was easy to get started because it was already packaged. There was also tools like Flent to evaluate performance in different combinations. All development was done on github etc and it was easy to follow.
> 
> When searching for L4S patches I find https://github.com/L4STeam/linux
> 
> I don't see much activity in the past 5 months, is this really where development is being done?

	[SM] If the repeated claim that team L4S invites everybody to help improve L4S it would be a great idea to offer a set of globally diverse distributed L4S-enabled endpoints, that sit behind well described L4S-AQM bottlenecks and that allow say something like long duration speedtests with timestamps, so that everybody can use the same set of testing endpoints to finally get to the answer of the question to what degree the current L4S design is actually going to work over the existing internet. If applying measurement endpoints is too big an ask, at least team L4S should consider to supply ready configured container/VM images for endpoint and AQM roles to expedite testing.
	Which accidentally does not require any progress for the L4S drafts, and could be tackled today. As it stands, everybody wanting to kick the tires of L4S is basically forced to establish both endpoints and the AQM themselves, which does put considerable hurdles into the path of non-full time AQM researchers. 

Best Regards
	Sebastian

> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
>