[alto] Pub/sub thread; Was Re: ALTO Draft ReCharter WG review

"Y. Richard Yang" <yry@cs.yale.edu> Wed, 10 March 2021 04:13 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 DE1C73A19FA; Tue, 9 Mar 2021 20:13:44 -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.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, URIBL_BLOCKED=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 iHb6u_q-1BIc; Tue, 9 Mar 2021 20:13:41 -0800 (PST)
Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (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 948953A19F7; Tue, 9 Mar 2021 20:13:40 -0800 (PST)
Received: by mail-lj1-f178.google.com with SMTP id e20so4691978ljn.6; Tue, 09 Mar 2021 20:13:40 -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=c/JGUVE/Ck4YAj+4H1JraYNfcoypVG5aJdZP/CDSkZw=; b=bw6j4qDsjzacHP6Yy7D4liPA2GObix+U7LVJNNBv3/J6zd3kBeF6xyKGxDjf8gJb0z avwIguWJ2NQxjLLGHT8+s3f5aEJmJCWlIgXdHJXYVFXskaZBUL6D4cP6rzhj3mVydS26 p8h3LnveNe9nzl0cpz4VmjC66j0LFBB4qzq17LQXEhDteyZxBBwPoEK19bFwD8avMGwb HEiIg0/W0lYFi3JXJUU+UX1XJk1zycSuWi8REkuuS5661EhYyDYDtzrOTlUhb/jbpBCW wxoUpqrBu+hgO5IqRDPypF6hzaduX631fW1iJXpywkzEzPNxEffDyCXcSnFCjY8O4nd2 vBQw==
X-Gm-Message-State: AOAM531ZAv7dNLJhC4wzd4zNshpv8W/Y0m/oIVf1ridrB3FY27zinI/3 OvrlgHzgVcb5hA8KWdi9zfKeAK+pPypnqgy4GAU=
X-Google-Smtp-Source: ABdhPJzE2RzLF4u8tfGgLQHY6nv2btgPpg1XbpyaXOzUByQb2p9+cFltRFp8k8xhXmRPnu3kvUksuROA6idPqwPldDU=
X-Received: by 2002:a2e:98c7:: with SMTP id s7mr644056ljj.276.1615349618608; Tue, 09 Mar 2021 20:13:38 -0800 (PST)
MIME-Version: 1.0
References: <B8F9A780D330094D99AF023C5877DABAADE47D21@dggeml511-mbs.china.huawei.com> <000601d713cc$f8112bd0$e8338370$@com>
In-Reply-To: <000601d713cc$f8112bd0$e8338370$@com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Tue, 9 Mar 2021 23:13:27 -0500
Message-ID: <CANUuoLr1YCeawcQsEWftcY1yP9F76itDZBZtDeWVtMfe28UMPg@mail.gmail.com>
To: Li Gang <ligangyf@chinamobile.com>
Cc: Qin Wu <bill.wu@huawei.com>, Kai Gao <kaigao@scu.edu.cn>, alto-chairs@ietf.org, alto-ads@ietf.org, IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000348ba805bd26e4cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/j-MgX_tDRt2MmHYDpes5HJrxPh0>
Subject: [alto] Pub/sub thread; Was Re: 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 04:13:45 -0000

Dear all,

I renamed the generic email Subject line so that we may focus this thread
on item 2.

Here are two quick comments related with this thread, and I will go to more
details as soon as I can.

1. ALTO SSE appears to be a quite useful service and it helps to adapt it
to use more modern transport such as HTTP/2, quic.

We may consider this under the sub/pub umbrella by considering the service
as a special sub/pub:
ALTO client can manage its subscription of network info to be pushed to it,
where the granularity of subscription is individual ALTO resource query; in
this model, the granularity can be quite fine-grained, depending on the
query granularity. Hence, if we want fine-grained subscriptions, we can
introduce these queries and leave the push/incremental encoding
mechanism/framework alone.

2. Can we clarify more on the sub/pub use cases? A typical use case of a
sub/pub system C is to facilitate the communication of other entities such
as A and B. Hence, if the ALTO server is C, then who are the A and B? I can
think of use cases where clients, for example, in a mobility/weakly
connected setting, are A and B. Or the use case is about developing C, and
the A and B are ALTO client/server. It helps to clarify.

Richard

On Sun, Mar 7, 2021 at 10:42 PM Li Gang <ligangyf@chinamobile.com> wrote:

> Hi, Qin,
>
> Please see my reply inline.
>
>
>
> Li Gang
>
>
>
> *From:* Qin Wu [mailto:bill.wu@huawei.com]
> *Sent:* Monday, March 8, 2021 10:52 AM
> *To:* Li Gang; kaigao@scu.edu.cn
> *Cc:* alto-chairs@ietf.org; alto-ads@ietf.org; 'IETF ALTO'
> *Subject:* RE: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi, Gang:
>
> Thanks for sharing your use case, let me rephrase what you envision for
> your use case,
>
> You want to express QoS requirement in the subscription request, the
> network exposes the network information via notification in response to
> subscription request,
>
> application operators can tune adaptive rate to improve user QoE based on
> the network information change.
>
>
>
> [Gang]: yes
>
>
>
> Can you clarify a little bit about specific application traffic patterns?
>
>
>
> [Gang]: let me take video streaming as an example, normally the downlink
> streaming content would be segmented into pieces for `10 seconds. For each
> piece, multiple video encoding rates, for example 1080p, 720p …, can be
> provided and adjusted by server. For each encoding rate, the QoS
> requirement (e.g. throughput, latency) is different. The network can
> provide such information change  (e.g. whether QoS requirement for 1080p,
> 720p is fulfilled or not) via pub/sub, which help application operator tune
> encoding rate.
>
>
>
> Secondly, I agree fine granularity pub sub can consider one time
> subscription and configure wait time as subscription policy to alleviate
> the signaling load on the network.
>
>
>
> -Qin
>
> *发件人:* Li Gang [mailto:ligangyf@chinamobile.com]
> *发送时间:* 2021年3月7日 16:30
> *收件人:* kaigao@scu.edu.cn; Qin Wu <bill.wu@huawei.com>
> *抄送:* alto-chairs@ietf.org; alto-ads@ietf.org; 'IETF ALTO' <alto@ietf.org>
> *主题:* RE: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi, Kai and Qin,
>
>
>
> Thanks for triggering the discussion on  the 2nd item of the recharter
> text.
>
> I agree that it would be better to define a generic pub/sub framework
> irrespective of specific transport protocol.
>
> We can start with a simple pub/sub mechanism, which is driven by concrete
> use cases and then consider to extend as needed.
>
>
>
> Some of my thoughts are inline.
>
>
>
> Li Gang
>
>
>
> *From:* alto [mailto:alto-bounces@ietf.org <alto-bounces@ietf.org>] *On
> Behalf Of *kaigao@scu.edu.cn
> *Sent:* Friday, March 5, 2021 11:03 AM
> *To:* Qin Wu
> *Cc:* alto-chairs@ietf.org; alto-ads@ietf.org; IETF ALTO
> *Subject:* Re: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi Qin,
>
> Thanks for the comments. A quick summary of my response is
>
> 1. "Pub/sub" means different things in different contexts and I think we
> must clarify what it means in the context of distributing ALTO information.
>
> 2. There are two ways of realizing complex "pub/sub" of ALTO information
> but I think they are fundamentally different deployment settings for one
> generic framework (whose details are, unfortunately, not thought through
> yet).
>
> Please see the details inline.
>
> Best,
>
> Kai
>
> -----Original Messages-----
> *From:*"Qin Wu" <bill.wu@huawei.com>
> *Sent Time:*2021-03-04 22:21:06 (Thursday)
> *To:* "kaigao@scu.edu.cn" <kaigao@scu.edu.cn>
> *Cc:* "alto-chairs@ietf.org" <alto-chairs@ietf.org>rg>, "alto-ads@ietf.org" <
> alto-ads@ietf.org>gt;, "IETF ALTO" <alto@ietf.org>
> *Subject:* Re: [alto] ALTO Draft ReCharter WG review
>
> Kai:
>
> *发件人:* kaigao@scu.edu.cn [mailto:kaigao@scu.edu.cn <kaigao@scu.edu.cn>]
> *发送时间:* 2021年3月3日 21:40
> *收件人:* Qin Wu <bill.wu@huawei.com>
> *抄送:* IETF ALTO <alto@ietf.org>rg>; alto-chairs@ietf.org; alto-ads@ietf.org
> *主题:* Re: [alto] ALTO Draft ReCharter WG review
>
>
>
> Dear all,
>
>  Below are some comments on the 2nd item in the recharter text.
>
> As far as I know, the ALTO incremental update extension (RFC 8895) already
> provides a mechanism to enable the "pub-sub" of ALTO information, using
> Server-Sent Events (SSE). I see there are multiple directions indicated by
> the new charter item:
>
> [Qin]: Thanks for clarifying the difference between SSE and pub sub
> proposed in the new proposed charter item.
>
> 1. Decouple the "pub-sub" protocol with the underlying mechanism.
>
> Besides SSE, other mechanisms can also be used to realize the "pub-sub" of
> ALTO information, such as HTTP/2, HTTP/3 or the methods mentioned in the
> charter text. Thus, a direct extension is to define the abstract format of
> control messages and data messages (i.e., WHAT information should be
> provided but not HOW), and allow different underlying protocols to use
> protocol-specific encodings.
>
> For example, SSE encodes the metadata (e.g., content-type and stream id)
> and the content of an event using "event:" and "data:" prefixes at the
> beginning of each line, and uses empty lines to indicate the end of a
> message, while HTTP/2 (RFC 7540) may encode the metadata and the content of
> an event using PUSH_PROMISE/HEADERS and DATA frame .
>
> [Qin]: Good analysis, I think we need to decide whether we should define
> generic pub sub mechanism or transport specific pub sub mechanism. Do you
> have any suggestion on this?
>
> [KAI]: I think the generic pub-sub mechanism (or maybe the term framework
> is more appropriate) is more important at this point, which should also
> cover the direction of providing more fine-grained control. One thing that
> just strikes me after taking a quick look at rabbitMQ is that "pub/sub"
> means different things in different contexts. It is important we understand
> what are the requirements of generic pub/sub in the ALTO framework.
>
> [KAI]: When we discuss "pub/sub" with SSE and HTTP/2, which is a
> one-to-one client-server communication, the focus of the "pub/sub" here is
> simple: what are the messages and how the client can control the subscribed
> information. However, with message queues (e.g., rabbitMQ), the
> communication pattern may be more complex: a message can be sent to
> multiple queues without knowing exactly who is subscribing. I see two ways
> to realize the more complex "pub/sub" requirement for ALTO information.
>
> rabbitMQ: https://www.rabbitmq.com/tutorials/tutorial-three-python.html
>
> [KAI]: CASE A: First, the client application may deploy its own "pub/sub"
> system, and the ALTO client simply serves as a producer by forwarding the
> ALTO messages to the "pub/sub" system. In this way, the problem is reduced
> to the one-to-one "pub/sub" problem.
>
> [KAI]: CASE B: Second, ALTO servers may natively support the "pub/sub" of
> ALTO information. In this case, an ALTO server may need to handle events
> such as join/leave of clients that subscribe to the same ALTO information.
> For example, for a client that just subscribes to a network map, the server
> should send the whole map instead of incremental updates.
>
> [KAI]: Both approaches have pros and cons. The first is simple on the
> server side but may be less efficient (because of triangle routing) and
> complex on the client side (client must handle data consistency to support
> dynamic subscribers). I think the generic framework should contain two
> aspects:
>
> [KAI] 1. Control of ALTO information: a server-client protocol which is
> similar to RFC 8895 but maybe with some extended capabilities.
>
> [KAI] 2. Distribution of ALTO information: a MQ-like protocol that
> controls how the ALTO information can be efficiently and consistently
> delivered to subscribers.
>
> [KAI] I think the connection between these two aspects is a logical entity
> called ALTO Exchange (following the term used by rabbitMQ). This entity can
> be operated by an application provider (as in CASE A) or by a network
> operator (as in CASE B). However, the detailed responsibilities of this
> entity may still need some investigation.
>
> I think this requirement may help integrating ALTO in network management
> platforms (such as OpenDaylight, Kubernetes, and ETSI ZSM*) which design
> their own pub-sub systems for reasons such as consistency or ease of
> development. It would be great if there is an interest in this direction
> from companies/organizations.
>
> [Qin]: I can see The 3GPP has defined a Service-Based Architecture (SBA),
> whereby the control plane functionality and common data repositories of a
> 5G network are delivered by way of a set of interconnected Network
> Functions (NFs),pub sub mechanism has been well adopted in 3GPP interface.
>
> Also in the public cloud, popular pub/sub implementations has been widely
> deployed,e.g., rabbitMQ (AMQP), mosquitto (MQTT), ejabberd (XMPP), and
> ZeroMQ. We also see many pub sub mechanism or extension has been developed
> in IETF, e.g., YANG Push, draft-ietf-dots-telemetry,
> draft-ietf-ace-mqtt-tls-profile.
>
> * The integration fabric of ETSI ZSM provides pub-sub support but ZSM also
> allows services to use their own pub-sub mechanisms.
>
> 2. Enable more fine-grained control of pub-sub.
>
> In RFC 8895, there are two types of commands which only defines WHAT
> information to subscribe:
>
> - add: Make one or more new requests to receive the incremental updates.
>
> - remove: Terminate the subscription of one or more previously-made
> requests.
>
> In the meantime, the updates will be continuously sent to the client
> whenever a server sees fit.
>
> The charter text proposes to enable ALTO clients to request and receive "a
> diverse types (such as event-triggered/sporadic, continuous), continuous,
> customized feed of publisher-generated information". It seems to me that
> the new extension wants to allow clients to specify not only WHAT
> information to be subscribed but also WHEN/HOW the information should be
> delivered (e.g., Notify me the latest value every 5 second.).
>
> [Qin]:Good point, I think fine grained control of pub-sub allows not only
> periodical subscription, but also on demand subscription, which is the
> missing piece in the existing SSE incremental update.
>
> [Gang]: I think WHAT/WHEN/HOW should all be considered for pub/sub.
> Specifically, after one time subscription, notification may be one time,
> multiple times based on either event triggering or periodic reporting.
> Besides that, in order to reduce signaling overhead, maybe minimum wait
> time can be defined between consecutive pub messages.
>
> Personally I find both directions to be interesting and useful. It would
> be great if they can be supported by real use cases.
>
> [Gang]: I also agree that the necessary extension should be well supported
> by concrete use cases. I’d like share some thoughts on use cases in my
> mind: some application operators would like to subscribe the QoS
> requirements(maybe one or a list)for their specific application traffic
> patterns to the network operators, the network can provide notification
> whether/how the network would fulfill their requirements, so that
> application operators can perform adaptive rate control to improve user QoE.
>
> Just my two cents.
>
> Best,
>
> Kai
>
> -----Original Messages-----
> *From:*"Qin Wu" <bill.wu@huawei.com>
> *Sent Time:*2021-02-22 21:50:44 (Monday)
> *To:* "IETF ALTO" <alto@ietf.org>
> *Cc:* "alto-chairs@ietf.org" <alto-chairs@ietf.org>rg>, "alto-ads@ietf.org" <
> alto-ads@ietf.org>
> *Subject:* [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