Hi Gang and Qin,
I am also interested in the details of the use case. Like I mentioned, ALTO
already has an extension (RFC 8895) that allows one-to-one pub/sub, it would be
useful if the use case can show that the current design, despite that it is
built on top of SSE, is not enough to support similar common use cases. My
guess is that there are some synchronization requirements that the subscribers
are intended to make decisions based on the same ALTO information? So aside
from Qin's question on the traffic pattern, it would be wonderful if the use
case can illustrate the distribution of ALTO information.
I am also a bit confused about what one-time subscription means here. Is it
one-time for a single subscriber or multiple subscribers? If for a single
subscriber, I do not see why the subscriber would make the same subscription
many times. It would wonderful if we can clarify this in the use case.
Best,
Kai
-----Original Messages-----
From:"Qin Wu" <bill...@huawei.com>
Sent Time:2021-03-08 10:51:31 (Monday)
To: "Li Gang" <ligan...@chinamobile.com>, "kai...@scu.edu.cn"
<kai...@scu.edu.cn>
Cc: "alto-cha...@ietf.org" <alto-cha...@ietf.org>, "alto-...@ietf.org"
<alto-...@ietf.org>, "'IETF ALTO'" <alto@ietf.org>
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.
Can you clarify a little bit about specific application traffic patterns?
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:ligan...@chinamobile.com]
发送时间: 2021年3月7日 16:30
收件人: kai...@scu.edu.cn; Qin Wu <bill...@huawei.com>
抄送: alto-cha...@ietf.org; alto-...@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-boun...@ietf.org] On Behalf Of kai...@scu.edu.cn
Sent: Friday, March 5, 2021 11:03 AM
To: Qin Wu
Cc:alto-cha...@ietf.org; alto-...@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...@huawei.com>
Sent Time:2021-03-04 22:21:06 (Thursday)
To: "kai...@scu.edu.cn" <kai...@scu.edu.cn>
Cc: "alto-cha...@ietf.org" <alto-cha...@ietf.org>, "alto-...@ietf.org"
<alto-...@ietf.org>, "IETF ALTO" <alto@ietf.org>
Subject: Re: [alto] ALTO Draft ReCharter WG review
Kai:
发件人:kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2021年3月3日 21:40
收件人: Qin Wu <bill...@huawei.com>
抄送: IETF ALTO <alto@ietf.org>; alto-cha...@ietf.org; alto-...@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 use 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...@huawei.com>
Sent Time:2021-02-22 21:50:44 (Monday)
To: "IETF ALTO" <alto@ietf.org>
Cc: "alto-cha...@ietf.org" <alto-cha...@ietf.org>, "alto-...@ietf.org"
<alto-...@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
