Re: Q on the congestion awareness of routing protocols

Stewart Bryant <stewart.bryant@gmail.com> Sat, 03 December 2022 10:22 UTC

Return-Path: <stewart.bryant@gmail.com>
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 CCFCBC14CF17; Sat, 3 Dec 2022 02:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 43CW5zaKe51A; Sat, 3 Dec 2022 02:22:32 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B1EC14CE4C; Sat, 3 Dec 2022 02:22:32 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id j5-20020a05600c410500b003cfa9c0ea76so6241703wmi.3; Sat, 03 Dec 2022 02:22:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:content-transfer-encoding:from:to:cc:subject:date :message-id:reply-to; bh=E2clfYnNw8JWKWn8nAtDzbsq+rblvk4xZaHfPc04tWo=; b=qjM0E/ziqho4W03meXfy7zr3sIDS3cIRhGxng+e7Pf0sJj9uhB1Z5zjGXPpVCPWn/u YnEPwcPwBYazJBSXGSEN6RD8mCT7Mhxa1Tr5wtGPkbMpdwdkxl5iGWKfvVkCsO80Bx0E Zo1/VGuhcyM8agkCyQIEmyJVf5d39z/vqhPcoqn1LmuoinATZ0ciLDGvu8/5PwZdDfHH OjWBC5Sh1d86Rpm9PmGyiXqiP48G6eX4gs0cAZDJRDXmubHhgGUk7D1Rp85MGv3XWr4E LBQUhkuWAOyFp86UThgRZGsLM61uNdV7rIv5bZEZ5QPyL4NAy9w1n7/p0dv7Ospx2XGA VrMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:content-transfer-encoding:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=E2clfYnNw8JWKWn8nAtDzbsq+rblvk4xZaHfPc04tWo=; b=OLyo2Px47RwXetYX/qNyFSCpQOlLbd1nz/xSzY4nl7ORZPg6UvL/rcdjeUqgMCGPEI gdAm8whzcz0WWwUu/rJj9vjZch6dTYmT+U27dG2V0NGZo3PWH60MGxFKRdR7/A4BxBnX 8KhXWmoV5bXSER/sBiX4+KHeMNwKTwTMRQ4fYW8tst5BWDGCCStT2mKTvV54DcFnCDpX mOj1j/cBJLcM1pwEJfHI7b4vdP982x5BEBWCYQ8EoX/gW4bq8LY6MjEQdGB3zMt8AlRZ gNph7B7mbvugCkTwjihWKNQO0SOlcxzeELSGzJ5NdAQ38hhDgEaU5+me2VVVvWqa2mA3 uu5Q==
X-Gm-Message-State: ANoB5pl4a4AXK1SbU2ceO0pozABSLsYlDqiEBfxiIGwrql4VTwE1kVhR s9K8I7fd2Yr/IB2FZi88+xe97aWKWj8=
X-Google-Smtp-Source: AA0mqf71foG1TjbCYJc+IdzCJAtzO144ZikAflCqEQ87A4ohYgJKobRwjKBsGHVTaUMeQesSJBWl0w==
X-Received: by 2002:a05:600c:1e89:b0:3cf:774b:ce6f with SMTP id be9-20020a05600c1e8900b003cf774bce6fmr10840919wmb.133.1670062950054; Sat, 03 Dec 2022 02:22:30 -0800 (PST)
Received: from smtpclient.apple ([2a00:23c5:33a1:2101:18a5:9f3c:e54d:bee1]) by smtp.gmail.com with ESMTPSA id u2-20020adfdd42000000b0024242111a27sm4826488wrm.75.2022.12.03.02.22.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Dec 2022 02:22:29 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Q on the congestion awareness of routing protocols
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <CAH56bmBnqi4peTWUXOVy0KRRXRc1L7TP+atFfVF6qb_OKBMBwg@mail.gmail.com>
Date: Sat, 03 Dec 2022 10:22:18 +0000
Cc: Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>, bier@ietf.org, tsv-area@ietf.org, pim@ietf.org, routing-discussion@ietf.org
Message-Id: <C303F9BF-F96A-4710-A4B5-4228807C07F7@gmail.com>
References: <CAH56bmBnqi4peTWUXOVy0KRRXRc1L7TP+atFfVF6qb_OKBMBwg@mail.gmail.com>
To: Matt Mathis <mattmathis=40google.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (20B101)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/1l05e9zxqNKXrdtdjstrOr0tobo>
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 10:22:36 -0000


> On 2 Dec 2022, at 18:21, Matt Mathis <mattmathis=40google.com@dmarc.ietf.org> wrote:
> 
> 
> That work was more than 30 years ago, so it might pay to revisit it, to re-examine it to see if something has changed.   However, the conclusion matches my intuition.

A few thoughts spring to mind, firstly routing normally works on the basis of truth. This means that everyone jumps to the shortest low delay path. You could ask routers to be altruistic and use SR to use a higher latency path for some of their flows. A more radical approach is to get some routers to lie about cost in some way to reduce the extreme.

Secondly it occurs that since we last looked at this there has been the development of shortest time routing in car Sat navigation and there might be a trick or two to be borrowed from that industry. For example cars have de facto multiple independent competing algorithms working in parallel. So we could again use SR with some form of local AI based path choice mechanism.

As Toerless says we really need a routing research area in the IETF to develop these sorts of ideas. We have tried and always been met with refusal from IRTF management.

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.

Stewart