Re: [pim] Q on the congestion awareness of routing protocols

Jonathan Morton <chromatix99@gmail.com> Tue, 06 December 2022 09:12 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43EAC157B44; Tue, 6 Dec 2022 01:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQuZi2MQtbD2; Tue, 6 Dec 2022 01:12:22 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C8DC14CE45; Tue, 6 Dec 2022 01:12:17 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id b9so16497535ljr.5; Tue, 06 Dec 2022 01:12:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=r3iPstuNFz9WMCxiJ31uvg/6uYePN2X/R9c182XXUzQ=; b=FI8BL8yf7DWFHrHvSmfDTMHczP/LP2l3f2uX74FAfYvCZnKOXNj81wxnFVvIZBK9Hp J0IaQciLZNPEoJ7pZTvcwBlxDT0hrggQeAdjTi9APqb+kKHsUnTbYiQbth5DBCt3DXU+ To5ReK5SJMBHtfZefaCKSarjy0mWQufWPngZNhYcuew7T1CB0aFfmg2KvBOY3uiVFqCm AuxlM2zhnnB18YYVdrEjCdGkY48CAhaayUReOKFMUtXHxqxURNsAn+uPbHUfOTWPPE/h v8CU/UauYpotOdn+0XTiyxrHfGWi3i1aH5kcuG/mEj3q1nc1nXvG3huABELKPomGRMXy Pm+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r3iPstuNFz9WMCxiJ31uvg/6uYePN2X/R9c182XXUzQ=; b=r8c0VhY4yN4yh/8YjzWUTTfHTEMsQ5buBVuOgrZuRILviHxvSTUXwgz12RsoHHQ29x LmKS9N/3lMlc5H+OYyp7jSp/sBm9onpA4cdmeJJYzV0cqaIs+cFoy6OEaw4uZadiyswG 6nPSTCOSUIkDIdSdelhBa0KKYL27nUGRT3QNcs6xK6xwP+aqlXxgiRzWwVil4pGZz/cr sSjp+/HoTuwLpK8us0BDmNp4mdnZLdwJY4KIxy3xxyrC7I4tfqApJk2XOSgnFf3Zz26d 2dj347j3ErjP35HVSIJE4JEBNkVWEW+B+fA1UNPhIQOlWL0gmsHjXgDpkrl+jHoA9w87 n2eQ==
X-Gm-Message-State: ANoB5pkQ7s1qR3dUEO66jS3NGAo/LNlM11iY8Xj5KPH06o7ZBNQlbbKf ZUZFDRS2oEsk6Z9Pw7rL9Ws=
X-Google-Smtp-Source: AA0mqf4Bpg5QVt246U+rbCJ2o7j/HbL+2zos8C50AzMEV+5/J+4yewyckp+DGU0v8p4N9eUjyCRYMw==
X-Received: by 2002:a2e:9cd1:0:b0:279:d461:8528 with SMTP id g17-20020a2e9cd1000000b00279d4618528mr6270239ljj.389.1670317935698; Tue, 06 Dec 2022 01:12:15 -0800 (PST)
Received: from smtpclient.apple (178-55-124-38.bb.dnainternet.fi. [178.55.124.38]) by smtp.gmail.com with ESMTPSA id z8-20020a056512370800b004a91d1b3070sm2409180lfr.308.2022.12.06.01.12.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2022 01:12:15 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Subject: Re: [pim] Q on the congestion awareness of routing protocols
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <A892C9A1-7805-4595-B3AA-6A2ACE6AD1B2@ifi.uio.no>
Date: Tue, 06 Dec 2022 11:12:14 +0200
Cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, Dino Farinacci <farinacci@gmail.com>, Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>, bier@ietf.org, routing-discussion@ietf.org, tsv-area@ietf.org, pim@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <14B34A9D-36E8-4F6C-BF36-4CAE47BE720F@gmail.com>
References: <Y4ovyV074qa3gLSu@faui48e.informatik.uni-erlangen.de> <CAEeTejLa8sdJVU_2OfTo=ZgWRY-kv_7M=xiR-bLyBEXhSDP=Eg@mail.gmail.com> <e2527c9c-c7d1-c6b7-a067-e5ccbdc7e997@necom830.hpcl.titech.ac.jp> <E1p1PaX-009tgu-Hl@mta1.cl.cam.ac.uk> <c86d7ae6-3dad-04be-9c16-0135cc95fe73@necom830.hpcl.titech.ac.jp> <E1p1Rbe-009zgN-1s@mta1.cl.cam.ac.uk> <643e9272-979a-2a0a-d702-2b63cf0de5c4@necom830.hpcl.titech.ac.jp> <CAEeTejJ3yS2fARZNchumfkNyc0cnFfVSW7VdtBaGzhJQ9KmpBg@mail.gmail.com> <85AD093E-05C8-4A6C-8972-9310B8CAE5D5@gmail.com> <d77e4cac-81ff-7a25-73ae-8cb36dc0a8c6@necom830.hpcl.titech.ac.jp> <A892C9A1-7805-4595-B3AA-6A2ACE6AD1B2@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/wWtHwI2o5wShQPStLKSPLzCJh3c>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-area/>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2022 09:12:26 -0000

> On 6 Dec, 2022, at 10:57 am, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> I have a question. You keep saying that you use a TCP connection for every link. That seems odd, because, if that’s all it is, then congestion control doesn’t really do much… for CC to do something meaningful, it needs MUXing to happen at intermediate systems, in between the sender and receiver. Else, all one gets from TCP is reliability (is this a benefit here?) and flow control - and then, when too many packets arrive at a node at the same time, the app-layer - TCP buffer will become very large. This means that one would need congestion control again - now operating over TCP input buffers instead of network layer buffers. Hence, recursive  ;-)

Flow control is enough for TCP to usefully handle a bottleneck in the control plane.  Delays in delivery to the control plane result in a slower opening of the right edge of the receive window, and hence backpressure at the sender to make it reduce its send rate.  That's pretty much what we want to see, rather than just blasting packets blindly at line rate.

Additionally, it's not at all true that TCP congestion control has "nothing to do" in the absence of multiplexing.  If a data-plane or link-layer bottleneck arises, TCP congestion control can be used to prevent excessive packet losses.  I contend that retransmissions are slower than correctly pacing the traffic in the first place.

 - Jonathan Morton