Re: [tsvwg] David Black (individual) on safety of L4S for the Internet
Neal Cardwell <ncardwell@google.com> Fri, 08 May 2020 22:04 UTC
Return-Path: <ncardwell@google.com>
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 ECCB03A0FA4 for <tsvwg@ietfa.amsl.com>; Fri, 8 May 2020 15:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 MG9iS44I0oiW for <tsvwg@ietfa.amsl.com>; Fri, 8 May 2020 15:04:34 -0700 (PDT)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 6FCE63A0F41 for <tsvwg@ietf.org>; Fri, 8 May 2020 15:04:34 -0700 (PDT)
Received: by mail-ua1-x931.google.com with SMTP id a16so1244355uaq.5 for <tsvwg@ietf.org>; Fri, 08 May 2020 15:04:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wm7Tcmxn2ZFBPmRdU0dnE/weHud61J6GvxzoKolzOko=; b=eF80WT2q/HorIr5yetVWXpY0qxPmmhhjUCh7za/T1gm9n2P0N89XOHCJUOk7Z4JGYH +496Ekfz8a2JDOU8KOp111Ua9nIXW1EK11tyFf+RjZiDxJGvN8pCcLB+GXSHT2y7UHZX 6EFpWCfRfnjRLZ2b0cE1UgM/sqamXiaHC18T3h6HA9uaUwEm3mH3jSdqs6oNe+hhieDB O8hqb26V07davlmRbZSvNST5EFFYXkUumgwiqxUe9M4f0HwIsz0RNMpdwTyON6qa4I0Q LT3qoyDnD5No4yzGM5nF7uT8LkNAJeZOaIu11KlZZ8GitM0pDjMPPQPqbO8n3OSRDZIz z+Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wm7Tcmxn2ZFBPmRdU0dnE/weHud61J6GvxzoKolzOko=; b=ImVUFWDeEL+86o30FVcVEU79JazTOhzVq97a/z6+3sVNFzwZIqLal0txRNaVUV29Fk ncV4I/sBrFWHFVIQUw23fjWGc3IAumvvLPbTGCuXb5puc21BOG6RfJ0ZaTgSqeBLkv2m tusxZi0/h8tqViP2zuKkSglChA0Qo0dITmKaAcyHDzZACt1K+Ec5hNNBTbhhPXuC10j6 f/V0Lyi7h9xqeD60zR2gMVAfjZqglA99DHHqkHJ2AxMCdKHCu8zBrP0PUGTrcXC5wnQY f+v7PNaRzOvzG7aHFm+U73M8nsebIk7JYnrAXGrfbr5t4u//sAnJrGumPjjkZda/a9UG sPHQ==
X-Gm-Message-State: AGi0PuazwMiE1etiabpjv7rJ4388OtQKRA8Lua//53RuYm0FTUBgdwkP aqqjjgOd9Hx0LutbHo4RsSwQ8GINMYxrSuRkRc1GSw==
X-Google-Smtp-Source: APiQypJPLUck+8fwGwYjjqf+zdVX4VWWwPjHSvs2QkQQzxPNH9191HCmjIvaSe/y2cFw7dNhqc/pweO4KmqDteh7jm8=
X-Received: by 2002:ab0:25:: with SMTP id 34mr4097072uai.63.1588975472710; Fri, 08 May 2020 15:04:32 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR19MB4045DBC270D70DECE5F2B4AC83A20@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB4045DBC270D70DECE5F2B4AC83A20@MN2PR19MB4045.namprd19.prod.outlook.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Fri, 08 May 2020 18:04:15 -0400
Message-ID: <CADVnQymXFe7o4M_GgwqxDP0x5UsAKE+1oQcavyDTF04gP-S34Q@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/b5Bsoonuum8aQjdnVoOnYqRIZPA>
Subject: Re: [tsvwg] David Black (individual) on safety of L4S for the Internet
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, 08 May 2020 22:04:39 -0000
On Fri, May 8, 2020 at 4:01 PM Black, David <David.Black@dell.com> wrote: > Current practice is not to mix DCTCP-like traffic (1/p-class congestion > control) with TCP-like traffic (1/sqrt(p)-class congestion control, e.g., > NewReno) in the same queue because the DCTCP-like traffic outcompetes the > TCP-like traffic to the point of starvation of the latter. For my education, does someone have a pointer to the experiments underlying that description of DCTCP outcompeting Reno/CUBIC? I'm not aware of that being a fundamental property of DCTCP. The DCTCP algorithm specifies a Reno-style response to loss - https://tools.ietf.org/html/rfc8257#section-3.5 - and has Reno-style increase functions as well. So the algorithm should be Reno friendly, AFAIK. The description of DCTCP outcompeting Reno reminds me of the behavior of the Linux DCTCP implementation, before this 2019 bug fix by Koen De Schepper and Olivier Tilmans: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=aecfde23108b8e637d9f5c5e523b24fb97035dc3 tcp: Ensure DCTCP reacts to losses AFAIK, Linux DCTCP with this fix no longer outcompetes Reno. > In contrast to reliance on TCP Prague, that combination of FQ and bleaching > looks like it could provide a robust safety case. AFAICT bleaching ECT(1) to Not-ECT should be sufficient for safety, without also requiring FQ. An L4S flow that has ECT(1) bleached to Not-ECT should then be treated Like Reno by the bottleneck in question. And, like DCTCP, the L4S specs specify a Reno-compatible loss response for TCP Prague: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-09#appendix-A.1.3 So at least to a first approximation it seems like if an L4S flow is bleached by an ISP to Not-ECT, is then treated by the ISP's bottlenecks like non-ECN Reno, and then (per the L4S spec) behaves like non-ECN Reno, L4S should be safe. Apologies for the noise if I have missed something. best regards, neal
- [tsvwg] David Black (individual) on safety of L4S… Black, David
- Re: [tsvwg] David Black (individual) on safety of… Jonathan Morton
- Re: [tsvwg] David Black (individual) on safety of… Neal Cardwell
- Re: [tsvwg] David Black (individual) on safety of… Jonathan Morton
- Re: [tsvwg] David Black (individual) on safety of… Yuchung Cheng
- Re: [tsvwg] David Black (individual) on safety of… Jonathan Morton
- Re: [tsvwg] David Black (individual) on safety of… Black, David
- Re: [tsvwg] David Black (individual) on safety of… Neal Cardwell
- Re: [tsvwg] David Black (individual) on safety of… Jonathan Morton
- Re: [tsvwg] David Black (individual) on safety of… Neal Cardwell
- Re: [tsvwg] David Black (individual) on safety of… Sebastian Moeller
- Re: [tsvwg] David Black (individual) on safety of… Luca Muscariello
- Re: [tsvwg] David Black (individual) on safety of… Scheffenegger, Richard
- Re: [tsvwg] David Black (individual) on safety of… Jonathan Morton
- Re: [tsvwg] David Black (individual) on safety of… alex.burr@ealdwulf.org.uk
- Re: [tsvwg] David Black (individual) on safety of… Bob Briscoe
- Re: [tsvwg] David Black (individual) on safety of… Black, David
- Re: [tsvwg] David Black (individual) on safety of… Gorry Fairhurst
- Re: [tsvwg] David Black (individual) on safety of… Sebastian Moeller
- Re: [tsvwg] David Black (individual) on safety of… Gorry Fairhurst
- Re: [tsvwg] David Black (individual) on safety of… Sebastian Moeller
- Re: [tsvwg] David Black (individual) on safety of… Bob Briscoe
- Re: [tsvwg] David Black (individual) on safety of… Sebastian Moeller