Re: [alto] ALTO Draft ReCharter WG review

"Y. Richard Yang" <yry@cs.yale.edu> Mon, 01 March 2021 23:36 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 79DA13A2500 for <alto@ietfa.amsl.com>; Mon, 1 Mar 2021 15:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.268
X-Spam-Level:
X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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, URI_DOTEDU=0.132] 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 vlm3j0DOetbo for <alto@ietfa.amsl.com>; Mon, 1 Mar 2021 15:36:29 -0800 (PST)
Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 5E5943A24FE for <alto@ietf.org>; Mon, 1 Mar 2021 15:36:29 -0800 (PST)
Received: by mail-lj1-f173.google.com with SMTP id r23so21631007ljh.1 for <alto@ietf.org>; Mon, 01 Mar 2021 15:36:29 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=puHvvAL8ezAiRWB7NsH4QTySsvyKRQNvhsmf0lcjIUk=; b=i6lxrPlKVG1wABSJwFY1V012N5eAy4fF5cYr2KfGFSDlIE7vUkD68TJZyx+XVpzfKS tgGpG76BDFvgttVWYPm6o+pfObKUQJk7rSrNp9Az/hYHvBE3ViGdM7DLK7IZjlgLOv1A ZkOBdRibyihoWNXu9+XKB/pZREASOPn680cSwtk+2Z4ADjST3TFRsRqCqHsEjhlmY99T QO+kOM9MSY1uejb/BOzqpxL40DL7kSehKN0YlNLdoo8rlnrhztcxuygZtHYAlxeVbrhE K9TuAgYz8UevZ72CPgK87de0OIitkS4KNXUnMdTWKsMPTMErw180AQ8nscjmMweordsW lS3g==
X-Gm-Message-State: AOAM530uuoHZPdEG+TamLEVQQU0NANwAZnrOcS7kMz9ZEnQudthHdcDL sBRDXPeuGgZBmhbQjuRpmSDlUS2IkwZ2m9F32LA=
X-Google-Smtp-Source: ABdhPJwpX5Tg5mirAAJueaQV9QvGprTqbq7EsN08EzxNL6986+mVE/R/0+N4knKIizV44nk73m5NQMJptkRgvR+4b0w=
X-Received: by 2002:a2e:9952:: with SMTP id r18mr10302698ljj.180.1614641787526; Mon, 01 Mar 2021 15:36:27 -0800 (PST)
MIME-Version: 1.0
References: <2021022710231490898215@chinamobile.com>
In-Reply-To: <2021022710231490898215@chinamobile.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Mon, 1 Mar 2021 18:36:16 -0500
Message-ID: <CANUuoLpedg5kmEDgqd_TBF0ZqQW1hT7JD6gGLr+VbmD2WECU2Q@mail.gmail.com>
To: =?UTF-8?B?5YiY6bmP?= <liupengyjy@chinamobile.com>
Cc: IETF ALTO <alto@ietf.org>, Qin Wu <bill.wu@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000002f627205bc821681"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/r7-aUiy6t7QPzEvZjxN2JkVxYNo>
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: Mon, 01 Mar 2021 23:36:32 -0000

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?

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.

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
>


-- 
-- 
 =====================================
| Y. Richard Yang <yry@cs.yale.edu>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================