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 12:20 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 E0EE7C1522BD for <tsv-area@ietfa.amsl.com>; Sat, 3 Dec 2022 04:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 JDRoocaamqZB for <tsv-area@ietfa.amsl.com>; Sat, 3 Dec 2022 04:20:37 -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 78D2BC14CF09 for <tsv-area@ietf.org>; Sat, 3 Dec 2022 04:20:36 -0800 (PST)
Received: (qmail 4599 invoked from network); 3 Dec 2022 12:11:36 -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 12:11:36 -0000
Message-ID: <c86d7ae6-3dad-04be-9c16-0135cc95fe73@necom830.hpcl.titech.ac.jp>
Date: Sat, 03 Dec 2022 21:20:34 +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>
Cc: bier@ietf.org, routing-discussion@ietf.org, tsv-area@ietf.org, pim@ietf.org
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>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <E1p1PaX-009tgu-Hl@mta1.cl.cam.ac.uk>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/J5SiQrUim0onqQjXCcqTKOgHUC4>
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 12:20:43 -0000

Jon Crowcroft wrote:

> i suggest reading
> https://www.icir.org/floyd/srm.html

I did so before my previous reply.

But, it did not affect my understanding that there are so
many complicated protocols for reliable multicast. As such,
TCP mesh should be better as long as we follow the CATENET
model.

> plus any of many papers on tcp incast

I'm afraid that if TCP incast is a problem for control traffic,
there should be no bandwidth left for data traffic.

If lack of bandwidth is a problem for data traffic, the way to
go is QoS routing, which means, over QoS satisfied routes, we
have enough bandwidth for control traffic.

						Masataka Ohta

v2.23.0 | Report a Bug | By Email