IETF Logo Mail Archive

Re: Q on the congestion awareness of routing protocols

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sat, 03 December 2022 09:36 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 2C032C14F5E0 for <tsv-area@ietfa.amsl.com>; Sat, 3 Dec 2022 01:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 gzyIp4MbwEQa for <tsv-area@ietfa.amsl.com>; Sat, 3 Dec 2022 01:36:09 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0A41AC14F692 for <tsv-area@ietf.org>; Sat, 3 Dec 2022 01:36:07 -0800 (PST)
Received: (qmail 2102 invoked from network); 3 Dec 2022 09:27:06 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 3 Dec 2022 09:27:06 -0000
Message-ID: <e2527c9c-c7d1-c6b7-a067-e5ccbdc7e997@necom830.hpcl.titech.ac.jp>
Date: Sat, 03 Dec 2022 18:36:04 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1
Subject: Re: Q on the congestion awareness of routing protocols
Content-Language: en-US
To: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>, Toerless Eckert <tte@cs.fau.de>
Cc: routing-discussion@ietf.org, tsv-area@ietf.org, pim@ietf.org, bier@ietf.org
References: <Y4ovyV074qa3gLSu@faui48e.informatik.uni-erlangen.de> <CAEeTejLa8sdJVU_2OfTo=ZgWRY-kv_7M=xiR-bLyBEXhSDP=Eg@mail.gmail.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <CAEeTejLa8sdJVU_2OfTo=ZgWRY-kv_7M=xiR-bLyBEXhSDP=Eg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/Xscmx5FWA2HpyM9Me63hZQbS8GY>
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: Sat, 03 Dec 2022 09:36:10 -0000

Jon Crowcroft wrote:

> Gonna say, ironically, one early use of multicast was a proposal to use SRM
> instead of a mesh of tcp connections for iBGP...so some people do think
> about scaling control plane traffic in the presence of congestion, some
> times:-)
That is a terrible approach, because, even within a link, TCP
mesh is the way to go against congestion.

That is, within each link, routers should not rely on link
multicast to exchange multicast control messages and should
have TCP mesh between them over which the messages can be
exchanged reliably even if there is congestion, which is
what I did in 2001 with SRSVP (Simple RSVP, a stable and
hierarchical unicast/multicast QoS routing protocol
without crank back).

					Masataka Ohta

v2.23.0 | Report a Bug | By Email