Re: [alto] ALTO Draft ReCharter WG review

Qiao Xiang <xiangq27@gmail.com> Wed, 10 March 2021 13:34 UTC

Return-Path: <xiangq27@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 9CE123A03C9 for <alto@ietfa.amsl.com>; Wed, 10 Mar 2021 05:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Hoxw4e38jy-5 for <alto@ietfa.amsl.com>; Wed, 10 Mar 2021 05:34:41 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 06D1D3A0121 for <alto@ietf.org>; Wed, 10 Mar 2021 05:34:41 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id f8so11318241otp.8 for <alto@ietf.org>; Wed, 10 Mar 2021 05:34:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZVhj4EMr7/XUIWyELEiVW9XnwpWu+bzHhWYxinEPt5g=; b=pHMaq1EWz3p9764A5c7QRuh2Df3Fj2L8o9BcK4eTUpsGg1qLxoNv/7duNd1kw/nEgq CNHK0OZ5WT9/rhVMBuH2uTL4MWNfhzjuZ/sYdz7QHnmSGlDtvErBCCRL6ozJtqzt7uuz pDMC1djf/1JjCUPfWbAX3EL425jopd1juY/0C1ufsmfDlUKF8ZqB0K7IhH9vTFrkavcS pppyB6Kt3OMJ7jognkHRecQZAxpwS4hGm/QDDzmOJ+4p5mwnr14G9qBoM3NpYOxQ/UFt 9QuxF0vvDXUOEdt/FuVyxytjadTHVOGfBiBTUZBN6v3JuVfbSBrpzMpuSafsrwwPBact o8JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZVhj4EMr7/XUIWyELEiVW9XnwpWu+bzHhWYxinEPt5g=; b=NPsw3Fixw5b/S5vmtKR/CQGNM7ThBNSfLeHehaJX9M2qpD4zRyg1KyFjQh04iugLTL fgJ6lI2YieQVigXzIjxw73EHDAVe+3JME6F+KFZrv5oeFBONDPyGj1SZEcML1KZGJGKT UYAduzpPau3kHQOZIcWKw3lUSbWYcAcSn+0fz3LkDxqGgf4u+agfi+mBsiSnuQkkFYUC 6lR17JtxJD3Pir5ydbhC2KcuyOQsI5cTNPivL6J5YTMLqlJ++P7QwgFZRhNM0JSsz50z JtQcSp2n939LSaWOyktKlJoPN69cm3zAy6hw78SMGy2RzK7gzCVVZ3Qr3EbJZA3Jn9qd GtkA==
X-Gm-Message-State: AOAM533Bj6iLQyCpcWMeoaQ4puAOMsR3mcXGDv4OZ4DLiU0WvYCRIK2K s22w5AqVRsJTGYZFgKgVEWIva3Omb1Bb4Y4FQRM=
X-Google-Smtp-Source: ABdhPJzT2KtQkPNcS/EqvEIyxXIRL3hT1cg66EP9WC79Uv7Y8kHzN848QHgVlx9ZLHmkgpUEAZR0/w9pgdFR3W4ggwg=
X-Received: by 2002:a9d:8b5:: with SMTP id 50mr2605234otf.93.1615383278898; Wed, 10 Mar 2021 05:34:38 -0800 (PST)
MIME-Version: 1.0
References: <20210302131418360366673@chinamobile.com> <CAOB1xS9XyhicYuBvDrXGJy5jp_GuUF5eT-oBC-posnyrCb9nEA@mail.gmail.com> <CANUuoLqDcyphfCDLdpVzH9myo3oWBJOkMiq0F8uwMyj5XLZ_xg@mail.gmail.com>
In-Reply-To: <CANUuoLqDcyphfCDLdpVzH9myo3oWBJOkMiq0F8uwMyj5XLZ_xg@mail.gmail.com>
From: Qiao Xiang <xiangq27@gmail.com>
Date: Wed, 10 Mar 2021 21:34:27 +0800
Message-ID: <CAOB1xS8xhUeK_k9xsFf53PtVG=2-nncNjik-jN9pL5y=EA+cxA@mail.gmail.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>
Cc: =?UTF-8?B?5YiY6bmP?= <liupengyjy@chinamobile.com>, IETF ALTO <alto@ietf.org>, Qin Wu <bill.wu@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000083d1cc05bd2ebaa7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/tLyA4hqU1995868U7l8F0f85MSE>
Subject: Re: [alto] ALTO Draft ReCharter WG review
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, 10 Mar 2021 13:34:45 -0000

Hi Richard,

Thanks for sharing your thoughts and the base line. I'll also think about
the security/privacy issues in multi-domain settings in the next few weeks.


Best
Qiao

On Wed, Mar 10, 2021 at 10:31 AM Y. Richard Yang <yry@cs.yale.edu> wrote:

> Hi Peng, all,
>
> Thanks a lot for the excellent discussions. It is clear that multi-domain
> is a major issue to resolve, as multidomain is the general deployment
> setting where resource consumers and providers are in the general case
> deployed in multiple networks.
>
> To proceed with the recharter discussion, I suggest that we conduct basic
> security and privacy analysis to see if we are ready for recharter; that
> is, we have a basic understanding of related issues so that it is ready for
> design, not still in the early research stage. For security, we can start
> with focusing on the basic requirements including authenticity, integrity,
> and confidentiality. For privacy, we can start with a framework such as
> differential privacy analysis.
>
> To me, a basic model of a multi-domain alto information service is the
> following:
> - a set of (potential) resource providers s1, s2, ...,
> - a set of (potential) resource consumers c1, c2, c3, ...
>
> The foundation of the alto service is to provide the costs of the paths
> {si -> cj}; I always think of alto as an extension of DNS, which is mainly
> for endpoints in a graph and alto is paths. In a single domain setting, all
> entities, {si}, {cj}, {si->cj} are within a single domain and hence the
> main security/privacy issue is the security/privacy issue of between the
> single alto server representing the single domain and the alto client. For
> security, the domain can leverage any one of the security systems (e.g.,
> using public keys to bootstrap the system); for privacy, the application
> (client) and the network (server) are two parties, and they can agree on an
> acceptable privacy model.
>
> Now, in a multi-domain setting, each entity may have a different domain
> (or a sequence of domains for a path). Now, both ALTO client and ALTO
> server will have additional security and privacy issues.
> - For the ALTO client, the information can now come from multiple
> networks; assume the information info(n1, n2, ...)  is computed from those
> from multiple networks n1, n2, ... Then the basic security issue is how the
> client can verify the authenticity of the information.
> - For an ALTO server, the server may not have a direct trust relationship
> with the client; for example, when the ALTO server is only in the chain of
> a path, not the client-facing server. Hence, the server may not have a
> relationship to specify the privacy requirement.
>
> The preceding are challenging issues. It is clear that security and
> privacy issues depend on the specific design. Hence, we target a
> "lower-bound" analysis, by considering a base design that can address main
> security and privacy issues. The WG can decide on the specific design which
> is better than the basic design.
>
> During the design meetings, we have considered the following "base-line"
> design for a "lower-bound":
> -  We provide a basic path discovery service to discover the path
> segments. We can use BGP security to bootstrap the security of the
> discovered paths.
> - We build verifiable aggregation (i.e., the preceding info function) so
> that the information can then be individually verified.
> - The remaining issue is how each server can control the privacy of its
> information, as it may not have a direct relationship with the client. For
> this, we suggest to start with basic public information, and gradually
> build trust.
>
> The preceding is high level. A first task, if multidomain is charted, is
> to write down the details, beyond the existing drafts. I do agree that this
> analysis and requirements is a good starting, based on the specified use
> cases.
>
> We can go over the details in our design meeting in the next few following
> weeks.
>
> Richard
>
>
>
>
>
>
> On Tue, Mar 2, 2021 at 11:18 AM Qiao Xiang <xiangq27@gmail.com> wrote:
>
>> Hi Peng, Qin and Richard,
>>
>> Very good discussion! Richard and I have been working with folks from CMS
>> and ESNet (a large global multi-domain science network) to design network
>> information exposure abstractions and mechanisms in multi-domain
>> networks, with privacy requirements considered. The basic idea stems from
>> the ALTO path-vector extension but goes beyond to take privacy into
>> consideration. The following are some pointers.
>>
>> [1] "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain
>> Network Resource Discovery", IEEE JSAC, 2019. (
>> https://ieeexplore.ieee.org/abstract/document/8756056)
>> [2] "Resource Orchestration for Multi-Domain, Exascale, Geo-Distributed
>> Data Analytics", (
>> https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/)
>>
>> For the pointers above, the privacy requirement considered in this work
>> is that the network information of multiple domains should be exposed to
>> applications as a complete, unified aggregation, appearing as much as
>> possible as from a single (virtual) network. We design a network
>> information obfuscation mechanism so that the application is not able to
>> associate any network resource bottleneck information to any domain,
>> reducing the risk of exposing network vulnerability.
>>
>> In addition, we also studied how to control the routing across multiple
>> domains to achieve more flexible end-to-end interdomain routing.
>> Essentially, we propose a mechanism that allows networks to expose their
>> available interdomain routes, just as BGP looking glasses, so that
>> applications can control them. In this setting, we consider the privacy
>> setting where each network's BGP export policies are private, and design
>> interesting algorithms for applications to select the best policy-compliant
>> routes without knowing the export policies. The following is the pointer
>> for this study:
>>
>> [3] "Toward Optimal Software-Defined Interdomain Routing". INFOCOM 2020 (
>> https://ieeexplore.ieee.org/abstract/document/9155486)
>>
>> Above are our current efforts on extending ALTO to multi-domain settings.
>> It would be great if we can know more about the industry efforts on network
>> information exposure in multi-domain settings, and the privacy requirements
>> of operators. This would be extremely helpful to push this extension
>> forward! :-)
>>
>>
>>
>> Best
>> Qiao
>>
>> On Tue, Mar 2, 2021 at 1:14 PM 刘鹏 <liupengyjy@chinamobile.com> wrote:
>>
>>> Hi Richard,
>>>
>>> Thank you. please see my reply inline below.
>>>
>>>
>>> Peng Liu | 刘鹏
>>> China Mobile | 移动研究院
>>> mobile phone:13810146105
>>> email: * liupengyjy@chinamobile.com <liupengyjy@chinamobile.com>*
>>>
>>>
>>> 发件人: Y. Richard Yang <yry@cs.yale.edu>
>>> 时间: 2021/03/02(星期二)07:36
>>> 收件人: 刘鹏 <liupengyjy@chinamobile.com>om>;
>>> 抄送人: IETF ALTO <alto@ietf.org>;Qin Wu <bill.wu@huawei.com>om>;
>>> 主题: Re: [alto] ALTO Draft ReCharter WG review
>>>
>>> Dear Peng,
>>>
>>> Thank you so much for the feedback. Please see below.
>>>
>>> On Fri, Feb 26, 2021 at 9:23 PM 刘鹏 <liupengyjy@chinamobile.com> wrote:
>>>
>>>> Hi WG,
>>>>
>>>>
>>>> Here are some considerations of recharter:
>>>>
>>>> I believe that the multi domain problem is worthy of attention.
>>>>
>>>
>>> It is good info.
>>>
>>>
>>>> At present, operators also research in it, which may involve
>>>> guaranteeing end-to-end network service in the future, such as delay,
>>>> bandwidth, etc. There are some researches on cross domain deterministic
>>>> network in the industry, which need some support from management and
>>>> control plane.
>>>>
>>>
>>>  Do you want to share some pointers?
>>>
>>> [Peng] As Qin said, it is hard to collect information across network
>>> borders.
>>>
>>> Just taking deterministic network as an example, it is hard to applying
>>> synchronization, unified forwarding strategy in multi domain, so there
>>> are some works need to be done with management plane. Due to the large
>>> scale and multi domains or operators, the management system may be
>>> distributed.
>>>
>>> A potential way is to consider negotiating the forwarding time of each
>>> domain in advance and carrying time stamp in the message to control the
>>> forwarding path of each domain. While it needs some agreements like
>>> contracts to prevent one party from tampering with and denying the
>>> management content.
>>>
>>> Beside this, there may be others use case. I'm not sure if Alto servers
>>> are willing to do those work, but it may be helpful to collect or configure
>>> some key information.
>>>
>>> Who is the provider of Alto service is related to the deployment and
>>>> cooperation mode. It may be difficult for operators to give too much
>>>> detailed network information now. If the Alto service belongs to the
>>>> operator, it may be used to help manage its own network. If Alto service
>>>> belong to non operators, I think the issue of how to cooperate needs
>>>> further discussion.
>>>>
>>>>
>>>> It looks that you want to consider both modes: multidomains but single
>>> operator (i.e., intra-cooperation) and multidomains and multiple operators.
>>> Regardless, I agree that it is important for the work to clarify on the
>>> privacy requirements.
>>>
>>> [Peng] Yes, agree.
>>>
>>> Richard
>>>
>>>
>>>
>>>
>>>> Regards,
>>>>
>>>> Peng
>>>>
>>>> Peng Liu | 刘鹏
>>>> China Mobile | 移动研究院
>>>> mobile phone:13810146105
>>>> email: * liupengyjy@chinamobile.com <liupengyjy@chinamobile.com>*
>>>>
>>>>
>>>> 发件人: Qin Wu <bill.wu@huawei.com>
>>>> 时间: 2021/02/22(星期一)21:45
>>>> 收件人: IETF ALTO <alto@ietf.org>rg>;
>>>> 抄送人: alto-chairs <alto-chairs@ietf.org>;alto-ads <alto-ads@ietf.org>rg>;
>>>> 主题: [alto] ALTO Draft ReCharter WG review
>>>>
>>>> Hi, :
>>>>
>>>> We have requested one hour session for ALTO WG meeting in the upcoming
>>>> IETF 110, which is arranged on Friday, March 12, 14:30-15:30(UTC).
>>>>
>>>> The goal is to boil down ALTO recharter and have consensus on charter
>>>> contents in IETF 110.
>>>>
>>>> To get this goal, an updated inline draft charter text for ALTO has
>>>> just been posted to this list,
>>>>
>>>> This charter has received a couple of rounds of informal review from WG members, chairs and our Ads from brief to deep thorough, 5 new chartered items have been listed.
>>>>
>>>> We would like to solicit feedback on these new chartered items and your
>>>> use case, deployment, idea corresponding to these new chartered items.
>>>>
>>>> Sharing your past deployment story will also be appreciated.
>>>>
>>>>
>>>>
>>>>
>>>> ============================================================================================
>>>>
>>>> The ALTO working group was established in 2008 to devise a
>>>> request/response protocol to allow a host to benefit from a server that is
>>>> more cognizant of the network infrastructure than the host is.
>>>>
>>>>
>>>>
>>>> The working group has developed an HTTP-based protocol and recent work
>>>> has reported large-scale deployment of ALTO based solutions supporting
>>>> applications such as content distribution networks (CDN).
>>>>
>>>>
>>>>
>>>> ALTO is now proposed as a component for cloud-based interactive
>>>> applications, large-scale data analytics, multi-cloud SD-WAN deployment,
>>>> and distributed
>>>>
>>>> computing. In all these cases, exposing network information such as
>>>> abstract topologies and network function deployment location helps
>>>> applications.
>>>>
>>>>
>>>>
>>>> To support these emerging uses, extensions are needed, and additional
>>>> functional and architectural features need to be considered as follows:
>>>>
>>>>
>>>>
>>>> o Protocol extensions to support a richer and extensible set of policy
>>>> attributes in ALTO information update request and response. Such policy
>>>> attributes may indicate information dependency (e.g., ALTO path-cost/QoS
>>>> properties with dependency on real-time network  indications), optimization
>>>> criteria (e.g., lowest latency/throughput network performance objective),
>>>> and constraints (e.g., relaxation bound of optimization criteria, domain or
>>>> network node to be traversed, diversity and redundancy of paths).
>>>>
>>>>
>>>>
>>>> o Protocol extensions for facilitating operational automation tasks and
>>>> improving transport efficiency. In particular, extensions to provide
>>>> "pub/sub" mechanisms to allow the client to request and receive a diverse
>>>> types (such as event-triggered/sporadic, continuous), continuous,
>>>> customized feed of publisher-generated information. Efforts developed in
>>>> other working groups such as MQTT Publish / Subscribe Architecture, WebSub,
>>>> Subscription to YANG Notifications will be considered, and issues such as
>>>> scalability (e.g., using unicast or broadcast/multicast, and periodicity of
>>>> object updates) should be considered.
>>>>
>>>>
>>>>
>>>> o The working group will investigate the configuration, management, and
>>>> operation of ALTO systems and may develop suitable data models.
>>>>
>>>>
>>>>
>>>> o Extensions to ALTO services to support multi-domain settings. ALTO is
>>>> currently specified for a single ALTO server in a single administrative
>>>> domain, but a network may consist of
>>>>
>>>> multiple domains and the potential information sources may not be
>>>> limited to a certain domain. The working group will investigate extending
>>>> the ALTO framework to (1) specify multi-ALTO-server protocol flow and usage
>>>> guidelines when an ALTO service involves network paths spanning multiple
>>>> domains with multiple ALTO servers, and (2) extend or introduce ALTO
>>>>
>>>> services allowing east-west interfaces for multiple ALTO server
>>>> integration and collaboration. The specifications and extensions should use
>>>> existing services whenever possible. The specifications and extensions
>>>> should consider realistic complexities including incremental deployment,
>>>> dynamicity, and security issues such as access control, authorization
>>>> (e.g., an ALTO server provides information for a network that the server
>>>> has no authorization), and privacy protection in multi-domain settings.
>>>>
>>>>
>>>>
>>>> o The working group will update RFC 7971 to provide operational
>>>> considerations for recent protocol extensions (e.g., cost calendar, unified
>>>> properties, and path vector) and new extensions that the WG develops. New
>>>> considerations will include decisions about the set of information
>>>> resources (e.g., what metrics to use), notification of changes either in
>>>> proactive or reactive mode (e.g., pull the backend, or trigger just-in-time
>>>> measurements), aggregation/processing of the collected information  (e.g.,
>>>> compute information and network information )according to the clients’
>>>> requests, and integration with new transport mechanisms (e.g., HTTP/2 and
>>>> HTTP/3).
>>>>
>>>>
>>>>
>>>> When the WG considers standardizing information that the ALTO server
>>>> could provide, the following criteria are important
>>>>
>>>> to ensure real feasibility:
>>>>
>>>>
>>>>
>>>> - Can the ALTO server realistically provide (measure or derive) that
>>>> information?
>>>>
>>>>
>>>>
>>>> - Is it information that the ALTO client cannot find easily some other
>>>> way?
>>>>
>>>>
>>>>
>>>> - Is the distribution of the information allowed by the operator of the
>>>> network? Does the exposure of the information introduce privacy and
>>>> information leakage concerns?
>>>>
>>>>
>>>>
>>>> Issues related to the specific content exchanged in systems that make
>>>> use of ALTO are excluded from the WG's scope, as is the issue of
>>>> dealing with enforcing the legality of the content. The WG will also not
>>>> propose standards on how congestion is signaled, remediated, or avoided.
>>>>
>>>>
>>>>
>>>> -Qin Wu (on behalf of chairs)
>>>> _______________________________________________
>>>> alto mailing list
>>>> alto@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>>

-- 
Qiao Xiang
Associate Research Scientist,
Department of Computer Science,
Yale University