[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
- [Coin] Semantic Routing : Problem and Solution Adrian Farrel
- Re: [Coin] Semantic Routing : Problem and Solution King, Daniel
- Re: [Coin] Semantic Routing : Problem and Solution Dirk Trossen