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

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

duzongpeng@foxmail.com & duzongpeng@chinamobile.com

From: Joel M. Halpern
Date: 2022-04-14 03:30
To: Linda Dunbar
CC: dyncast@ietf.org
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:
> 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 <dyncast-bounces@ietf.org> *On Behalf Of *Jens Finkhaeuser
> *Sent:* Wednesday, April 13, 2022 4:07 AM
> *To:* tony.li@tony.li; wangaijun@tsinghua.org.cn
> *Cc:* dyncast@ietf.org; liupengyjy@chinamobile.com; 
> luigi.iannone=40huawei.com@dmarc.ietf.org
> *Subject:* Re: [Dyncast] CAN BoF issues and the next steps
> 
> 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 < tony.li@tony.li 
> <mailto:tony.li@tony.li>> 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.
> 
>     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
>     <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn>> 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.
>      > For my understanding, the latter scenario is more popular.
>      >
>      >
>      > Best Regards
>      >
>      > Aijun Wang
>      > China Telecom
>      >
>      > -----Original Message-----
>      > From: Joel M. Halpern <jmh@joelhalpern.com
>     <mailto:jmh@joelhalpern.com>>
>      > Sent: Wednesday, April 13, 2022 10:55 AM
>      > To: Aijun Wang <wangaijun@tsinghua.org.cn
>     <mailto:wangaijun@tsinghua.org.cn>>; '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>;
>     liupengyjy@chinamobile.com <mailto:liupengyjy@chinamobile.com>;
>     'dyncast' <dyncast@ietf.org <mailto:dyncast@ietf.org>>
>      > 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
>      >>
>      >> -----Original Message-----
>      >> From: dyncast-bounces@ietf.org <mailto:dyncast-bounces@ietf.org>
>     <dyncast-bounces@ietf.org <mailto:dyncast-bounces@ietf.org>> On
>     Behalf Of
>      >> Luigi IANNONE
>      >> Sent: Tuesday, April 12, 2022 3:04 PM
>      >> To: Aijun Wang <wangaijun@tsinghua.org.cn
>     <mailto:wangaijun@tsinghua.org.cn>>; 'Joel M. Halpern'
>      >> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>;
>     liupengyjy@chinamobile.com <mailto:liupengyjy@chinamobile.com>;
>     'dyncast'
>      >> <dyncast@ietf.org <mailto:dyncast@ietf.org>>
>      >> 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.
>      >>> It is time to consider both the network metric and application
>     server
>      >>> metric together to achieve such goals.
>      >>
>      >> 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.
>      >>
>      >>
>      >>
>      >>
>      >> --
>      >> Dyncast mailing list
>      >> Dyncast@ietf.org <mailto:Dyncast@ietf.org>
>      >> 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
>      > Dyncast@ietf.org <mailto:Dyncast@ietf.org>
>      > 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
>     Dyncast@ietf.org <mailto:Dyncast@ietf.org>
>     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
Dyncast@ietf.org
https://www.ietf.org/mailman/listinfo/dyncast