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:42 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: routing-discussion@ietfa.amsl.com
Delivered-To: routing-discussion@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67F5C14CE4C for <routing-discussion@ietfa.amsl.com>; Sat, 3 Dec 2022 01:42:48 -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=unavailable 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 2Ugk-YCM872Q for <routing-discussion@ietfa.amsl.com>; Sat, 3 Dec 2022 01:42:48 -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 AF1EEC14CF17 for <routing-discussion@ietf.org>; Sat, 3 Dec 2022 01:42:47 -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/routing-discussion/6d36A-6bU3WWHhgMwG69T14jNEw>
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area General Discussion list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/routing-discussion/>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2022 09:42:48 -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