[alto] qoRE: Pub/sub thread; Was Re: ALTO Draft ReCharter WG review(Internet mail)

[熊春山]

Hello all,

There are a lot of interesting discussion on the “pub/sub” related use cases 
and mechanisms.

Here I want to provide some use cases on how the “pub/sub” needs to support:


1) One sub/pub for different bitrates :

e.g.  the alto client can subscribe the alto server to get 5G network current 
supporting bitrates as :

a) bigger than  A kbps;

b) less than A but bigger than B;

c) less than B;

where A>B, e.g. A is for 1080p video streaming, B is for 720p streaming,

of course, we can introduce more different bitrates span, but for simple, only 
3 are defined in the example.



In such case the alto server will pub(notify) the alto client the current 5G 
network bitrates when the bitrates span is changed (not the bitrates are 
changed, only after the bitrate changed into different bitrate span).



It is each to above bitrates to latency.





2) Normally, the smart UE-client and cloud Server application can use the 
adaptive bitrate changes to handle the network bitrate changes as above, but 
there are still a lot of chances that the client applicant temporary halts to 
wait the downlink data in the cloud gaming. Because in some case the bitrates 
of the 5G RAN change very quicky and steeply in a short time and the ALTO 
server can not in time to provide such information to the alto client.

In order to handle such steeply and quickly bitrate changes in the wireless 
system, a new sub/pub use case is needed as below.



The alto client can subscribe the ALTO server to notify the Quick QoS Change. 
E.g. if the bitrate decreases/increases  30% (e.g. changes +- 30%) （ or 
decreases/increases  A kbps） in a short time ，the alto serve shall notify the 
alto client very quickly and emergently.

(Normally, if the bitrates changes  up and down very quickly but the average 
bitrate are not changed, it is not considered as the QUICK QOS Change. The 
QUICK QoS Change means the bitrates are changed quickly and steeply in short 
time and keeps the new bitrates  after the QUICK change).



With such QUICK QoS Change sub/pub, the cloud gaming server can real-time to 
get the 5G network bitrates big changes and quickly use the adaptive encoding 
scheme.




What is the differences between the above 1) and 2) ?
Normally the 1) needs the alto client to provides the bitrates spans to the 
alto server and 5G network , and 5G network or the alto server  needs to 
compare its current bitrates with the provided bitrate span. But for the 2) the 
alto client does not provide any defined bitrate values, it only provides the 
bitrate change ratio or change values to the alto server and 5G, then the 5G 
network or the alto server needs to compare the bitrate changes and notify the 
alto client.

1) is well defined in 3GPP for 5G standards, but this method is used only 
for the Guaranteed QoS Flow (currently, the Guaranteed  QoS Flow is used by is 
not used very widely, currently it is only used by the operator’s HD Voice 
(i.e. Voice Over LTE/5G, i.e. Voice over IMS) service ); 2) can be used by the 
Guaranteed QoS Flow and non-Guaranteed QoS Flow (the Non Guaranteed QoS Flow is 
widely used by the internet applications ). We/Tencent are going to study the 
2) and try to find out how much QoE improvement based on this Quick QoS Change. 
We/Tencent also are planning to push 3GPP 5G to study this Quick QoS Change 
standards in Release 18.



BRs,
Chunshan Xiong

From: alto  On Behalf Of Y. Richard Yang
Sent: Wednesday, March 10, 2021 12:13 PM
To: Li Gang 
Cc: alto-cha...@ietf.org; alto-...@ietf.org; Kai Gao ; Qin 
Wu ; IETF ALTO 
Subject: [alto] Pub/sub thread; Was Re: ALTO Draft ReCharter WG review(Internet 
mail)

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 

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

[Y. Richard Yang]

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  wrote:

> Hi, Qin,
>
> Please see my reply inline.
>
>
>
> Li Gang
>
>
>
> *From:* Qin Wu [mailto:bill...@huawei.com]
> *Sent:* Monday, March 8, 2021 10:52 AM
> *To:* Li Gang; kai...@scu.edu.cn
> *Cc:* alto-cha...@ietf.org; alto-...@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:ligan...@chinamobile.com]
> *发送时间:* 2021年3月7日 16:30
> *收件人:* kai...@scu.edu.cn; Qin Wu 
> *抄送:* alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 
> *主题:* 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" 
> *Sent Time:*2021-03-04 22:21:06 (Thursday)
> *To:* "kai...@scu.edu.cn" 
> *Cc:* "alto-cha...@ietf.org" , "alto-...@ietf.org" <
> alto-...@ietf.org>, "IETF ALTO" 
> *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 
> *抄送:* IETF ALTO ; 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 

Re: [alto] ALTO Draft ReCharter WG review

[Y. Richard Yang]

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  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 

[alto] ALTO Recharter discussion on Friday 12th of March 2nd Session

[Qin Wu]

Hi All,
We request one hour session in upcoming IETF 110 to discuss ALTO Recharter 
proposal. The goal is to focus on network aware application, explore
ALTO as component for cloud-based interactive applications, large-scale data 
analytics, multi-cloud SD-WAN deployment, and
distributed computing application.

The ALTO session is scheduled on Friday, 12th of March, 2nd session 
(15:30-16:30 UTC, 10:30~11:30 Beijing Time,10:30-11:30 EST).
The meeting agenda is available at:
https://datatracker.ietf.org/doc/agenda-110-alto/

The charter proposal is available at:
https://mailarchive.ietf.org/arch/msg/alto/FxRoRoesddhOhgkYhzQOyHjghPc/

I would like to invite you to join this meeting and hear your feedback and 
input to ALTO recharter proposal. Thanks in advance.

-Qin (on behalf of chairs)
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] SIGCOMM'21 NAI Workshop

[Qin Wu]

Richard:
Network-Application Integration is an interesting and important topic which can 
help us better understand pain points from both application provider and 
network provider today, gap in their implementation or deployment practice.
I also see network application integration as network as a service which help 
integrate both overlay and underlay.
I can envision we have many Network application integration related work and 
efforts in IETF which is literally scattered around in different working group, 
or IETF areas.  This workshop seem a good opportunity for them to
get together to share their story and lessons.
Would it be great and valuable to circulate this NAI Sigcomm workshop news to 
other interested Working Group such as PANRG, NMRG, CDNI, MOPS, CONRG, etc.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Y. Richard Yang
发送时间: 2021年3月9日 10:24
收件人: IETF ALTO ; alto-weekly-meet...@googlegroups.com
主题: [alto] SIGCOMM'21 NAI Workshop

Dear all,

FYI: Our proposal for the second ACM SIGCOMM NAI Workshop during ACM SIGCOMM'21 
has been accepted. Please do consider submission to this highly relevant venue.


Call for Submissions: ACM SIGCOMM NAI’21
The Second ACM SIGCOMM Workshop on Network-Application Integration/CoDesign 
(NAI)

The Internet was designed and launched 50 years ago to satisfy yet unforeseen 
applications, and the Internet's adaptation and scalability have been proved 
remarkably successful over the years. However, the general-purpose and 
best-effort model of the Internet continues to be challenged with an 
ever-growing demand for more complex applications with stricter 
application-specific requirements. How can we deliver 4k videos to everybody? 
How can we ensure ultra-low latency for applications such as self-driving cars 
and cloud gaming? How do applications adapt when the underlying infrastructure 
cannot provide the services such as reliability or security?

The Second ACM SIGCOMM Workshop on Network-Application Integration/CoDesign 
(NAI) seeks to build on the success of the first workshop 
(https://conferences.sigcomm.org/sigcomm/2020/workshop-nai.html) and continue 
to foster discussions on this topic. We invite researchers from academia and 
industry as well as engineers to explore novel ideas and future directions of 
NAI.

See https://conferences.sigcomm.org/sigcomm/2021/workshop-nai.html and submit 
papers and posters at https://nai21.hotcrp.com/. Please direct any questions to 
the workshop chairs at sigcomm21...@gmail.com.

Submission deadline: May 17, 2021
Notification deadline: June 14, 2021
Workshop: August 23-27 (TBD), 2021
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto