Re: [tsvwg] L4S vs SCE

Sebastian Moeller <moeller0@gmx.de> Fri, 22 November 2019 07:14 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 BE74412009C for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 23:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 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_DNSWL_NONE=-0.0001, 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 d0tKPg7NLLNu for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 23:14:55 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 5009712008A for <tsvwg@ietf.org>; Thu, 21 Nov 2019 23:14:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574406888; bh=jlg3E2TtL03L1dR97aod4ZA1NtRUo2ncuHE5y74UuSg=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=JmW3ODrQYrQqni3MTFzvB7/ysBH+Z21v9dE5+X5mdDGxef2Tj2SZQgS8Rm9nCajrl wlS8eG2LVOiSCMQSJu790c3vfFB6PC/pwsr6c2VRTl4YoI/PM7TTxYgCm0psZmedA7 qNtb6FTdUnYOvLDo4YEo92ux9rPgAIXmv/xauNQg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.200.135.195] ([80.187.111.85]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MDQeK-1ifEgI1oIA-00AWCa; Fri, 22 Nov 2019 08:14:48 +0100
Date: Fri, 22 Nov 2019 08:14:47 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <2BF22591-F0F6-4793-AE4E-9B8719347338@cablelabs.com>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <12ED7632-5E3E-4EB9-B65E-8A8324067C9A@akamai.com> <5DD4BB25.3060700@erg.abdn.ac.uk> <5658232C-07D5-4C89-B16A-58A928332FC6@gmx.de> <HE1PR07MB4425D989D4A266C73331FFA5C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <CAJU8_nUK5cZLFE-0UBzf0a7T0hC7C+CpCsUy_+ZU_p4oxW9BmQ@mail.gmail.com> <HE1PR07MB442560D0715BC921AB9B7FE3C24F0@HE1PR07MB4425.eurprd07.prod.outlook.com> <AM4PR07MB345968E8C665304DFBD5B11FB94F0@AM4PR07MB3459.eurprd07.prod.outlook.com> <228d061d-f25e-b350-4a6e-2aea827a590c@kit.edu> <e5a7ed0e-90cb-10a9-c55f-0ba8d2144ecd@bobbriscoe.net> <2AFFF85C-E66F-4CF4-AA62-6F7249A16959@heistp.net> <357abfd2-2d93-b4cf-355a-71a2def32b15@gmx.at> <E175102C-CD01-40B3-9807-3DE0C2DB8277@heistp.net> <9d6c1ce4-d192-d016-8418-c26a09e25517@gmx.at> <716AA405-6C3D-4AF5-9C7A-FEEC8A988CF4@cablelabs.com> <3AAE96EC-54C1-4768-AA2A-879973F96B79@heistp.net> <2BF22591-F0F6-4793-AE4E-9B8719347338@cablelabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: tsvwg@ietf.org, Greg White <g.white@CableLabs.com>, Pete Heist <pete@heistp.net>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Sebastian Moeller <moeller0@gmx.de>
Message-ID: <24DDEC3A-2498-4284-B7B3-0B899279D1B2@gmx.de>
X-Provags-ID: V03:K1:HRP4Nyp5EEfe5im7EVm7ryL1GOrJ5XcqtdfTRRf4e7WUD9wnHre 8h4Jh/abhOkLK3OI8gJtHtEuxi28G3cpVpk87Hl7QxD9Wx68Tw8K6CY/od20XM5K3rJIaz0 mHF7sV8oukF08d/3qoH6WV26YJ0t0ueb5HzBF2kX/ZP2lWXgK2KYKtrjPSnks/6c++mLuGk mg7FFwLCcy+E5IZECn1cQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:aZytjS6zOpA=:3taAgcMLgkouqm9FIBKMoP GgDETrZ4OskN4pfHdEmPihjbJA4b6g+Eo942CHUaKuQw6TX07rHYTDWbJNqUx4zoNoTg66/Pm EhELnAU5METja9JLn9wmqNcRshoKXDy7D0bnKiHIdeuMsqEDCvuv1M0vV9mHhdlhoX2AQWAT/ zzPJgeAdSY099zyz31CL8OvVHKcH9TikdCFTlSn21OeECnLAsFbmT0qHJJHDQpSBR3a+eOabY nL4mV1drKEySvMMAXiWnR9YBM/wOQPz3zYvRtSAxfowewfUFjbQTTvOm7dglOL6pWMxyEfKC5 Y44pYZTelk7tJ/RvXTCvbcnutOjS+otGWjsfpCnDGlyKg0uvxMrTTbdInUQGjndWTQO1jGrsn /0fYv3Eq1acdu2hKqbBo6JQNtiyHSZT/K2ZOz7L9VYKNTo2yBOpQR/U8voswUhLEvfPEzZURA 9T0L2Ysa5Cx/zIiYeInpy6+gGWV7bfwzJH6Tfdk87fXqM6MoA3FIMIq/FZLzXJQvyNJ6MBxyc LWQaQetlp3DYa98X6CcXzglrsiakIvL/Jx/5ebbM1wS4aJuXsa5NYJKSO2LS8kQiljhn2UWaS nAAnGIV+bxj9lwn9+ZVnXlPzctjHBPS2afWRsym2pg/BqHDzQk8B5U/bvhZgcaIXiFhf/BpAo 7NK/p+D2E+BVx3OpleUImV/graYYcA+6FIb10WeqxWef2M9U/HEJFCtX8fUFRaddChHlzooqo mDWcj5HHWZwddZshGF5pOWUnjMEHBXvs/oNAEjVNjLGN997psS8duuwyuSkmQWoKbKvLTcuA6 4R8nNT2vXnt/89XRhmCXTmJ632AiEOleIiUchZIQUyQRiixMQFbG/MKQTUzNntvgPqCrltUWM HHVMkGEPD3aPtkF08p8Mqsd+JljJqq/Z6UmFVkgV7ldxTJBmtsFpUqwiA/xHd1I+3BZSI51wM teesneeMIpdIETR40s93yLSRduizSZafL1HTI7NcqZpXCF346x77ROfRJJKLkUCg/D2TAKgQl XRnaIF2ZIgG4JfpnR6oA6w58iBehXxUuzvpy+khNMLpQi//r0rrUp/jqc7N+gaOQX/vsmXX11 NCuAXAq9mglnR9ETWXeCINdQ1Vg3+PEdf6pf2i9ObXHiSEhLOoS7D4uWXn6n7DBRrYnTsKEdL 8s6PCwj5zTy2SLZClAFzMScanab5LgIfxCXlSlgMKCnXtX6bJoLeX+d37dXYTBJ73S5uYBpc5 tSM3HlJ8Hxk2WCP9cXP/8c8I7Ji5pnUQ/oR0+u4iuuW4kAgGTjpQ+pAKoc7Y=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JTAYkRBp-DhtZ86jGNwSva4FWe4>
Subject: Re: [tsvwg] L4S vs SCE
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, 22 Nov 2019 07:14:58 -0000

Dear Greg,


On November 22, 2019 5:02:05 AM GMT+01:00, Greg White <g.white@CableLabs.com> wrote:
>Pete,
>
>I've seen several statements being made to the effect that SCE can
>possibly work in a single queue or dual queue bottleneck, but I've not
>seen any data to suggest that it is true.
>
>If the SCE team can come up with such an approach, and provide test
>results (preferably to a similar extent to those provided by the L4S
>team, not just the simple flent scenarios), it would be interesting to
>see.

[SM] I do note that the simple flent scenarios, as you call them, revealed and illustrated instantaneously at least three issues with the dual queue coupled AQM and TCP Prague. IMHO this calls into question the extent of the L4S teams testing, at the very least it indicates that testing should be performed with the actual implementation one wants to standardize. Also as far as I can none of the dctcp tests over the DualQ aqm have so far been really testing realistic corner cases.
So I applaud and support the call for diligent testing, but I very include the L4S implementations into that call.


Best Regards
        Sebastian

>
>-Greg
>
>
>On 11/21/19, 8:58 PM, "Pete Heist" <pete@heistp.net> wrote:
>
>    
>> On Nov 21, 2019, at 7:14 AM, Greg White <g.white@CableLabs.com>
>wrote:
>    > 
>> Where I think SCE fails is that it is not available to any link that
>doesn't implement FQ, whether that is by choice or by necessity.  I
>don't believe that the IETF should use the last IP codepoint for a
>signaling mechanism that can *only* work in FQ.
>    
>The thoughts are appreciated. What I think needs to be clarified is
>that SCE doesn’t necessarily require full FQ using the traditional many
>queues approach. It only requires some level of help from the network,
>when fairness between SCE and non-SCE flows is required. Options
>include:
>    
>- Changing the SCE marking ramp, trading off some of the advantages of
>SCE for improved fairness. This was first described at IETF 105 in
>Montreal.
>- Using CNQ, which is implemented but we didn’t have time to present
>today. That provides a minimal level of improved fairness that can
>actually favor SCE flows early in their lifetime.
>- Using LFQ, which like CNQ, is in draft form with a crude discrete
>time simulation, but doesn’t yet have an implementation. This provides
>closer to full FQ but with a lighter weight implementation.
>    
>This is still an active area of research with many options available to
>us, and we feel it’s a tractable problem. We just want to make clear
>that “SCE requires FQ” isn’t very accurate, and needs more
>clarification as to the current and future options available.
>    
>    

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.