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