Re: [alto] ALTO service query spanning multiple domains (ECS)

Qin Wu <bill.wu@huawei.com> Fri, 16 September 2022 03:31 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8242DC14CE26 for <alto@ietfa.amsl.com>; Thu, 15 Sep 2022 20:31:52 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 GaZXhrXzipgv for <alto@ietfa.amsl.com>; Thu, 15 Sep 2022 20:31:48 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FA6C14CE25 for <alto@ietf.org>; Thu, 15 Sep 2022 20:31:48 -0700 (PDT)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MTKMZ3LyCz67bJc for <alto@ietf.org>; Fri, 16 Sep 2022 11:30:18 +0800 (CST)
Received: from canpemm100007.china.huawei.com (7.192.105.181) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 16 Sep 2022 05:31:45 +0200
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm100007.china.huawei.com (7.192.105.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 16 Sep 2022 11:31:43 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2375.031; Fri, 16 Sep 2022 11:31:43 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>, IETF ALTO <alto@ietf.org>
Thread-Topic: [alto] ALTO service query spanning multiple domains (ECS)
Thread-Index: AdjJepF3qPS5NgSdTFOJYynLQokuBQ==
Date: Fri, 16 Sep 2022 03:31:43 +0000
Message-ID: <41977391b0744698b0d9e56dce502f68@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: multipart/alternative; boundary="_000_41977391b0744698b0d9e56dce502f68huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/RUw_CS79CKbO2gV4aHm3k4pXAy4>
Subject: Re: [alto] ALTO service query spanning multiple domains (ECS)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Sep 2022 03:31:52 -0000

Hi, Richard:

发件人: alto [mailto:alto-bounces@ietf.org] 代表 Y. Richard Yang
发送时间: 2022年9月14日 1:47
收件人: IETF ALTO <alto@ietf.org>
主题: Re: [alto] ALTO service query spanning multiple domains (ECS)

Hi all,

There were quite extensive discussions, on the reactive/on-demand, multi-domain design below, during the weekly meeting early this morning and here is a brief summary of the key points.

- The design can be decomposed into two components: routing composition and cost metric composition, from single domains to multiple domains:
   (metricVal, egressIP) = alto-server.query(ingressIP, srcIP, dstIP, metric)
[Qin Wu]  I feel this formula doesn’t explicitly indicate this is multi-domain setting, when srcIP and dstIP belong to different domains, we need to calculate ingressIP and egressIP in each domain one by one, also metricValue is not end to end metric, it is edge to edge metric.
   =>
   egressIP = query(ingressIP, pkt-attributes)  // Q1
   metricVal = query(ingressIP, pkt-attributes, metric) //Q2

- It turns out that there can be at least multiple potential design points:
  For Q1: It can have two designs:
     - D1.1 It can be that Q1 is out of scope for ALTO, for example, by using a routing system to conduct the query
[Qin Wu] if each alto server can calculate edge to edge metric from ingress node to egress node in each domain, why bother routing system to conduct the query, the routing system can provide measurements and inject measurement results to alto server. No?
     - D1.2 It can be a new service/metric type in ALTO
[Qin Wu] yes, you can introduce new service/metric type in ALTO, we have already define similar service/metric type in PCE, see RFC8233.
In addition, as I clarified in the previous email, we need to distinguish server to server communication within a domain and one across domains, this require ALTO protocol extension, e.g., inter-domain flag indication, I am not sure stitching label is required,
In PCE use case, stitching label is required to setup end to end path across domain.
  For Q2: it also can have two designs:
     - D2.1 using the current RFC7285 for Q2, with specifying ingressIP as src, in the ECS query
       This design is good if a network is destination-based routing
     - D2.2 We add an extension to ALTO ECS, to include general packet (and pseudo packet) attributes

  For the extension design path, it can help to
      (1) convey the matching requirements in the IRD (for example, what packet attributes to be included)
      (2) return indicates the equivalent classes (matching masks).
[Qin Wu] I am not sure caching is required in this case, I am worried about matching masks might be error prone. I suggest to investigate how Backward-Recursive PCE-Based Computation (BRPC) Procedure defined in RFC5441 can be used, instead to solve your problem.
The design team will proceed with the simple designs first to push forward the deployment, but will document the proceeding.

Cheers,
Richard



On Mon, Sep 12, 2022 at 10:50 PM Y. Richard Yang <yry@cs.yale.edu<mailto:yry@cs.yale.edu>> wrote:
Hi all,

During the weekly meeting last week, we went over the details when deploying ALTO in a multi-domain setting, say the FTS/Rucio setting supporting the TCN deployment [1]. Below is the endpoint cost service (ECS) case, and it was suggested that we post it to the WG mailing list to update the WG and get potential feedback.

Problem: An ALTO client queries the endpoint cost from srcIP to dstIP for a given performance metric (e.g., latency). Consider the case that the srcIP and dstIP belong to different networks, with the whole layer-3 path as the list [ip[0], ip[1], ..., ip[N]], where ip[0] = srcIP and ip[N] = dstIP. Define Net(ip) as the function that maps an IP address to the network that owns the IP---ignore the complexity such as anycast since the deployment does not have this case. Then Net(srcIP) != Net(dstIP), if it is multi-domain. Consider the initial deployment that we have only an ALTO server for each network; that is, it provides ALTO service for only Net(srcIP) == Net(dstIP). Then, there is not a single ALTO server that can provide the answer.

Basic solution (one src-dst flow): Map the list [ip[0], ..., ip[N]] to a list of segments, where each segment starts with an IP address, and ends with the first IP address in the sequence that leaves the network of the start IP address. Hence, the basic query framework at an aggreation ALTO client:
- alto-ecs(srcIP, dstIP, metric)
  metrics = EMPTY
  ingressIP = srcIP
  do {
      alto-server = server-discovery(ingressIP)
      (metricVal, egressIP) = alto-server.query(ingressIP, srcIP, dstIP, metric)
      metrics.add(metricVal)
      ingressIP = egressIP
  } while (egressIP != dstIP)

The preceding assumes a procedure that collects segment attributes, and it can be a single pass composition using a metric-dependent function (e.g., latency is addition, and bw is min).

Multi-flow queries: ALTO ECS supports the querying of multiple src-dst pairs. A simple solution is to query each src-dst pair one-by-one. Such a query is necessary because the routing can be dependent on packet attributes (srcIP, dstIP) and a pseudo packet attribute (ingressIP), and the ALTO client cannot reuse the results. To allow reuse (both in multi-flow queries and caching of past queries), it helps that the ALTO server indicates equivalent classes, which Kai and Jensen investigated.

A revision of the protocol using caching and equivalent class is:
alto-server-cache: indexed by ALTO server, <attribute, mask> pairs
- alto-ecs(srcIP, dstIP, metric)
  metrics = EMPTY
  ingressIP = srcIP
  do {
      alto-server = server-discovery(ingressIP)
      if (alto-server-cache.match(alto-server, ingressIP, srcIP, dstIP)
         use cache results
      else
         (metricVal, egressIP; ingressIPMask, srcIPMask, dstIPMask)
                 = alto-server.query(ingressIP, srcIP, dstIP, metric)
         alto-server-cache.add(alto-server, <ingressIP, ingressIPMask>,
                    <srcIP, srcIPMask>, <dstIP, dstIPMask>
      metrics.add(metricVal)
      ingressIP = egressIP
  } while (egressIP != dstIP)

The mask design is a special case. For the general case, the most flexible equivalent class may be using predicates (e.g., supporting identifying the lower entries of longest prefix matching). It is an issue that can benefit from more benchmarking, or if there are any related pointers, the team will appreciate the pointers.

In the next email, Kai and Jensen will post a slightly different design supporting a map oriented service.

Cheers,

[1] Transport control networking: optimizing efficiency and control of data transport for data-intensive networks, https://dl.acm.org/doi/abs/10.1145/3538401.3548550