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

Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk> Tue, 06 December 2022 07:15 UTC

Return-Path: <Jon.Crowcroft@cl.cam.ac.uk>
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 50F5EC14F6E7; Mon, 5 Dec 2022 23:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=cl.cam.ac.uk
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 vAX4CmVGGf-E; Mon, 5 Dec 2022 23:15:38 -0800 (PST)
Received: from mta0.cl.cam.ac.uk (mta0.cl.cam.ac.uk [IPv6:2a05:b400:110::25:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139CDC14F738; Mon, 5 Dec 2022 23:15:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cl.cam.ac.uk; s=mta3; h=Message-Id:Date:Content-ID:Content-Type: MIME-Version:References:In-reply-to:Subject:cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=D40D3jrlvV+TbVP9+5jmesFM/SoKEpFW4SpK0Jsg7Vk=; t=1670310936; x=1671174936; b=SJXef9mLsK0lfMbJR5hxl65U//GLamxYAC+pklmxnCwTk8WGeUKyDOZ2lNOuWZYwCJCR4Leq3V1 ptazOVtyywRYZcuVsVHd3+0mACgyLaENUiX+vL1Wghy3MGEpRKjdxbqYGHxWL5i7yGlbQ+twTrCMR LdKc0tcT6AIaOQyr0HhTjLd1d97xGdK1jkHam0dTMwy4gJgRXob0rKiK+k9dnGBDs+JPo+3Uf8K6i c3LepE8PsUA8JtBclcE7OS6yBBils4h7Rj5kYZhYo25KDwlcpRdgc4PTE1bKSbixWjncCx/ymo3Lp 8RCtc2+oH00brVocMP94ys6HtoGNcjqUXB7w==;
Received: from ely.cl.cam.ac.uk ([2001:630:212:238:8cfa:7eff:feb6:efd7]) (dnseec=no) by mta0.cl.cam.ac.uk:587 [2a05:b400:110::25:0] with esmtp (Exim 4.94) id 1p2SAw-006HQa-3s (envelope-from <Jon.Crowcroft@cl.cam.ac.uk>); Tue, 06 Dec 2022 07:15:31 +0000
From: Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>
To: Dino Farinacci <farinacci@gmail.com>
cc: Stewart Bryant <stewart.bryant@gmail.com>, Matt Mathis <mattmathis=40google.com@dmarc.ietf.org>, Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>, BIER WG <bier@ietf.org>, tsv-area@ietf.org, pim <pim@ietf.org>, routing-discussion@ietf.org
Subject: Re: [pim] Q on the congestion awareness of routing protocols
In-reply-to: <52907137-CA5A-4042-AB2C-23FD9B032210@gmail.com>
References: <CAH56bmBnqi4peTWUXOVy0KRRXRc1L7TP+atFfVF6qb_OKBMBwg@mail.gmail.com> <C303F9BF-F96A-4710-A4B5-4228807C07F7@gmail.com> <52907137-CA5A-4042-AB2C-23FD9B032210@gmail.com>
Comments: In-reply-to Dino Farinacci <farinacci@gmail.com> message dated "Mon, 05 Dec 2022 12:36:25 -0800."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3294016.1670310931.1@ely.cl.cam.ac.uk>
Date: Tue, 06 Dec 2022 07:15:31 +0000
Message-Id: <E1p2SAw-006HQa-3s@mta0.cl.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/NuZZvrPulsXRYITnTz0Ig_P4hvI>
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: Tue, 06 Dec 2022 07:15:43 -0000

> > One thought is that we set up a shadow RRG operating independently of 
> the IETF meeting but meeting concurrently and at the same location. This 
> is what BoFs used to be before the IETF apparatus got hold of them and 
> formalised them. We can still use the draft infrastructure. If we cannot 
> have a IETF list, there is groups.io or similar. All a bit like Internet 
> Routing where we route around damage to the infrastructure.

> I'd be all for this idea.

path exploration? but consider the shadow pricing...

the tradeoff between convergence rate and congestion control seems to
be something that ought to be put on a more systematic grounding

cheers

j