[alto] ALTO multidomain extension

"Y. Richard Yang" <yry@cs.yale.edu> Wed, 04 November 2020 22:12 UTC

Return-Path: <yang.r.yang@gmail.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 D38593A0FC4 for <alto@ietfa.amsl.com>; Wed, 4 Nov 2020 14:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 HhY8Ev8tuFzY for <alto@ietfa.amsl.com>; Wed, 4 Nov 2020 14:12:49 -0800 (PST)
Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56113A0ED7 for <alto@ietf.org>; Wed, 4 Nov 2020 14:12:48 -0800 (PST)
Received: by mail-lf1-f43.google.com with SMTP id e27so6416523lfn.7 for <alto@ietf.org>; Wed, 04 Nov 2020 14:12:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bpiIYUjb3Stq4SE6sB3hfct2gSDffpZ+3ogPd9AQomk=; b=JfvEYmx0usQSkkr2ECxK/Ea5sFdwuu8aJs1vpZBD7fm64hYmV+ZFUPGB8LUmfGNOwk tcCm+8l+oH8/SdeIqu9LaL6taUBC7YrB6QOlOr5wwYTvMv7n28LBHC6r2ycg+7GgZqHg UF1pPkrblxmgvxNCm/UB9Pv167VA5keMZkVCwzALHZNRkaZG3TF69sRo8irPrp4szEQk P8RCYCBAXAN78VZtM9NOl4zQe/EZ8RFcW14wxE3BXxU92BoRaohfXaVsJrl2JYfWpiNe DyZBQPV3LLK1hcmAEB6AU9AwpnPFHFRAcFm+Y01ceiOYQqXM04LzoF38oSHsLcvfZZbN hj2g==
X-Gm-Message-State: AOAM533JXMfJgq0xFIA4+hSBZSDsMgmpbPiKGrCcId0pCErcgUvLVqIB Leoazbu4NYcAK0P1ceJ7oyOlCofkw0Xe9uGAa2wCLPO3mXn/Jw==
X-Google-Smtp-Source: ABdhPJwgfpjutlQP18Qvb14SY02GRCQ3OxvfFj1gQBfyumbqE8bW68ey9+2lhXoPVXobo838iGwkJwrnY22Ef+L1kJY=
X-Received: by 2002:ac2:5c45:: with SMTP id s5mr9887206lfp.302.1604527966588; Wed, 04 Nov 2020 14:12:46 -0800 (PST)
MIME-Version: 1.0
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Wed, 04 Nov 2020 17:12:35 -0500
Message-ID: <CANUuoLonZ6NMyO_sHjgKD2UqVAci_JcH4tPWrwoXnKs_OJmRJw@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007b163205b34f47d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/aKgF4SHbHZLmJjOxTpoxrNCeYrA>
Subject: [alto] ALTO multidomain extension
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 04 Nov 2020 22:12:51 -0000

Dear ALTOers,

During the weekly meeting yesterday, one issue discussed is an extension of
ALTO to multidomains. This is a relevant issue and investigated by Ingmar,
Sebastian, Kai and Qiao. Below is a proposal to get the WG feedback.

Problem: Consider a basic ALTO service say the endpoint-cost service (ECS).
The client has a set of (srci, dsti) pairs which we call flows, and a
performance metric m; the client wants to query the system to receive the
value of m for each flow. The existing ALTO framework solves the issue in
the context of a single domain network as follows:

- Use ALTO service discovery (using an address say srci) to find the single
ALTO server
- Send the ECS query to the server

The preceding will not work if the {(srci, dsti)} span multiple networks.
Consider the simplest case of only one flow, but the path of the flow spans
multiple networks: assume src is in network 1,

src ---> net1-int ----> net1-egress ---> net2-ingress ----> net2-int --->
dst,

then the information does not come from a single network (via its ALTO
server), but should come from multiple segments, assuming that there is not
an aggregator ALTO server sering both net1 and net2, Hence, it is a
relevant issue that we should solve.

To show that this is not a research problem because it has no solution yet,
the team designed an initial solution which should address the following
two tasks:

[T1] first, we need a solution to discover that the path from a src to a
dst.
[T2] given a network, the query will no longer be from the src to the dst,
but from a given ingress.

A first solution demonstrating the feasibility is the following:

- [E1] For a given network, add a new ALTO service with
  input: a flow, its ingress to the network
  output: the egress of the flow from the network, and the ingress of the
network
  // To address issue that there can be internal addresses (e.g.,
net1-egress, net1-ingress), we design that the return includes a network
identifier

- [E2] Extend basic (full path) cost service to collect segment cost.

Basic single flow case:

  input: a flow, its ingress to the network. [egress of this network;
ingress-next]
  output: the cost (metric m) of the flow traversing the segment from
ingress to egress
 // comment: missing the segment from egress to next ingress; in general
case, we can include the segment from ingress to next ingress for
consistency but the WG can discuss this issue for final design.

General multi flows, as the original cost service. Then the client using E1
can construct a flow graph from all flows specified in the original ECS
query, e.g.,

 src1 ---> net1-int ---> net1-egress ---> net2-ingress ---> net2-int -->
dst1
                                ^
     \
                               /
      \
 src2 --> net1-int  -
net2-int --> ...


For the same network, the client collects all sgements traversing the
network and issue a single query. Note that this makes the original cost
services just c a special case.

[E3] Instead of client conducting aggregation (aka DNS iterative), the
client can request an aggregator like query (aka DNS recursive). Single the
aggregator may not be able to aggregate data from different networks for
some metrics (e.g., internal-cost), the results will be a vector instead of
a single number.

We will go over some details during the recharter discussion in 2 weeks but
want to share this simple, clean design first with the WG to seek feedback.

Cheers,
Richard