IETF Logo Mail Archive

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

"Adamson, Robert B CIV USN NRL (5592) Washington DC (USA)" <brian.adamson@nrl.navy.mil> Mon, 19 December 2022 13:35 UTC

Return-Path: <brian.adamson@nrl.navy.mil>
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 DE416C14CE27; Mon, 19 Dec 2022 05:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nrl.navy.mil
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 24N-uHTObzUb; Mon, 19 Dec 2022 05:35:19 -0800 (PST)
Received: from mf.dren.mil (mfe.dren.mil [IPv6:2001:480:a0:f003::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB679C14CE28; Mon, 19 Dec 2022 05:35:16 -0800 (PST)
Received: from pps.filterd (mfe.dren.mil [127.0.0.1]) by mfe.dren.mil (8.17.1.19/8.17.1.19) with ESMTP id 2BJDZ2OV191099; Mon, 19 Dec 2022 13:35:02 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nrl.navy.mil; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=s2.dkim; bh=wVS758k2WvGTcnXqVGVPPF0o34WO0pxIZo2KkcgdlvU=; b=dL3x0XZlhccqhTcrEDbFQX6s/VnAFul0ED+RU4v34hg0TDgLTm5vNOroWgWhRv1pxUC6 laE7LfCWKwW9IpNqwK8L6+Gvp+Efn5hWtSxncfcrzkasUjnDSjGcUo0bBBQ2kEGQOgk+ dYTF7GhD0p9vwU7+mVTX5MvQt3wCvQ+/V5PtDx6B+g/wPtdMJXXVwjDLg5CGiHF0qhl6 3XEdJQJXGv/hEeXS2GfNNUyyWAKHwJuCrLE2hyvlOhlE/Gj2PY7UFOMN9CU8b45RC5E/ AOoiKUlIkferZHyUOAhQ74ZMQgOgnN1SZoCcfLzgZF8QShEcK8H02mzt3lYm6bTZ5wXH OA==
Received: from pps.reinject (localhost [127.0.0.1]) by mfe.dren.mil (PPS) with ESMTPS id 3mhq83yfw8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 13:35:02 +0000
Received: from mfe.dren.mil (mfe.dren.mil [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2BJDZ28L191084; Mon, 19 Dec 2022 13:35:02 GMT
Received: from mail6.nrl.navy.mil (smail6.nrl.navy.mil [IPv6:2001:480:20:421:0:0:25:116]) by mfe.dren.mil (PPS) with ESMTPS id 2BJDZ1M7191074 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 13:35:02 +0000
Received: from G1950SRVB2000.WDC.GEN.NRL.NAVY.MIL (nrl-mail-mrs.nrl.navy.mil [128.60.31.200]) by mail6.nrl.navy.mil (8.15.2/8.15.2) with ESMTPS id 2BJDZ1mr016008 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Dec 2022 08:35:01 -0500
Received: from G1950SRVB2001.WDC.GEN.NRL.NAVY.MIL (2001:480:20:2031:31::201) by G1950SRVB2000.WDC.GEN.NRL.NAVY.MIL (2001:480:20:2031:31::200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Mon, 19 Dec 2022 08:35:00 -0500
Received: from G1950SRVB2001.WDC.GEN.NRL.NAVY.MIL ([fe80::d1d8:a0fa:8863:95de]) by G1950SRVB2001.WDC.GEN.NRL.NAVY.MIL ([fe80::d1d8:a0fa:8863:95de%15]) with mapi id 15.01.2507.016; Mon, 19 Dec 2022 08:35:00 -0500
From: "Adamson, Robert B CIV USN NRL (5592) Washington DC (USA)" <brian.adamson@nrl.navy.mil>
To: Jonathan Morton <chromatix99@gmail.com>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>
CC: BIER WG <bier@ietf.org>, "routing-discussion@ietf.org" <routing-discussion@ietf.org>, Matt Mathis <mattmathis=40google.com@dmarc.ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>, pim <pim@ietf.org>
Subject: Re: [pim] Q on the congestion awareness of routing protocols
Thread-Topic: [pim] Q on the congestion awareness of routing protocols
Thread-Index: AQHZErAglXfwpn0OY0C1+TZH7XalN651NfSA
Date: Mon, 19 Dec 2022 13:35:00 +0000
Message-ID: <4D5036B1-1158-4DB2-ADC8-EBECEFE1690E@nrl.navy.mil>
References: <CAH56bmBnqi4peTWUXOVy0KRRXRc1L7TP+atFfVF6qb_OKBMBwg@mail.gmail.com> <C303F9BF-F96A-4710-A4B5-4228807C07F7@gmail.com> <52907137-CA5A-4042-AB2C-23FD9B032210@gmail.com> <E1p2SAw-006HQa-3s@mta0.cl.cam.ac.uk> <Y5M8RSjDuTLqJ/+v@faui48e.informatik.uni-erlangen.de> <BL0PR05MB56529DBC5D9299428B0D2A84D4E79@BL0PR05MB5652.namprd05.prod.outlook.com> <607179AB-1603-4D8A-84FF-D379E1C57AB4@gmail.com>
In-Reply-To: <607179AB-1603-4D8A-84FF-D379E1C57AB4@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.60.31.173]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1BCE5DFC3359FA4E95CFA7E929360198@mail.nrl.navy.mil>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.85 on 132.250.21.116
Archived-At: <https://mailarchive.ietf.org/arch/msg/routing-discussion/RtXB5BSVcWm2ElTkPamf20fEe2A>
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: Mon, 19 Dec 2022 13:35:24 -0000

The NORM (NACK-Oriented Reliable Multicast) protocol (RFC 5740) implements a form of TCP-Friendly congestion control.  An open-source implementation is available at: 

https://github.com/USNavalResearchLaboratory/norm

The implementation provides for message delivery in a couple of different forms in addition to bulk content transfer and a number of controls are available for customizing flow control including application-controlled positive acknowledgement and reliability mechanisms including options for hybrid packet erasure FEC coding / ARQ.     Incidentally, it can also work a reliable UDP-based unicast protocol with some advantages for some use cases and network environments.

Just pointing it out as a candidate for where multicast and congestion control may be needed.

Best regards,

Brian


On 12/18/22, 2:12 AM, "routing-discussion on behalf of Jonathan Morton" <routing-discussion-bounces@ietf.org <mailto:routing-discussion-bounces@ietf.org> on behalf of chromatix99@gmail.com <mailto:chromatix99@gmail.com>> wrote:


> On 17 Dec, 2022, at 4:32 pm, Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org <mailto:40juniper.net@dmarc.ietf.org>> wrote:
> 
> - There are situations where a non-TCP based solution is needed even when a parallel TCP-based option is also present, so we can not simply disallow the former. We can discuss examples separately (one example is actually PIM as BIER overlay vs mLDP/BGP as BIER overlay).


There are also congestion control algorithms that don't rely on an underlying TCP session, such as TFRC (TCP Friendly Rate Control). Possibly these could be applied to existing protocols.


- Jonathan Morton
_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org <mailto:routing-discussion@ietf.org>
https://www.ietf.org/mailman/listinfo/routing-discussion <https://www.ietf.org/mailman/listinfo/routing-discussion>

v2.23.0 | Report a Bug | By Email