From nobody Wed Mar 3 07:33:22 2021 Return-Path: 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 7656B3A14E4 for ; Wed, 3 Mar 2021 07:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_FROM=0.001, HTML_MESSAGE=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 xJrN8qGIB_VX for ; Wed, 3 Mar 2021 07:33:18 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 15FE73A14E0 for ; Wed, 3 Mar 2021 07:33:18 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id e10so23906502wro.12 for ; Wed, 03 Mar 2021 07:33:17 -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=4ka/m6WNz9pZKA6m9stupPloJNDvL10afNq4guf0q/k=; b=vV2G0h5+VpVeIY0/zldrAekie2xTFjR93jPJEkfYyNMxIn5WYiPxnFUPGDoO7BEgZW ich9JoZzAWd/sKMp8WvQWkXZn4NN5YyoSyhzYr5LN6Tb+Tv4SEN8XTz8lpBl7LL3qvI1 FqEXbsHOnphlexTPW7q+yHzHEo0drTB8/q2vZ9JC+BuZFVUatRANkt5nF1Mc76/nTg/U 6efAhIoq0IK8yg+UgycccmjgWxrN8DQnjeHQIWANUayVlq32LZWzReG5E4edh/eXJiQq q5nAFTSE2Gc+bndr8egxkh2vNx1z63EzjNCJhuEWEyAaozP4pnKUT8vvhSsJPJbcBG5v DZwA== 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=4ka/m6WNz9pZKA6m9stupPloJNDvL10afNq4guf0q/k=; b=qkyrUdMyyPX7l7AhX9cG5oM9lRlKcJc/Q64OePV9A+pBEsBS8TSmQYTGRutHUzWU5r qs96mxpyYrkXTLI6D996fv0nC5XihWQRgIUvg7qHIVWHiObQDGjFbGO55KfC18YsKsGG 36FViGJBp7OAZ/GgTeUrMwzaMUV0IL5jLgFhRCBsIawN2hMfpD/GI3DoiEfFs4RJT2ir dyaZlfBvKKPy1edJUtHRJNkY4NwWAur4uLqnNRZH2V5RL1tnLJv6mQwEfrHbTjO8CjFs cL6ebUJKRyiNv6tfjUACOM1ukqdZAyw555ahQ+z1V0uWsFXo2zFjjGQgxoimAf4WT24Y 79Ww== X-Gm-Message-State: AOAM530qk2YXTxPyC6UYi5+pZVLvjiJgOUyWzou2/OBieT+zlAxM/Sb+ Ri7WJ+GCI6deP6E/k+B0pwT4lynL9QI00s0855w= X-Google-Smtp-Source: ABdhPJwzPK23eAoseqMIvG6pJwduK2H0kcRK5YeNJmN/oNwyqJs13GjHDg/uTeRllw92HRetXPiu2VOXb/C6akCGKEc= X-Received: by 2002:a05:6000:24b:: with SMTP id m11mr20104254wrz.393.1614785596355; Wed, 03 Mar 2021 07:33:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jensen Zhang Date: Wed, 3 Mar 2021 23:33:06 +0800 Message-ID: To: Qin Wu Cc: IETF ALTO Content-Type: multipart/alternative; boundary="000000000000dbf94f05bca391a7" Archived-At: Subject: Re: [alto] ALTO Draft ReCharter WG review -- ALTO Data Model X-BeenThere: alto@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 15:33:21 -0000 --000000000000dbf94f05bca391a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I would like to make some comments on the 3rd recharter item. This item is going to propose YANG data models for ALTO configuration and management. Most of this kind of YANG data models for communication protocols like PCEP [1] and HTTP [2] will support both client and server configuration. One of the open issues for ALTO is: *whether we should also provide the data model for the ALTO client configuration*. For some of the traditional ALTO use cases like p2p, I think the YANG data model only for the ALTO server is enough. It can help the network operator easily configure and manage ALTO services. The data model for the ALTO client may not be necessary because the client is usually not under the control of the network operator. However, there are two cases where people may be interested in the data model for the ALTO client: 1. The multi-domain setting is a potential use case. But it depends on how we are going to design the server-to-server communication. (a) If we are going to reuse the current ALTO framework, then the architecture could be similar to the PCE-based architecture, i.e., each ALTO domain should initiate an entity that can be an alto-server, alto-client, or alto-server-and-client. And for the alto-client or alto-server-and-client entity, the operator could configure the list of peered alto-server/alto-server-and-client entity directly, or how to discover the peers. The operator could also configure which information the client entity is interested in and would like to fetch from the peers. (b) If we are going to completely redesign the communication protocol among ALTO servers, we may need specific data models for the configuration of this new protocol. The traditional roles of the ALTO client and server may no longer be applicable. 2. The other use case could come from the network-application integration. More specifically, the multi-service operator (e.g., Comcast, Telefonica) who can offer both application service (e.g., TV, CDN) and network service can be an example. In such a case, the application service operator may have some collaboration with the network operator on the protocol configuration level. For example, in a CDN-ISP collaboration setting (@Luis can comment on it), the CDN operator may request the network operator to install a new ALTO service to compute on-demand ALTO information resources based on new parameters dynamically. And in the meantime, the CDN operator may also configure its own ALTO client to periodically send requests to the new ALTO service or use the pub/sub mechanism (e.g. SSE). And the CDN operator may want the ALTO client to report some operational status/statistics like when the last request is done, whether the last response is out-dated, how many versions are updated for the current information resource (Not quite sure if this info should be in the scope of the ALTO data model). It makes more sense to do these kinds of things via the configuration protocol instead of another ALTO protocol extension. It would be great if people can share further comments or their own interesting use cases. [1] https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15 [2] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06 Best regards, Jensen On Mon, Feb 22, 2021 at 9:51 PM Qin Wu wrote: > 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 m= embers, chairs and our Ads from brief to deep thorough, 5 new chartered ite= ms 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. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The ALTO working group was established in 2008 to devise a > request/response protocol to allow a host to benefit from a server that i= s > more cognizant of the network infrastructure than the host is. > > > > The working group has developed an HTTP-based protocol and recent work ha= s > 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), optimizati= on > 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, WebSu= b, > 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 ALT= O > 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 u= se > 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, unifi= ed > 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-ti= me > measurements), aggregation/processing of the collected information (e.g.= , > compute information and network information )according to the clients=E2= =80=99 > requests, and integration with new transport mechanisms (e.g., HTTP/2 and > HTTP/3). > > > > When the WG considers standardizing information that the ALTO server coul= d > 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 wa= y? > > > > - 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 > --000000000000dbf94f05bca391a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I would like= to make some comments on the 3rd recharter item.

= This item is going to propose YANG data models for ALTO configuration and m= anagement. Most of this kind of YANG data models for communication protocol= s like PCEP [1] and HTTP [2] will support both client and server configurat= ion. One of the open issues for ALTO is:

whether we should also provide the data model for the ALTO client configur= ation.

For some of the traditional ALTO use ca= ses like p2p, I think the YANG data model only for the ALTO server is enoug= h. It can=C2=A0help the network operator easily configure and manage ALTO s= ervices. The data model for the ALTO client may not be necessary because th= e client is usually not under the control of the network operator. However,= there are two cases where people may be interested in the data model for t= he ALTO client:

1. The multi-domain setting is a p= otential use case. But it depends on how we are going to design the server-= to-server communication.

=C2=A0 (a) If we are goin= g to reuse the current ALTO framework, then the architecture could be simil= ar to the PCE-based architecture, i.e., each ALTO domain should initiate an= entity that can be an alto-server, alto-client, or alto-server-and-client.= And for the alto-client or alto-server-and-client entity, the operator cou= ld configure the list of peered alto-server/alto-server-and-client entity d= irectly, or how to discover the peers. The operator could also configure wh= ich information the client entity is interested in and would like to fetch = from the peers.

=C2=A0 (b) If we are going to comp= letely redesign the communication protocol among ALTO servers, we may need = specific data models for the configuration of this new protocol. The tradit= ional roles of the ALTO client and server may no longer be applicable.

2. The other use case could come from the network-appl= ication integration. More specifically, the multi-service operator (e.g., C= omcast, Telefonica) who can offer both application service (e.g., TV, CDN) = and network service can be an example. In such a case, the application serv= ice operator may have some collaboration with the network operator on the p= rotocol configuration level.=C2=A0

=C2=A0 For exam= ple, in a CDN-ISP collaboration setting (@Luis can comment on it), the CDN = operator may request the network operator to install a new ALTO service to = compute on-demand ALTO information resources based on new parameters dynami= cally. And in the meantime, the CDN operator may also configure its own ALT= O client to periodically send requests to the new ALTO service or use the p= ub/sub mechanism (e.g. SSE). And the CDN operator may want the ALTO client = to report some operational status/statistics like when the last request is = done, whether the last response is out-dated, how many versions are updated= for the current information resource (Not quite=C2=A0sure if this info sho= uld be in the scope of the ALTO data model). It makes more sense to do thes= e kinds of things via the configuration protocol instead of another ALTO pr= otocol extension.

It would be great if people = can share further comments or their own interesting use cases.

On Mon, Feb 22, 2021 at 9:51 PM Q= in Wu <bill.wu@huawei.com> = wrote:

= 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 conte= nts in IETF 110.

= To get this goal, an updated inline draft charter text for ALTO has just be= en posted to this list, 

This charter has r=
eceived a couple of rounds of informal review from WG members, chairs and o=
ur 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.<= /span>

=C2=A0=

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

The ALTO working group was = established in 2008 to devise a request/response protocol to allow a host t= o benefit from a server that is more cognizant of the network infrastructure than the host is.

=C2=A0=

The working group has devel= oped an HTTP-based protocol and recent work has reported large-scale deploy= ment of ALTO based solutions supporting applications such as content distribution networks (CDN).

=C2=A0=

ALTO is now proposed as a c= omponent for cloud-based interactive applications, large-scale data analyti= cs, multi-cloud SD-WAN deployment, and distributed

computing. In all these cas= es, exposing network information such as abstract topologies and network fu= nction deployment location helps applications.

=C2=A0=

To support these emerging u= ses, extensions are needed, and additional functional and architectural fea= tures need to be considered as follows:

=C2=A0=

o Protocol extensions to su= pport 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 w= ith dependency on real-time network=C2=A0 indications), optimization criter= ia (e.g., lowest latency/throughput network performance objective), and con= straints (e.g., relaxation bound of optimization criteria, domain or network node to be traversed, diversity and redundancy= of paths).

=C2=A0=

o Protocol extensions for f= acilitating 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 (suc= h 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 considere= d, and issues such as scalability (e.g., using unicast or broadcast/multica= st, and periodicity of object updates) should be considered.

=C2=A0=

o The working group will in= vestigate the configuration, management, and operation of ALTO systems and = may develop suitable data models.

=C2=A0=

o Extensions to ALTO servic= es to support multi-domain settings. ALTO is currently specified for a sing= le ALTO server in a single administrative domain, but a network may consist of

multiple domains and the po= tential information sources may not be limited to a certain domain. The wor= king group will investigate extending the ALTO framework to (1) specify multi-ALTO-server protocol flow and usage guideli= nes when an ALTO service involves network paths spanning multiple domains w= ith multiple ALTO servers, and (2) extend or introduce ALTO

services allowing east-west= interfaces for multiple ALTO server integration and collaboration. The spe= cifications and extensions should use existing services whenever possible. The specifications and extensions should consi= der realistic complexities including incremental deployment, dynamicity, an= d security issues such as access control, authorization (e.g., an ALTO serv= er provides information for a network that the server has no authorization), and privacy protection in multi-dom= ain settings.

=C2=A0=

o The working group will up= date RFC 7971 to provide operational considerations for recent protocol ext= ensions (e.g., cost calendar, unified properties, and path vector) and new extensions that the WG develops. New consideratio= ns will include decisions about the set of information resources (e.g., wha= t 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 collecte= d information=C2=A0 (e.g., compute information and network information )acc= ording to the clients=E2=80=99 requests, and integration with new transport= mechanisms (e.g., HTTP/2 and HTTP/3).

=C2=A0=

When the WG considers stand= ardizing information that the ALTO server could provide, the following crit= eria are important

to ensure real feasibility:=

=C2=A0=

- Can the ALTO server reali= stically provide (measure or derive) that information?=

=C2=A0=

- Is it information that th= e ALTO client cannot find easily some other way?

=C2=A0=

- Is the distribution of th= e information allowed by the operator of the network? Does the exposure of = the information introduce privacy and information leakage concerns?

=C2=A0=

Issues related to the speci= fic content exchanged in systems that make use of ALTO are excluded from th= e WG's scope, as is the issue of dealing w= ith enforcing the legality of the content. The WG will also not propose standards on how congestion is signaled, remediated,= or avoided.

=C2=A0

-Qin Wu (on behalf of chair= s)

_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
--000000000000dbf94f05bca391a7--