Re: [alto] ALTO Draft ReCharter WG review

[Qin Wu]

Thanks for your clarification, I think 1080p and 720p are resolution, 
corresponding to HD, SD video, or 4.5Mbit/s, 2.5 Mbit/s bit rate if you are 
using H.264 encoding scheme.
Have you considered to use VP8 encoding scheme?

-Qin
发件人: Li Gang [mailto:ligan...@chinamobile.com]
发送时间: 2021年3月8日 11:42
收件人: Qin Wu ; kai...@scu.edu.cn
抄送: alto-cha...@ietf.org; alto-...@ietf.org; 'IETF ALTO' 
主题: RE: [alto] ALTO Draft ReCharter WG review

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 
mailto:bill...@huawei.com>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org; 'IETF ALTO' 
mailto: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" mailto:bill...@huawei.com>>
Sent Time:2021-03-04 22:21:06 (Thursday)
To: "kai...@scu.edu.cn" 
mailto:kai...@scu.edu.cn>>
Cc: "alto-cha...@ietf.org" 
mailto:alto-cha...@ietf.org>>, 
"alto-...@ietf.org" 
mailto:alto-...@ietf.org>>, "IETF ALTO" 
mailto: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 mailto:bill...@huawei.com>>
抄送: IETF ALTO mailto: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 d

Re: [alto] ALTO Draft ReCharter WG review

[Jensen Zhang]

Hi Qin,

See my comments inline.

On Mon, Mar 8, 2021 at 11:21 AM Qin Wu  wrote:

> Hi, Jensen and Qian:
>
> Thanks for your clarification, , the interesting paper [2] you share,
>
> I am wondering how ALTO server in your implementation get network info
> from BGP in each domain?
>

In our implementation, the ALTO server doesn't get network info from the
BGP/SFP speaker. Each domain runs OpenFlow to do the intra-domain routing.
And the ALTO server gets intra-domain network info from the OpenFlow
controller in each domain. The SFP speaker in each domain provides another
service to allow the application to request the inter-domain routing. We
also inject a delegation service into the ALTO server to delegate such
requests to the SFP speaker. But it doesn't follow any existing ALTO
specification.


> Do you configure ALTO server in each domain for consistent Cost Metric
> reporting? What if each ALTO server report different Cost metric in the
> multi-domain setting?
>

Yes, we enforce each domain to deploy the same ALTO server implementation
and configure the consistent cost metric reporting. The inconsistent cost
metric reporting was not in the scope of our previous work. But personally,
if ALTO servers report different cost metrics, I think one potential
solution is to design a negotiation mechanism similar to the ethernet link
connection negotiation before the client does any ALTO queries.

Thanks,
Jensen


>
>
> -Qin
>
> *发件人:* Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com]
> *发送时间:* 2021年3月5日 10:26
> *收件人:* Qiao Xiang 
> *抄送:* Qin Wu ; 刘鹏 ; IETF
> ALTO 
> *主题:* Re: [alto] ALTO Draft ReCharter WG review
>
>
>
> Hi Qin and Qiao,
>
> Please see my comments inline.
>
>
>
> On Thu, Mar 4, 2021 at 11:57 PM Qiao Xiang  wrote:
>
> Hi Qin,
>
>
>
> Thank you so much for the feedback. Please see my responses inline.
>
>
>
> On Thu, Mar 4, 2021 at 9:22 PM Qin Wu  wrote:
>
> Thanks Qiao for sharing your project on Unicorn and thought on
> multi-domain setting.
>
> My impression in your implementation is each domain name and first ingress
> node in such domain will be carried in the ALTO response message.
>
> First, for domain name, I do not believe we need that in the ALTO response
> message. Our setting here is each domain has an ALTO server, and the ALTO
> clients at the aggregator have separate connections to different ALTO
> servers. In this way, by maintaining a (domain, ALTO  server) mapping, the
> aggregator can differentiate responses from different domains.
>
>
>
> Right, our implementation didn't carry each domain name in the ALTO
> message. The current ALTO protocol cannot carry on this info. And we also
> didn't do such an extension to ALTO. We just use a centralized aggregator
> (which can be considered as an ALTO client) to coordinate with the ALTO
> server of each domain. There is no communication between any two ALTO
> servers. The domain name may appear in the configuration message.
>
>
>
> Second, for ingress node, the client needs to specify the ingress and the
> (srcIP, dstIP) pair in the query first so that the ALTO server knows what
> information to return. And I should also clarify that although we use
> ODL-ALTO for our system, but the path vector extension is not implemented
> exactly following the specification since it was not fully stabilized then.
>
>
>
> Yes, and the ingress info only appears in the request message, not in the
> response message. We use the early design of the FCS extension [1] to do
> this. The request message should specify the flow-id of each flow.
>
>
>
> [1] https://tools.ietf.org/html/draft-gao-alto-fcs-04
>
>
>
>
>
> @Jensen is the core developer and can comment further on this, as well as
> the ODL implementation.
>
>
>
> One thing I want to highlight is
>
> Unicorn has already been deployed in several cities of USA in 2018 and
> implemented in the ODL open source.
>
> I should clarify that this deployment is pre-production, and the
> demonstration scenario is at SC18 and SC19, where we are at the conference
> cities (Dallas and Denver), and orchestrate traffic from there back to a
> Caltech LHC site (we manually separate this site into two domains to create
> a 3-domain scenario for demonstration purpose.)
>
>
>
> Quote from
> https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/
>
> “
>
>The authors build an ALTO server on top of the OpenDaylight Software
>
>Defined Network controller.  The ALTO server collects the network
>
>state information from the OpenDaylight controller, e.g., topology,
>
>policy and traffic statistics, processes the collected information
>
>into resource abstraction, and sends the abstraction back to the ALTO
>
>client at the resource orchestrator.
>
>
>
> The Unicorn framework has been deployed and
>
>demonstrated in small federation networks connecting Dallas, Texas,
>
>Los Angles, California, and Denver, Colorado at different
>
>conventions.  For example, in 2018, the federation 

Re: [alto] ALTO Draft ReCharter WG review

[Li Gang]

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" 
, "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 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 
thing

Re: [alto] ALTO Draft ReCharter WG review

[Qin Wu]

Hi, Jensen and Qian:
Thanks for your clarification, , the interesting paper [2] you share,
I am wondering how ALTO server in your implementation get network info from BGP 
in each domain?
Do you configure ALTO server in each domain for consistent Cost Metric 
reporting? What if each ALTO server report different Cost metric in the 
multi-domain setting?

-Qin
发件人: Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com]
发送时间: 2021年3月5日 10:26
收件人: Qiao Xiang 
抄送: Qin Wu ; 刘鹏 ; IETF ALTO 

主题: Re: [alto] ALTO Draft ReCharter WG review

Hi Qin and Qiao,
Please see my comments inline.

On Thu, Mar 4, 2021 at 11:57 PM Qiao Xiang 
mailto:xiang...@gmail.com>> wrote:
Hi Qin,

Thank you so much for the feedback. Please see my responses inline.

On Thu, Mar 4, 2021 at 9:22 PM Qin Wu 
mailto:bill...@huawei.com>> wrote:
Thanks Qiao for sharing your project on Unicorn and thought on multi-domain 
setting.
My impression in your implementation is each domain name and first ingress node 
in such domain will be carried in the ALTO response message.
First, for domain name, I do not believe we need that in the ALTO response 
message. Our setting here is each domain has an ALTO server, and the ALTO 
clients at the aggregator have separate connections to different ALTO servers. 
In this way, by maintaining a (domain, ALTO  server) mapping, the aggregator 
can differentiate responses from different domains.

Right, our implementation didn't carry each domain name in the ALTO message. 
The current ALTO protocol cannot carry on this info. And we also didn't do such 
an extension to ALTO. We just use a centralized aggregator (which can be 
considered as an ALTO client) to coordinate with the ALTO server of each 
domain. There is no communication between any two ALTO servers. The domain name 
may appear in the configuration message.

Second, for ingress node, the client needs to specify the ingress and the 
(srcIP, dstIP) pair in the query first so that the ALTO server knows what 
information to return. And I should also clarify that although we use ODL-ALTO 
for our system, but the path vector extension is not implemented exactly 
following the specification since it was not fully stabilized then.

Yes, and the ingress info only appears in the request message, not in the 
response message. We use the early design of the FCS extension [1] to do this. 
The request message should specify the flow-id of each flow.

[1] https://tools.ietf.org/html/draft-gao-alto-fcs-04


@Jensen is the core developer and can comment further on this, as well as the 
ODL implementation.

One thing I want to highlight is
Unicorn has already been deployed in several cities of USA in 2018 and 
implemented in the ODL open source.
I should clarify that this deployment is pre-production, and the demonstration 
scenario is at SC18 and SC19, where we are at the conference cities (Dallas and 
Denver), and orchestrate traffic from there back to a Caltech LHC site (we 
manually separate this site into two domains to create a 3-domain scenario for 
demonstration purpose.)

Quote from 
https://datatracker.ietf.org/doc/draft-xiang-alto-multidomain-analytics/
“
   The authors build an ALTO server on top of the OpenDaylight Software
   Defined Network controller.  The ALTO server collects the network
   state information from the OpenDaylight controller, e.g., topology,
   policy and traffic statistics, processes the collected information
   into resource abstraction, and sends the abstraction back to the ALTO
   client at the resource orchestrator.

The Unicorn framework has been deployed and
   demonstrated in small federation networks connecting Dallas, Texas,
   Los Angles, California, and Denver, Colorado at different
   conventions.  For example, in 2018, the federation in the
   demonstration is composed of three member networks.  Network 1 is in
   Dallas, Texas, and Network 2 and network 3 are in Los Angeles,
   California.  Network 1 is connected to network 2 through a layer-2
   WAN circuit with a 100 Gbps bandwidth, provisioned by several
   providers such as SCinet, CenturyLink and CENIC.  Network 1 is a
   temporal science network in the CMS experiment, while network 2 and 3
   are long-running CMS Tier-2 sites.
”
I believe your case require server to server communication for end-to-end 
interdomain routing.

Yes, the server-to-server communication for the e2e interdomain routing is 
helpful. However, we didn't use/extend ALTO to do this in our deployment. We 
used SFP (a BGP extension) [2] to do this. So any ALTO servers didn't 
communicate with each other. The limitation is that we must assume the ALTO 
server of each domain can provide consistent cost metrics.

[2] "SFP: Toward Interdomain Routing for SDN Networks", SIGCOMM 2018 Poster 
(https://dl.acm.org/doi/10.1145/3234200.3234207)

Thanks,
Jensen


Secondly, as for network information exposure in multi-domain setting, I think
1. 3GPP Network Exposure Function is a good example for network information 
exposu

Re: [alto] ALTO Draft ReCharter WG review

[Qin Wu]

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 
抄送: 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" mailto:bill...@huawei.com>>
Sent Time:2021-03-04 22:21:06 (Thursday)
To: "kai...@scu.edu.cn" 
mailto:kai...@scu.edu.cn>>
Cc: "alto-cha...@ietf.org" 
mailto:alto-cha...@ietf.org>>, 
"alto-...@ietf.org" 
mailto:alto-...@ietf.org>>, "IETF ALTO" 
mailto: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 mailto:bill...@huawei.com>>
抄送: IETF ALTO mailto: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 messag

Re: [alto] ALTO Draft ReCharter WG review

[Li Gang]

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" 
, "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 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 informatio