Subject: [Dyncast] CAN BoF issues and the next steps

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Apr 2022 14:36:04 +0800

Dear all,

Thanks for supporting and joining the CAN work.  We can see that the BoF was successful and had a good discussion, and almost everyone agree on the use case that considering more metrics for steering traffic is valuable and a right direction. https://notes.ietf.org/notes-ietf-113-can. 

Here we list the issues according to BoF talking and give the preliminary answers to them, which could be found at https://github.com/CAN-IETF/CAN-BoF-ietf113/issues. If missing any issue, please let us know and we could add it. The issues will continue to be iterated and then closed.

Moreover, we will update the key drafts according to the BoF talking and further thinking. If you have the interests, please feel free to contact us. 

Regards,
Peng

[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Apr 2022 08:41:56 -0400

Please do not overstate the situation.
I do not think that "almost everyone agreed" to anything in that BoF.
And in particular, I do not think that "almost everyone agreed" to the 
value for additional metrics.

Yours,
Joel

On 4/11/2022 2:36 AM, [email-masked] wrote:
> Dear all,
> 
> Thanks for supporting and joining the CAN work.  We can see that the BoF 
> was successful and had a good discussion, and almost everyone agree on 
> the use case that considering more metrics for steering traffic is 
> valuable and a right direction. 
> https://notes.ietf.org/notes-ietf-113-can 
> <https://notes.ietf.org/notes-ietf-113-can>.
> 
> Here we list the issues according to BoF talking and give the 
> preliminary answers to them, which could be found at 
> https://github.com/CAN-IETF/CAN-BoF-ietf113/issues 
> <https://github.com/CAN-IETF/CAN-BoF-ietf113/issues>. If missing any 
> issue, please let us know and we could add it. The issues will continue 
> to be iterated and then closed.
> 
> Moreover, we will update the key drafts according to the BoF talking and 
> further thinking. If you have the interests, please feel free to contact 
> us.
> 
> Regards,
> Peng
> 
> ------------------------------------------------------------------------

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Apr 2022 22:30:48 +0800

Dear Joel,

Sorry, more accurately, we didn't hear any objections on the use case. 

We are eager to hear any issues with the use cases presented. We would appreciate it very much if you can elaborate issues you have with the use case.

Regards,
Peng

From: Joel M. Halpern
Date: 2022-04-11 20:41
To: [email-masked]; dyncast
Subject: Re: [Dyncast] CAN BoF issues and the next steps
Please do not overstate the situation.
I do not think that "almost everyone agreed" to anything in that BoF.
And in particular, I do not think that "almost everyone agreed" to the 
value for additional metrics.
 
Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Apr 2022 10:35:35 -0400

I believe I was very clear during the BoF.  I have not seen a persuasive 
case for why we need to use the underlay routing system to address the 
problem of enabling communication between end user applications and edge 
located compute services.

There are multiple ways to improve the application situation without 
burdening the underlay routing with something it does not care about.

Yours,
Joel

On 4/11/2022 10:30 AM, [email-masked] wrote:
> We are eager to hear any issues with the use cases presented. We would 
> appreciate it very much if you can elaborate issues you have with the 
> use case.
> 
> Regards,
> Peng
>     *From:* Joel M. Halpern <mailto:[email-masked]>
>     *Date:* 2022-04-11 20:41
>     *To:* [email-masked]
>     <mailto:[email-masked]>; dyncast <mailto:[email-masked]>
>     *Subject:* Re: [Dyncast] CAN BoF issues and the next steps

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 11 Apr 2022 14:39:57 +0000

Joel,

Indeed, there was a clear message (from what I recall from the chat comments) towards thinking of the realization of such capability in relation to the underlay and particular the routing system. 

From my side, I don't see the need to place this into the underlay as a given, while the question to realize a compute-aware on-path endpoint selection decision may well be of interest. Is that a fair statement?

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: 11 April 2022 16:36
To: [email-masked]; dyncast <[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

I believe I was very clear during the BoF.  I have not seen a persuasive case for why we need to use the underlay routing system to address the problem of enabling communication between end user applications and edge located compute services.

There are multiple ways to improve the application situation without burdening the underlay routing with something it does not care about.

Yours,
Joel

--
Dyncast mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dyncast

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 11 Apr 2022 14:42:46 +0000

I agree.
Thanks,
Acee

On 4/11/22, 10:36 AM, "Dyncast on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    Yours,
    Joel

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 12 Apr 2022 10:18:05 +0800

Hi, Joel:
I think we all agree that the user want to better E2E application performance. 
The underlay network has invented various tools to achieve such aims within its boundary, for example, various TE solutions, Segment Routing, Flexalgo etc, and more metrics(link bandwidth, link delay, link color etc.) are considered and added into the SPF calculations.

But, with the placement of the ANYCAST application servers closing to the users in different sites, the bottleneck to influence the E2E application performance is not only the network metric, the metric for the application servers play a major role now.
It is time to consider both the network metric and application server metric together to achieve such goals.

There are already existing similar approaches, for example, LB based solution. But as analyzed during the BoF meeting, to solve the above problem, LB based solution will also dive into one similar signaling protocol and SPF calculation process.
Then, I think we should analyze what's the main concerns to let router do such more clever selection and find the solution to mitigate the influences.

Best Regards

Aijun Wang
China Telecom   

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Monday, April 11, 2022 10:36 PM
To: [email-masked]; dyncast <[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Yours,
Joel

---

From: Luigi IANNONE <[email-masked]>
Date: Tue, 12 Apr 2022 07:04:24 +0000

Hi,

> But, with the placement of the ANYCAST application servers closing to the
> users in different sites, the bottleneck to influence the E2E application
> performance is not only the network metric, the metric for the application
> servers play a major role now.

I think that Joel is not against the above (routing metric +compute metric = instance selection).
I think that he is more inline with Dirk's position, meaning that it is not necessarily the routing layer that has to be "enhanced" with compute metrics. 
Rather, an in-path decision based on both metrics should be made by some (CAN ) element.
My personal take is that the ingress is well suited for that (since for sure it is in-path).    
Then you have the choice of various ways on how to steer the traffic.

Ciao

L.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 12 Apr 2022 16:11:46 +0800

Hi,
 
I agree that multiple solutions exist here. Some of them do not need to change the routing layer, and work in a higher level.
 
However, in some scenarios, maybe the solution in the routing layer is more efficient. There are some tradeoffs here.
 
IMHO, the main object of the BOF is to clarify that sometimes, we need to consider both the network status and the computing status, and make a better choice in the traffic steering. 
 
Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Luigi IANNONE
Date: 2022-04-12 15:04
To: Aijun Wang; 'Joel M. Halpern'; [email-masked]; 'dyncast'
Subject: Re: [Dyncast] CAN BoF issues and the next steps
Hi,

 
Ciao
 
L.

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 13 Apr 2022 10:52:31 +0800

Hi, Luigi:
Why only the ingress need such decision? I think all the routers in-path
need such information(routing metric +compute metric), to achieve the
optimal "instance selection".

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Luigi
IANNONE
Sent: Tuesday, April 12, 2022 3:04 PM
To: Aijun Wang <[email-masked]>; 'Joel M. Halpern'
<[email-masked]>; [email-masked]; 'dyncast'
<[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi,

> But, with the placement of the ANYCAST application servers closing to 
> the users in different sites, the bottleneck to influence the E2E 
> application performance is not only the network metric, the metric for 
> the application servers play a major role now.

I think that Joel is not against the above (routing metric +compute metric =
instance selection).
I think that he is more inline with Dirk's position, meaning that it is not
necessarily the routing layer that has to be "enhanced" with compute
metrics. 
Rather, an in-path decision based on both metrics should be made by some
(CAN ) element.
My personal take is that the ingress is well suited for that (since for sure
it is in-path).    
Then you have the choice of various ways on how to steer the traffic.

Ciao

L.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Apr 2022 22:54:51 -0400

If the ingress edge does the calculation, makes the determination, and 
tunnels the traffic to the right place then the underlay routing system 
does not need to know anything about these metrics or the decision 
processes made by the edge.

Yours,
Joel

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 13 Apr 2022 10:59:24 +0800

Hi, Joel:
If you use binding address behind the ANYCAST address, it is possible. But if you use the ANYCAST address directly, you can't.
For my understanding, the latter scenario is more popular.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Wednesday, April 13, 2022 10:55 AM
To: Aijun Wang <[email-masked]>; 'Luigi IANNONE' <luigi.iannone=[email-masked]>; [email-masked]; 'dyncast' <[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

If the ingress edge does the calculation, makes the determination, and tunnels the traffic to the right place then the underlay routing system does not need to know anything about these metrics or the decision processes made by the edge.

Yours,
Joel

On 4/12/2022 10:52 PM, Aijun Wang wrote:
> Hi, Luigi:
> Why only the ingress need such decision? I think all the routers 
> in-path need such information(routing metric +compute metric), to 
> achieve the optimal "instance selection".
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> From: [email-masked] <[email-masked]> On Behalf Of 
> Luigi IANNONE
>> application performance is not only the network metric, the metric 
>> for the application servers play a major role now.
> I think that he is more inline with Dirk's position, meaning that it 
> is not necessarily the routing layer that has to be "enhanced" with 
> compute metrics.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Apr 2022 11:07:31 +0800

Hi Aijun,

Yes, there is a mapping of binding address and anycast address in the current dyncast architecture.

Regards,
Peng

[email-masked]
 
From: Aijun Wang
Date: 2022-04-13 10:59
To: 'Joel M. Halpern'; 'Luigi IANNONE'; [email-masked]; 'dyncast'
Subject: Re: [Dyncast] CAN BoF issues and the next steps
Hi, Joel:
If you use binding address behind the ANYCAST address, it is possible. But if you use the ANYCAST address directly, you can't.
For my understanding, the latter scenario is more popular.

Best Regards
 
Aijun Wang
China Telecom
 
-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Wednesday, April 13, 2022 10:55 AM
To: Aijun Wang <[email-masked]>; 'Luigi IANNONE' <luigi.iannone=[email-masked]>; [email-masked]; 'dyncast' <[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Apr 2022 11:14:35 +0800

Hi, Aijun
 
    If we can tunnel the anycast traffic in the bearing network, which is a normal process for the IP/MPLS network, the middle nodes in the underlay network do not need to know the route for the anycast address.

Best Regards
Zongpeng Du

From: Aijun Wang
Date: 2022-04-13 10:59

Best Regards
 
Aijun Wang
China Telecom
 
-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Wednesday, April 13, 2022 10:55 AM
To: Aijun Wang <[email-masked]>; 'Luigi IANNONE' <luigi.iannone=[email-masked]>; [email-masked]; 'dyncast' <[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 12 Apr 2022 23:19:56 -0400

We are defining how the system will operate.  There is no "more popular" 
that we are trying to support.

Also, even if anycast is used by the end stations, the ingress and 
egress can still tunnel using proper unicast address to keep the routing 
system from becoming complicated with things it does not care about.

Yours,
Joel

PS: Personally, I like an approach even one step more drastic.  Have the 
host talk to a service to determine what application instance it should 
talk to, and use unicast between them.  But I am not insisting on that.

---

From: Tony Li <[email-masked]>
Date: Tue, 12 Apr 2022 20:27:56 -0700

Hi Aijun,

My understanding of the requirements was that a particular UE was supposed to be bound to a server for the lifetime of a ’transaction’ and that includes across the UE rehoming to a different source. Thus, the entire network needs to make a consistent and fixed decision per UE. Doing so in a dynamic environment would seem to be most challenging: you would need to synchronize forwarding state across the entire network instantly.

Making a single decision at the ingress and propagating that state seems somewhat easier.

And easier still is Joel’s proposal: have the UE pick one (from a centralized broker?) and then rely on unicast. :-)

Regards,
T

> On Apr 12, 2022, at 7:59 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Joel:

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Apr 2022 11:59:30 +0800

Hi Tony,

I think CAN has it's own worked scope of the network and considers the frequency of synchronization at same time.

The method of UE to pick the instance from the broker is simple but thought to cause more messages and latency compared to the in-path solution, and need the broker to learn all the network status. 

Regards,
Peng

From: Tony Li
Date: 2022-04-13 11:27
To: Aijun Wang
CC: dyncast; liupengyjy; Luigi IANNONE
Subject: Re: [Dyncast] CAN BoF issues and the next steps
 
Hi Aijun,

 
 
Regards,
T

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Apr 2022 12:15:01 +0800

Hi, Tony, Aijun, Joel:

    Multiple solutions exist here. But I suggest that we do not maintain per UE status in the Ingress.

A general procedure is as following:
1、 A client tries to access the service by using the anycast address 
2、 The Ingress makes a decision which server to connect, and tunnels the anycast packet to the specific Egress
3、   The Egress forwards the anycast packet to the specific server, which can provide the service
4、 After the connection is established, the UE can communicate with the server by using the unicast address.

From: Tony Li
Date: 2022-04-13 11:27
To: Aijun Wang
 
Hi Aijun,

 
 
Regards,
T

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 13 Apr 2022 06:05:33 +0000

All,

Responding to the various aspects in a single response:

1.      @all: we are working on an update to the arch draft, which will hopefully make the ingress-based service instance selection architecture (ISISA, quite a mouthful) clearer.

a.      This shows that the ingress is the decision point

b.      With it, the intermediary routing nodes need no knowledge of the selection process (or its data)

c.      With it, we hopefully clarify that the process is one of service instance selection (hence the longish name), not path selection. For the latter, the routing policies applied to steer traffic to the binding IP will be used.

d.      Other clarifications will hopefully also improve the document

2.      @Tony,Joel: the use case document (problems with existing solutions) already mentions client-based selection. There are a number of issues with this, which hopefully a clearer gap analysis (still discussing how to capture such analysis) will shed light on. But yes, it is an option which we have recognized.

3.      @Tony: there are two aspects of mobility, namely that of a client moving and, possibly, that of a service instance ‘moving’. The approaches to both are different. It is to be seen/decided, if we want to include the mobility aspect (if so, which ones) into the scope of work.

I hope this clarifies albeit in forward-reference to a to-be-updated draft.

Best,

Dirk

From: Dyncast [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 13 April 2022 06:15
To: Tony Li <[email-masked]>; Aijun Wang <[email-masked]>; Halpern' <[email-masked]>
Cc: [email-masked]; Peng Liu <[email-masked]>; Luigi IANNONE <luigi.iannone=[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi, Tony, Aijun, Joel:

________________________________
[email-masked]<mailto:[email-masked]> & [email-masked]<mailto:[email-masked]>

From: Tony Li<mailto:[email-masked]>
Date: 2022-04-13 11:27
To: Aijun Wang<mailto:[email-masked]>
CC: dyncast<mailto:[email-masked]>; liupengyjy<mailto:[email-masked]>; Luigi IANNONE<mailto:luigi.iannone=[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi Aijun,

Regards,
T

> On Apr 12, 2022, at 7:59 PM, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi, Joel:
> From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Luigi IANNONE' <luigi.iannone=[email-masked]<mailto:luigi.iannone=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'dyncast' <[email-masked]<mailto:[email-masked]>>
>> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of
>> Luigi IANNONE
>> To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Joel M. Halpern'
>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'dyncast'
>> <[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
Dyncast mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dyncast

---

From: Tony Li <[email-masked]>
Date: Tue, 12 Apr 2022 23:17:24 -0700

Hi duzongpeng,

I suggest that we need to agree on the requirements, because we are pretty clearly not on the same page.

T

> On Apr 12, 2022, at 9:15 PM, [email-masked] wrote:
> 
> Hi, Tony, Aijun, Joel:
> 
> [email-masked] <mailto:[email-masked]> & [email-masked]
>  
> From: Tony Li <mailto:[email-masked]>
> Date: 2022-04-13 11:27
> To: Aijun Wang <mailto:[email-masked]>
> CC: dyncast <mailto:[email-masked]>; liupengyjy <mailto:[email-masked]>; Luigi IANNONE <mailto:luigi.iannone=[email-masked]>

---

From: Tony Li <[email-masked]>
Date: Tue, 12 Apr 2022 23:19:24 -0700

Hi Peng,

> The method of UE to pick the instance from the broker is simple but thought to cause more messages and latency compared to the in-path solution, and need the broker to learn all the network status. 

If minimizing messaging and latency are design requirements, then that needs to be justified somehow.

Tony

---

From: Luigi IANNONE <[email-masked]>
Date: Wed, 13 Apr 2022 06:52:30 +0000

Hi Aijun,

> 
> Hi, Luigi:
> Why only the ingress need such decision? I think all the routers in-path need
> such information(routing metric +compute metric), to achieve the optimal
> "instance selection".

Not necessarily. If a tunnel/overlay is used only ingress and egress must be aware of the selection.

Ciao

L.

---

From: Jens Finkhaeuser <[email-masked]>
Date: Wed, 13 Apr 2022 09:07:24 +0000

Hi all,

speaking from practical experience with the edge case of streaming video from the "best" source, it may be desirable for the UA to make the decision locally, as it's also best suited to deciding if a response no longer matters.

We'd query a central repository for likely sources with some compute aware ordering, and then use path aware ordering at the UA for narrowing down the candidate list.

In our use case, we would query all sources, update their ordering on actual RTT, and send ACK equivalents to all, independent of which source provided each packet.

This list then periodically got refreshed.

This could conceivably be done by the ingress, use unicast for all sources, etc. but it would need some transparency. That is, E2EE would likely place this at the UA rather than an ingress router.

The point here is probably that it's likely best to differentiate between where the path aware and the compute aware metrics get aggregated and evaluated, at least for some types of application.

Hope that makes sense,
Jens

\-------- Original Message --------
On 13 Apr 2022, 05:27, Tony Li < [email-masked]> wrote:

> > To: Aijun Wang <[email-masked]>; 'Luigi IANNONE' <luigi.iannone=[40huawei.com][]@dmarc.ietf.org>; [email-masked]; 'dyncast' <[email-masked]>
> > Subject: Re: \[Dyncast\] CAN BoF issues and the next steps
> >
> >> Subject: Re: \[Dyncast\] CAN BoF issues and the next steps
> >>
> >> Hi,
> >>
> \--

[40huawei.com]: http://40huawei.com

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Apr 2022 17:58:45 +0800

Hi, Jens

    It is a choice about the decision point, and it leads to different solutions. The decision point may be the UE, the Ingress node, some centralized point (such as a controller), etc.

    If the UE is that smart, it can choose the proper server after knowing the needed information.
    If the Ingress node can handle the anycast/Dyncast job, the UE can be less complicated.
    Or a controller can give a suggestion about the selected path and/or the selected server to the UE or Ingress node.

    Some tradeoff needs to be considered here, and perhaps they have different suitable scenarios.

Best Regards
Zongpeng Du

From: Jens Finkhaeuser
Date: 2022-04-13 17:07
To: tony.li; wangaijun
CC: dyncast; liupengyjy; luigi.iannone=40huawei.com
Subject: Re: [Dyncast] CAN BoF issues and the next steps
Hi all,

Hope that makes sense,
Jens

-------- Original Message --------

Hi Aijun,

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Apr 2022 18:22:28 +0800

Hi Tony,

Thanks, may not minimizing but compared to be a better choice for some use cases which also depends on the requirements. 

We will add more analysis in the drafts of next version.

Regards,
Peng

From: Tony Li
Date: 2022-04-13 14:19
To: liupengyjy
CC: Aijun Wang; dyncast; Luigi IANNONE
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi Peng,

Tony

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 Apr 2022 16:47:38 +0000

Tony,

Are you saying that it is important to have the use cases to “justify the need of minimizing messaging and latency”?

Thanks, Linda

From: Dyncast <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, April 13, 2022 1:19 AM
To: [email-masked]
Cc: dyncast <[email-masked]>; Aijun Wang <[email-masked]>; Luigi IANNONE <luigi.iannone=[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi Peng,

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 13 Apr 2022 10:04:08 -0700

Hi Linda,

> Are you saying that it is important to have the use cases to “justify the need of minimizing messaging and latency”?

Not necessarily in the use cases, but if there’s a requirement beyond good engineering that we avoid an extra message or 1ms of latency, we need to know about it and would like to understand why.

If there are boundaries on the solution space, they should be clear to all, up front.

Tony

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 Apr 2022 18:07:13 +0000

Tony,

Thank you very much for the clarification. I added your concern to the issues list.

Linda

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, April 13, 2022 12:04 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; dyncast <[email-masked]>; Aijun Wang <[email-masked]>; Luigi IANNONE <luigi.iannone=[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi Linda,

Tony

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 Apr 2022 18:24:23 +0000

Jen,

Does the "UA" mean "User Application" ?

So your solution requires the applications on the UE  to query the "Central Repository"?
When a UE roam from one Cell tower to another in the middle of the communication, does your solution require the Application on the UE to periodically query the "Central Repository" to select the optimal path to the "Source"?

Thank you
Linda

From: Dyncast <[email-masked]> On Behalf Of Jens Finkhaeuser
Sent: Wednesday, April 13, 2022 4:07 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; luigi.iannone=[email-masked]
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi all,

Hope that makes sense,
Jens

-------- Original Message --------
On 13 Apr 2022, 05:27, Tony Li < [email-masked]<mailto:[email-masked]>> wrote:

Hi Aijun,

My understanding of the requirements was that a particular UE was supposed to be bound to a server for the lifetime of a 'transaction' and that includes across the UE rehoming to a different source. Thus, the entire network needs to make a consistent and fixed decision per UE. Doing so in a dynamic environment would seem to be most challenging: you would need to synchronize forwarding state across the entire network instantly.

And easier still is Joel's proposal: have the UE pick one (from a centralized broker?) and then rely on unicast. :-)

Regards,
T

> To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Luigi IANNONE' <luigi.iannone=40huawei.com<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40huawei.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TinZa%2FzGye5Be5QpPp5SIKVO9HNopgrB2IHeTTfiOFE%3D&reserved=0>@dmarc.ietf.org>; [email-masked]<mailto:[email-masked]>; 'dyncast' <[email-masked]<mailto:[email-masked]>>
>> https://www.ietf.org/mailman/listinfo/dyncast<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserved=0>
>>
>
> --
> Dyncast mailing list
> https://www.ietf.org/mailman/listinfo/dyncast<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserved=0>

--
Dyncast mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dyncast<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserved=0>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 Apr 2022 18:28:54 +0000

Dirk,

Thank you very much for summarize the changes to be made.

Just curious, what scenario will cause  “a service instance ‘moving’ “ (described in your our bullet 3)?

Thank you.
Linda

From: Dyncast <[email-masked]> On Behalf Of Dirk Trossen
Sent: Wednesday, April 13, 2022 1:06 AM
To: [email-masked]; Tony Li <[email-masked]>; Aijun Wang <[email-masked]>; Halpern' <[email-masked]>
Cc: [email-masked]; Peng Liu <[email-masked]>; Luigi IANNONE <luigi.iannone=[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

All,

  1.  @all: we are working on an update to the arch draft, which will hopefully make the ingress-based service instance selection architecture (ISISA, quite a mouthful) clearer.
     *   This shows that the ingress is the decision point
     *   With it, the intermediary routing nodes need no knowledge of the selection process (or its data)
     *   With it, we hopefully clarify that the process is one of service instance selection (hence the longish name), not path selection. For the latter, the routing policies applied to steer traffic to the binding IP will be used.
     *   Other clarifications will hopefully also improve the document
  2.  @Tony,Joel: the use case document (problems with existing solutions) already mentions client-based selection. There are a number of issues with this, which hopefully a clearer gap analysis (still discussing how to capture such analysis) will shed light on. But yes, it is an option which we have recognized.
  3.  @Tony: there are two aspects of mobility, namely that of a client moving and, possibly, that of a service instance ‘moving’. The approaches to both are different. It is to be seen/decided, if we want to include the mobility aspect (if so, which ones) into the scope of work.

Best,

Dirk

From: Dyncast [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 13 April 2022 06:15
To: Tony Li <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Halpern' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Peng Liu <[email-masked]<mailto:[email-masked]>>; Luigi IANNONE <luigi.iannone=[email-masked]<mailto:luigi.iannone=[email-masked]>>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi, Tony, Aijun, Joel:

Hi Aijun,

Regards,
T

>> https://www.ietf.org/mailman/listinfo/dyncast<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C2316b87121144e63032808da1d13a8ac%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854267552749777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3ImCiAZTZ66XhEeXPoI51xC%2B%2BpONA3IJLtVNQmS4avo%3D&reserved=0>
>>
>
> --
> Dyncast mailing list
> https://www.ietf.org/mailman/listinfo/dyncast<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C2316b87121144e63032808da1d13a8ac%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854267552749777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3ImCiAZTZ66XhEeXPoI51xC%2B%2BpONA3IJLtVNQmS4avo%3D&reserved=0>

--
Dyncast mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dyncast<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C2316b87121144e63032808da1d13a8ac%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854267552749777%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3ImCiAZTZ66XhEeXPoI51xC%2B%2BpONA3IJLtVNQmS4avo%3D&reserved=0>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Apr 2022 15:30:44 -0400

With regard to the specific case of a UE / UA moving to a different cell 
tower or region, this is in fact one of the advantages of handling this 
at the application.  Given that the ongoing application exchange has 
state at the server, you do NOT want to suddenly shift the client to a 
different server.  As a setp one on mobility, you want to keep using the 
same server.  Using the server unicast address from the UE / UA makes 
that work seemlessly.

If we want reoptimization then the application can ask the dispatcher, 
and in the event a move is desired, ask the server to move the 
application state to the new service instance (identified by a distinct 
unicast IP addresss.)

Whereas if you count on anycast in the underlay routing, a significant 
move is almost certain to automatically rehome the application session 
with no notification or coordination.

If we assume edge marking, then we need to figure out how to have the 
sticky state in the right place when the UE / UA moves.  Which is at 
least easier than trying to get all the routers in the new path to know 
where this flow is supposed to go.

Yours,
Joel

On 4/13/2022 2:24 PM, Linda Dunbar wrote:
> Jen,
> 
> Does the “UA” mean “User Application” ?
> 
> So your solution requires the applications on the UE  to query the 
> “Central Repository”?
> 
> When a UE roam from one Cell tower to another in the middle of the 
> communication, does your solution require the Application on the UE to 
> periodically query the “Central Repository” to select the optimal path 
> to the “Source”?
> 
> Thank you
> 
> Linda
> 
> *From:* Dyncast <[email-masked]> *On Behalf Of *Jens Finkhaeuser
> *Sent:* Wednesday, April 13, 2022 4:07 AM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]; 
> luigi.iannone=[email-masked]
> speaking from practical experience with the edge case of streaming video 
> from the "best" source, it may be desirable for the UA to make the 
> decision locally, as it's also best suited to deciding if a response no 
> longer matters.
> 
> We'd query a central repository for likely sources with some compute 
> aware ordering, and then use path aware ordering at the UA for narrowing 
> down the candidate list.
> 
> In our use case, we would query all sources, update their ordering on 
> actual RTT, and send ACK equivalents to all, independent of which source 
> provided each packet.
> 
> This could conceivably be done by the ingress, use unicast for all 
> sources, etc. but it would need some transparency. That is, E2EE would 
> likely place this at the UA rather than an ingress router.
> 
> The point here is probably that it's likely best to differentiate 
> between where the path aware and the compute aware metrics get 
> aggregated and evaluated, at least for some types of application.
> 
> Hope that makes sense,
> Jens
> 
> 
> 
>     My understanding of the requirements was that a particular UE was
>     supposed to be bound to a server for the lifetime of a ’transaction’
>     and that includes across the UE rehoming to a different source.
>     Thus, the entire network needs to make a consistent and fixed
>     decision per UE. Doing so in a dynamic environment would seem to be
>     most challenging: you would need to synchronize forwarding state
>     across the entire network instantly.
> 
>     And easier still is Joel’s proposal: have the UE pick one (from a
>     centralized broker?) and then rely on unicast. :-)
> 
>     Regards,
>     T
> 
>      > On Apr 12, 2022, at 7:59 PM, Aijun Wang
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      > Hi, Joel:
>      > If you use binding address behind the ANYCAST address, it is
>     possible. But if you use the ANYCAST address directly, you can't.
>      > To: Aijun Wang <[email-masked]
>     <mailto:[email-masked]>>; 'Luigi IANNONE'
>     <luigi.iannone=40huawei.com
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40huawei.com%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TinZa%2FzGye5Be5QpPp5SIKVO9HNopgrB2IHeTTfiOFE%3D&reserved=0>@dmarc.ietf.org>;
>     [email-masked] <mailto:[email-masked]>;
>     'dyncast' <[email-masked] <mailto:[email-masked]>>
>      > If the ingress edge does the calculation, makes the
>     determination, and tunnels the traffic to the right place then the
>     underlay routing system does not need to know anything about these
>     metrics or the decision processes made by the edge.
>      >
>      > Yours,
>      > Joel
>      >
>      >> From: [email-masked] <mailto:[email-masked]>
>     <[email-masked] <mailto:[email-masked]>> On
>     Behalf Of
>      >> Luigi IANNONE
>      >> To: Aijun Wang <[email-masked]
>     <mailto:[email-masked]>>; 'Joel M. Halpern'
>      >> <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>;
>     'dyncast'
>      >> <[email-masked] <mailto:[email-masked]>>
>      >>> It is time to consider both the network metric and application
>     server
>      >>> metric together to achieve such goals.
>      >>
>      >> [email-masked] <mailto:[email-masked]>
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserved=0>
>      >>
>      >
>      > --
>      > Dyncast mailing list
>      > [email-masked] <mailto:[email-masked]>
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserved=0>
> 
>     --
>     Dyncast mailing list
>     [email-masked] <mailto:[email-masked]>
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserved=0>
> 
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 Apr 2022 20:04:25 +0000

Joel, 

You have stated the clear message from the CAN BoF: it is not desirable "to get all the routers in the new path to know where this flow is supposed to go". 

As for Application querying "Dispatcher" to get the optimal path/destination, there could be many solutions. Like DNS is one of them. Or the front end load balancers presented at the CAN BoF, or Dyncast solution. 

Indeed, the "Sticky state when UE/UA moves" can be tricky, especially for SSC Mode 2 where the UE has a new IP address. 

Linda 

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Wednesday, April 13, 2022 2:31 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dyncast] CAN BoF issues and the next steps

With regard to the specific case of a UE / UA moving to a different cell tower or region, this is in fact one of the advantages of handling this at the application.  Given that the ongoing application exchange has state at the server, you do NOT want to suddenly shift the client to a different server.  As a setp one on mobility, you want to keep using the same server.  Using the server unicast address from the UE / UA makes that work seemlessly.

If we want reoptimization then the application can ask the dispatcher, and in the event a move is desired, ask the server to move the application state to the new service instance (identified by a distinct unicast IP addresss.)

Whereas if you count on anycast in the underlay routing, a significant move is almost certain to automatically rehome the application session with no notification or coordination.

If we assume edge marking, then we need to figure out how to have the sticky state in the right place when the UE / UA moves.  Which is at least easier than trying to get all the routers in the new path to know where this flow is supposed to go.

Yours,
Joel

On 4/13/2022 2:24 PM, Linda Dunbar wrote:
> "Central Repository"?
> periodically query the "Central Repository" to select the optimal path 
> to the "Source"?
> 
> Thank you
> 
> Linda
> 
> speaking from practical experience with the edge case of streaming 
> video from the "best" source, it may be desirable for the UA to make 
> the decision locally, as it's also best suited to deciding if a 
> response no longer matters.
> 
> aware ordering, and then use path aware ordering at the UA for 
> narrowing down the candidate list.
> 
> actual RTT, and send ACK equivalents to all, independent of which 
> source provided each packet.
> 
>     supposed to be bound to a server for the lifetime of a 'transaction'
>     And easier still is Joel's proposal: have the UE pick one (from a
>     <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40huawei.com%2F&amp;data=05%7C01%7Clinda.dunbar%40futurewei.com%7C7dfd80b446a74f6d26d008da1d841c4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854750515030493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=KP7WdmjWj%2BmlGM7zcNvdtsWaDUNZ6TP87MTE%2Bt%2B26tk%3D&amp;reserved=0>@dmarc.ietf.org>;
>      >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&amp;data=05%7C01%7Clinda.dunbar%40futurewei.com%7C7dfd80b446a74f6d26d008da1d841c4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854750515030493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZUUgPUFEbJAAHkpbgl5g1%2FUUO5M%2FsFLf14F2iHlyuuw%3D&amp;reserved=0
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&amp;data=05%7C01%7Clinda.dunbar%40futurewei.com%7C7dfd80b446a74f6d26d008da1d841c4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854750515030493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZUUgPUFEbJAAHkpbgl5g1%2FUUO5M%2FsFLf14F2iHlyuuw%3D&amp;reserved=0>
>      >>
>      >
>      > --
>      > Dyncast mailing list
>      > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&amp;data=05%7C01%7Clinda.dunbar%40futurewei.com%7C7dfd80b446a74f6d26d008da1d841c4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854750515030493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZUUgPUFEbJAAHkpbgl5g1%2FUUO5M%2FsFLf14F2iHlyuuw%3D&amp;reserved=0
>     
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fdyncast&amp;data=05%7C01%7Clinda.dunb
> ar%40futurewei.com%7C7dfd80b446a74f6d26d008da1d841c4c%7C0fee8ff2a3b240
> 189c753a1d5591fedc%7C1%7C0%7C637854750515030493%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&amp;sdata=ZUUgPUFEbJAAHkpbgl5g1%2FUUO5M%2FsFLf14F2iHlyu
> uw%3D&amp;reserved=0>
> 
>     --
>     Dyncast mailing list
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdyncast&amp;data=05%7C01%7Clinda.dunbar%40futurewei.com%7C7dfd80b446a74f6d26d008da1d841c4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854750515030493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZUUgPUFEbJAAHkpbgl5g1%2FUUO5M%2FsFLf14F2iHlyuuw%3D&amp;reserved=0
>     
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fdyncast&amp;data=05%7C01%7Clinda.dunb
> ar%40futurewei.com%7C7dfd80b446a74f6d26d008da1d841c4c%7C0fee8ff2a3b240
> 189c753a1d5591fedc%7C1%7C0%7C637854750515030493%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&amp;sdata=ZUUgPUFEbJAAHkpbgl5g1%2FUUO5M%2FsFLf14F2iHlyu
> uw%3D&amp;reserved=0>
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Apr 2022 09:50:21 +0800

Hi, Joel, Linda

    I agree with the point below:  

"Using the server unicast address from the UE / UA makes that work seemlessly."

Besides, IMHO, if the number of clients requiring the same service is huge, the L3 Load balancing base on anycast/Dyncast also makes sense.
Should it be the second step to consider the mobility? It is complicated.

Best Regards
Zongpeng Du

From: Joel M. Halpern
Date: 2022-04-14 03:30
To: Linda Dunbar
CC: [email-masked]

 
 
Yours,
Joel

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 14 Apr 2022 06:39:47 +0000

Linda,

As for a ‘service instance moving’, this was brought up in the chat. I can imagine scenarios in which previous selections of a service instance (with which I have ongoing transaction, so a client has an ongoing affinity to this instance) may become non-optimal, either through changes at the serving host of the instance (e.g., it may become overloaded due to side load) or through changes at the client side (e.g., the client may move and, say, latency changes compared to the previous attachment point).

In those cases, a re-assignment of the service instance may be desirable. This also brings up the question whether that would happen mid-transaction, which then leads to the application state problem – I am not as strict as Joel in saying that this has advantages in being handled at the application level. It clearly has aspects that I can see almost only been handled at the app level, such as transferring the actual state (unless we advocate a network-level shared data storage but let us not go there). But it is maybe of interest what the role of a CAN network would be to assist those cases but that discussion may much depend on the solution space being explored for CAN in general.

I hope this explains.

Best,

Dirk

From: Linda Dunbar [mailto:[email-masked]]
Sent: 13 April 2022 20:29
To: Dirk Trossen <[email-masked]>; [email-masked]; Tony Li <[email-masked]>; Aijun Wang <[email-masked]>; Halpern' <[email-masked]>
Cc: [email-masked]; Peng Liu <[email-masked]>; Luigi IANNONE <[email-masked]>
Subject: RE: [Dyncast] CAN BoF issues and the next steps

Dirk,

Thank you.
Linda

From: Dyncast <[email-masked]<mailto:[email-masked]>> On Behalf Of Dirk Trossen
Sent: Wednesday, April 13, 2022 1:06 AM
To: [email-masked]<mailto:[email-masked]>; Tony Li <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Halpern' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Peng Liu <[email-masked]<mailto:[email-masked]>>; Luigi IANNONE <luigi.iannone=[email-masked]<mailto:luigi.iannone=[email-masked]>>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

All,

Best,

Dirk

Hi, Tony, Aijun, Joel:

Hi Aijun,

Regards,
T

---

From: Jens Finkhaeuser <[email-masked]>
Date: Thu, 14 Apr 2022 07:50:50 +0000

Linda,
yes, User Application or User Agent.
This is describing how the system worked in the past. It is not strictly required that a system should work like this in future.

However, it is a fairly special edge case: video streaming doesn't so much care about "compute" as it cares about storage; this distinction gets a bit blurred when a video stream is produced on-the-fly/live.
Keeping this distinction in mind, there are hard timeouts past which a UA no longer cares about a (live) video frame. One way to deal with this is to adopt solutions similar to time sensitive networking where the UA provides such timeout information up front with every request - or the UA discards expired data itself. Since it's nontrivial to map a video frame to some byte sequence without decoding the byte sequence, the latter was the better choice.
I'm not sure what the intended scope of CAN is, and whether this kind of use case is of interest. But in case it is, I hope my description helps.
Jens

------- Original Message -------

> So your solution requires the applications on the UE  to query the “Central Repository”?
> 

> When a UE roam from one Cell tower to another in the middle of the communication, does your solution require the Application on the UE to periodically query the “Central Repository” to select the optimal path to the “Source”?
>

---

From: Jens Finkhaeuser <[email-masked]>
Date: Thu, 14 Apr 2022 08:04:37 +0000

Hi,

Dirk and I have been separately discussing a use case in which UA moves, but service instances moving are in a way the same issue in reverse. See below.

------- Original Message -------
On Wednesday, April 13th, 2022 at 21:30, Joel M. Halpern <[email-masked]> wrote:

> same server. Using the server unicast address from the UE / UA makes

The use case that I'm actively working on relates to drones, where changes in network attachment can happen at any time. At the same time, the service - in this case a ground control station steering the drone - may also need to move simply because the new network has a much better path to a different one (if we involve the use of private networks, this problem gets critical).

For regulatory reasons, the different networks may require the use of different radio technology, which may mean that the application needs to manage multiple radios. Our current approach here is to have an ingress router on the drone that manages radios and therefore network attachment and paths, which keeps the application agnostic of such changes. I think this approach would suit the CAN BoF work quite well; this ingress router can also make the optimal service choice from a compute perspective.

Merging this with the previous video use case I was mentioning, it may be that such an ingress router needs to be made aware of timeouts for each request, at which point returning responses is no longer of interest.

I understand that I'm considering solutions to specific use cases here, but as far as I understand, that's sort of the point for arriving at a generalized architecture, right?

Jens

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Apr 2022 16:17:17 +0800

Hi Jens,

Yes video cares more about storage, while in some cases the storage could also be seen in the scope of compute, if we consider this as a factor from the service instance side. More request will cause a heavy load.

Though there are some existing methods to guarantee the video's experience, if we want, I think video service could also benefit from CAN to get the video content dynamiclly.

Regards,
Peng

From: Jens Finkhaeuser
Date: 2022-04-14 15:50
To: Linda Dunbar
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; luigi.iannone=[email-masked]
Subject: RE: [Dyncast] CAN BoF issues and the next steps
Linda,

Jens

------- Original Message -------

Jen, 

 
Thank you
Linda

Hi all,

Hope that makes sense,
Jens

-------- Original Message --------

Hi Aijun,

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 14 Apr 2022 17:34:02 +0800

Is "Compute Aware Network" equal to "Session Aware Network"(SAN)?
For SAN, I think it is better to be accomplished via the L4-7 load balancer, there are lots of state to be stored on the devices.
But deploying the L4-7 load balancer in distributed mode is also one challenge to the operator, another is how to let the distributed load balancer synchronized with the network condition.

Should we let CAN to focus on the connection-less or connection-unware application?

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Thursday, April 14, 2022 3:31 AM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Yours,
Joel

On 4/13/2022 2:24 PM, Linda Dunbar wrote:
> .ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%4
> 0futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c
> 753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserv
> ed=0>
> 
>     --
>     Dyncast mailing list
> .ietf.org%2Fmailman%2Flistinfo%2Fdyncast&data=05%7C01%7Clinda.dunbar%4
> 0futurewei.com%7Cca6dc1b0fded458cdb1408da1d2d1f58%7C0fee8ff2a3b240189c
> 753a1d5591fedc%7C1%7C0%7C637854376904197688%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&sdata=piGpQplHZL7q1Xit3lgpkJYwRZ8DZXtcwHz5t623zrw%3D&reserv
> ed=0>
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Apr 2022 18:18:25 +0800

Hi, Aijun

    My suggestion is not to maintain per UE status in the network, so that the Ingress in CAN will only be enhanced to know the server information, not the UE session.

Best Regards
Zongpeng Du

From: Aijun Wang
Date: 2022-04-14 17:34
To: 'Joel M. Halpern'; 'Linda Dunbar'
CC: dyncast

Best Regards
 
Aijun Wang
China Telecom
 
-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Thursday, April 14, 2022 3:31 AM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dyncast] CAN BoF issues and the next steps

 

Yours,
Joel

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 14 Apr 2022 10:31:33 +0000

Hi Jens,

I am wondering if you had an interest in adding the drones example to the use case document? If so, we could discuss this offline on how get your input into this document.

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Jens Finkhaeuser
Sent: 14 April 2022 10:05
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi,

------- Original Message -------
On Wednesday, April 13th, 2022 at 21:30, Joel M. Halpern <[email-masked]> wrote:

> With regard to the specific case of a UE / UA moving to a different 
> cell tower or region, this is in fact one of the advantages of 
> handling this at the application. Given that the ongoing application 
> exchange has state at the server, you do NOT want to suddenly shift 
> the client to a different server. As a setp one on mobility, you want 
> to keep using the same server. Using the server unicast address from 
> the UE / UA makes that work seemlessly.

Jens