Re: [tsvwg] L4S vs SCE

Pete Heist <pete@heistp.net> Fri, 22 November 2019 04:54 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 DAA79120889 for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 20:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 a88G44DNhkWt for <tsvwg@ietfa.amsl.com>; Thu, 21 Nov 2019 20:54:37 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 1A465120894 for <tsvwg@ietf.org>; Thu, 21 Nov 2019 20:54:36 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id k13so2775455pgh.3 for <tsvwg@ietf.org>; Thu, 21 Nov 2019 20:54:36 -0800 (PST)
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=RIHiLXqJXQQEoEtCd6KK0AiBidFTlcIqS/HxA9T5E2A=; b=kmAicItiEwD5i3+pBa+Rgm+gHSHSQIPGdqBXly+Ck8+iObxpGaoowKL8wURI8A0Rns AcB0d5ul3/K3oQ/yjwIj9Ng8uHad3hp237U8+zCjWlOwkUyhtI31VfbY2GwMYRH+Tgzd JgfJFn/K+AlgY46i+d4PDwD5ogPLDKti3U8qOWAlxCdhnKJE3KtUOdWXUwe/Yw4VYis1 OS/OA1+1IukMh2xZH29+xckVMVdL8VC4H7NGVpHxwOHf9Tt0Xeqp4NFKpoOWX2a2iMjk O6yWFOJHI3yIoEYcYV0Zry0BzuOS9enlOr1wuWGY2ZtT/Wle1LXyrP9eqpgJI1O/J7v3 IvhQ==
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=RIHiLXqJXQQEoEtCd6KK0AiBidFTlcIqS/HxA9T5E2A=; b=oGPZWlNK+ck11LC7ufFMjnjsJBF3jT2gANHPgR+7y8NkMfd9uHM6q+GHlbOQRf1jkc Q2hd3njw5crRuoIU4RifmRhwvkkfcYFOtGyWHzIWfgreEtRb6utJvyvv3Ild+NeKlVgg gvju2qwNYZfiKgysEW6UBhfqOyinvNL4CfYOO3a2qmDDaDJZOX1lu1x/9bBH6cDVAhQl WEUuAMhahOqeRCD2XnJ7Sn992nSW0vZKwN7zm4P/04EVj10JxYkDTvcTHKk318kClNQf rMFflivGd3vMFCGqdueMizu6+RU5qOygmHZnygOXxQOtHUDbTIy+7XV5T8e+KYMdjmXC u3Iw==
X-Gm-Message-State: APjAAAWOie75gSpY0RHJLR7Yf1hiFTNnoEDOBUZQzS5/catjLR4nGNZY 2KqvTfX4B+eHPmCjW5p+98znAQ==
X-Google-Smtp-Source: APXvYqw9Mx19AelueF4mNKCEc5R4o4hqQZimm6ELCvXghpaVyYUU31eS4shezidpDfdMpEYs41iRCA==
X-Received: by 2002:a65:64c1:: with SMTP id t1mr6973165pgv.263.1574398475459; Thu, 21 Nov 2019 20:54:35 -0800 (PST)
Received: from dhcp-92b3.meeting.ietf.org (dhcp-92b3.meeting.ietf.org. [31.133.146.179]) by smtp.gmail.com with ESMTPSA id r24sm5037499pgu.36.2019.11.21.20.54.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 20:54:34 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist <pete@heistp.net>
In-Reply-To: <2BF22591-F0F6-4793-AE4E-9B8719347338@cablelabs.com>
Date: Fri, 22 Nov 2019 12:54:32 +0800
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <162AF980-57EB-4459-95D1-3ED1A951DB7A@heistp.net>
References: <HE1PR07MB44250F3C4E6A744DDCC3DAFCC24C0@HE1PR07MB4425.eurprd07.prod.outlook.com> <ad7b763e-b3dd-36cf-a9c5-7de99476babb@mti-systems.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>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HD_C-J8UZdHkSEnm7FxgvYW0V6M>
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 04:54:43 -0000

Yes, we look forward to providing more results later, in the form of flent tests. If there's is anything more detailed that needs testing, we’ll enhance flent as a first option.

The CNQ implementation is only a week or so old, and LFQ is not implemented yet. The crude discrete time simulations for both are referenced in the respective drafts.

A clarification for my earlier statement regarding CNQ is below.

> On Nov 22, 2019, at 12:02 PM, 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.
> 
> -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.

It should more accurately say:

"That provides a minimal level of improved fairness that prevents SCE flows from being starved to minimum cwnd.  It also priorities sparse flows including initial handshakes & request-response transactions.”

Experimentally, we have seen SCE flows outcompete non-SCE flows early in their lifetime with CNQ, but that isn’t directly due to help from CNQ, but to the new marking strategy using Codel, which was prototyped in CNQ.  We’ll port this development to Cake in due course.

>    - 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.