[Coin] Semantic Routing : Problem and Solution

Adrian Farrel <adrian@olddog.co.uk> Mon, 28 February 2022 17:00 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D6C3A11FA for <coin@ietfa.amsl.com>; Mon, 28 Feb 2022 09:00:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdS_uvd5Ye5l for <coin@ietfa.amsl.com>; Mon, 28 Feb 2022 09:00:29 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 7B3783A132F for <coin@irtf.org>; Mon, 28 Feb 2022 09:00:29 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21SH0AUV027410; Mon, 28 Feb 2022 17:00:10 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D2C3346051; Mon, 28 Feb 2022 17:00:10 +0000 (GMT)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C50A146055; Mon, 28 Feb 2022 17:00:10 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS; Mon, 28 Feb 2022 17:00:10 +0000 (GMT)
Received: from LAPTOPK7AS653V ([148.252.133.209]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21SH08M3005141 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Feb 2022 17:00:09 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <coin@irtf.org>
Cc: <philip.eardley@bt.com>, "'Dirk Kutscher'" <ietf@dkutscher.net>
Date: Mon, 28 Feb 2022 17:00:09 -0000
Organization: Old Dog Consulting
Message-ID: <06fe01d82cc4$a57a0880$f06e1980$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdgsrmUyCCLZIFVHQGu6kI05tnoEmA==
Content-Language: en-gb
X-Originating-IP: 148.252.133.209
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26744.001
X-TM-AS-Result: No--8.767-10.0-31-10
X-imss-scan-details: No--8.767-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26744.001
X-TMASE-Result: 10--8.766600-10.000000
X-TMASE-MatchedRID: NEAz94+E/Lk9XGCCGG69UbJpcu2XCdkcJi9o/Zx5a4wNFCjTbXYtXHAw i8qlmI2o5G46d6IJTKSSO5yNTc0YfKn/B8tmgiNpqug9vIA2WODvQYvK/M6DTCbNZ5pVQyyIepM qtPiQJGkTI0lB8I+eIjrybmbofAHVAhgHKcq5RirL/nbytEh6GJQ7eT0DII9N+Z4EmkFYO6BMII 4004QPLjRLHEAwH0l8Ta7UCB6Y5ntl0B295avw4MVUBXy8OM3/KCYFr1mSkdAfaBJLrllK9dSHn JDq2yhMaAU2xwLorQHQnb45/hs++7mfiXo+ehxx4t2mucDkRBE2ugGkJu34ZtXHHVxCBSg+TBVb bJMrRldIG1Wo0+s740v4mMY7qP/b6olEShJ8uogNEGOVZ0MgDdq1p6neH75UcutmmT4xaZj4xeQ 9T0owA6L15TD97T9ELyAleXUczNy/1qkGdIkdrqRIIRm3YLajdmWMDQajOiJB7u7n6dBVqDcpXp PCV0E3vaNqd3Y9EXyucclXq7DjwE8gJp/LaGq7z7dAQlCr42/LBdK2mpaYln4BHa3k4X9uo8WMk QWv6iV95l0nVeyiuPvaZcqB7SGXC24oEZ6SpSkj80Za3RRg8LQzQkBofKt8uIGbf/hQBa+WbsWE 53l6V5Wgjg3axdC2OiBUDD2CVOg=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/jXUwDuWLIV2wYdvaBWdyOLXdArk>
Subject: [Coin] Semantic Routing : Problem and Solution
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2022 17:00:34 -0000

Hi again,

Two related questions were asked during the interim that may have slightly
missed the point of the work we are doing.

Phil Eardley asked about the comparison with MPLS saying, "You just said
something like 'Flag packet with behavioural quality that an ISP should
provide' - this sounds like MPLS, except you hope the 'flag' is not confined
to a domain. Wouldn't that have the same issues that inter-domain MPLS
does?"

And Dirk Kutscher noted that, "If the goal is to make the network do
something useful for applications, it may be useful to be more specific
about that exactly this could entail: Is it QoS on steroids?"

Both of these questions assume that what we are trying to do is engineer a
specific solution to a set of problems. But this is back to front. What we
have observed is that a lot (and I mean a lot) of technology enhancements
have been floated over the years aimed at solving one problem or another.
More proposals are made almost daily. The general problem space that these
solutions address can be loosely described as, "Getting the network to
differentiate the treatment of packets according to the service that the
traffic flows require as indicated by information carried in the packets."
Some of the proposals result in different queueing/forwarding behaviours,
while others result in traffic taking different paths through the network,
but you can probably safely categorise the whole thing as "QoS on steroids
with additional awareness of service functionality."

Our observation leads us to several things we want to see happen:

1. More coordination between research activities into this type of
problem/solution so that knowledge is shared and not "rediscovered" or
"reinvented" each time.

2. Better awareness of the impact on the routing system of applying these
solutions.

3. Greater understanding on the overlap with existing initiatives that are
both research and engineering, such as SDN, network programming, compute in
the network, etc.

4. A generic abstract definition for the field (building on a taxonomy and
an ontology, and which is not self-referential) and the research questions
that arise.

The first of these comes through our literature search draft and, of course,
by getting people to talk about the work on this list.

The second is initiated by draft-king-irtf-challenges-in-routing. We see
this document as a place to capture the current state of the discussion so
that no one has to trawl the email archives. It obviously deserves wider
review and input from the routing engineering community, too. The end result
may well be publication, but whether as a paper or an RFC or something else
is a decision to be made far in the future.

The third is definitely work in progress and for discussion. There are
several drafts kicking around that start to capture the discussions to date,
and (just as important) to open up topics for further debate on the COIN
list. We think there are also some papers being written in this area and we
hope they will show up in COIN. We are aware of a research project currently
seeking funding on this topic.

And finally, yes, there is a significant piece of work needed to abstract
the definition of semantic routing. That's going to take quite a lot of
effort, but it has started (collaborators welcome!)

As you can see, none of those amount to a technology problem we want to see
solved, or specific engineering solution.

I hope this helps answer the questions and also give some
context/perspective.

Best,
Adrian