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 13:02 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 376FCC1522AD for <tsv-area@ietfa.amsl.com>; Sat, 3 Dec 2022 05:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 VTj-W2ps1jsm for <tsv-area@ietfa.amsl.com>; Sat, 3 Dec 2022 05:01:57 -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 41B15C1522A6 for <tsv-area@ietf.org>; Sat, 3 Dec 2022 05:01:56 -0800 (PST)
Received: (qmail 5109 invoked from network); 3 Dec 2022 12:52:56 -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:52:56 -0000
Message-ID: <643e9272-979a-2a0a-d702-2b63cf0de5c4@necom830.hpcl.titech.ac.jp>
Date: Sat, 03 Dec 2022 22:01:55 +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> <c86d7ae6-3dad-04be-9c16-0135cc95fe73@necom830.hpcl.titech.ac.jp> <E1p1Rbe-009zgN-1s@mta1.cl.cam.ac.uk>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <E1p1Rbe-009zgN-1s@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/M5p7l1-rgPRrnh19tjkZyYJOpJo>
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 13:02:02 -0000

Jon Crowcroft wrote:

>>      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.

> incast isn't about persistent congestion, it is about synchronised
> sources.

Is it a problem even if all the multicast control traffic
between two routers is exchanged through a single TCP
stream?

						Masataka Ohta

v2.23.0 | Report a Bug | By Email