Subject: Re: [Dyncast] edge capability feedback

From: 刘鹏<[email-masked]>
Date: 11 Mar 2021 10:24:35 +0800

Hi Mike,

The edge node could inform it's status to the D-routers based on the metric, such as CPU load or other metrics for the specific instance if defined in the furture, then the D-router could choose a suitable edge considering both network and computing or other specific status. We have some experimental verification and functional implementation.

Regards,

Peng

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email:  [email-masked]

发件人: Michael McBride

时间: 2021/03/11(星期四)05:22

收件人: dyncast;

主题: [Dyncast] edge capability feedback 

Hello all, 

Thank you for the very informative side meeting.  

I have a follow up question on discovery. In one of the slides it explains the need to steer traffic to the best edge. How do we know what that best edge is? Is there some feedback mechanism that edge equipment uses to inform a controller,  or other, of it’s compute, etc load in order for dyncast to dynamically steer traffic to the best edge equipment for a particular task? I ask this as some of us are working on a variety of data discovery use cases and wondering if you already have this feedback  mechanism solved. 

Thanks, 

mike

---

From: Barry Greene <[email-masked]>
Date: Wed, 10 Mar 2021 21:33:49 -0600

> On Mar 10, 2021, at 8:24 PM, 刘鹏 <[email-masked]> wrote:
> 

Have you done the due diligence in past work in this area?

What you described above sounds like the signaling in the DOTS work (shifting load based on DDoS).

It is also should similar to Cisco Distributed Direct Routing Protocol (1997ish), TIDP/TMP (early 2000s), and some other network oriented shifting of edge loads.

What would be helpful is a review of all the past efforts (go back to the ‘90s) and review what worked and what did not work.

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 11 Mar 2021 08:14:42 +0000

Hi Barry,

Thanks for the pointers. The use case draft does point to related work but it’s good to extend this  so the pointers are useful for that.

Best,

Dirk

From: Dyncast [mailto:[email-masked]] On Behalf Of Barry Greene
Sent: 11 March 2021 04:34
To: 刘鹏 <[email-masked]>
Cc: dyncast <[email-masked]>; Michael McBride <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

On Mar 10, 2021, at 8:24 PM, 刘鹏 <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Liyizhou <[email-masked]>
Date: Thu, 11 Mar 2021 09:48:45 +0000

Hi Barry,

Is RFC8782 the one you mentioned as DOTS signaling channel?

AFAIK DOTS signal channel is most likely to report some risky traffic from DOTS client and server.
DOTS signaling channel is more for light weight info exchange regarding what the potential attack is between DOTS client and DOTS server. It is not relevant to where and what are the reachable serving address and also it is hardly the case a single client talking to a number of servers.
Client and server are pre-determined pair in most cases.

For metrics sync or distribution, a metric agent needs to distribute the metrics to a number of D-Routers so that each can make the own choices when a service demand reaches.

So DOTS signal channel was not designed for such purpose and it is a bit hard for me to imagine what kind of changes would be required to let it carry those metrics info and make such info flooded out.

Cheers,
Yizhou

Sent: Thursday, March 11, 2021 11:34 AM

---

From: Tianji Jiang <[email-masked]>
Date: Thu, 11 Mar 2021 17:06:14 -0800

Yes, I concur with Yizhou’s comments below.

Based on the objective that has been laid out by Dyncast initiative, a client intends to find the ‘most suitable’ server for a type of service. The critical use cases and the corresponding deployment settings as specified in Dyncast drafts are most mobile-related edge-computing scenarios. So, considering these together, if we put the server-selection intelligence at an end client (like a UE) itself, then the UE would require significant amount of new logics. 

Moreover, it is always challenging to determine (a) how a UE could do this type of ‘selection intelligence’; (b) what are the “consensus selection criteria’ across numerous UEs; (c) how a service instance (i.e., a server) in an IP domain could signal the update-to-date metrics to UEs, etc. All these would require the involvement of both UEs (like utilizing URSP) and mobile core (saying 5GC), aside from the work in IP domain . IMO, these are way beyond the scope. So, all the *new logics* related to Dyncast would be best addressed in IP network. 

That is why I think the ‘architecture design’ in Dyncast proposals does make sense as the first starting step.

Thanks.

-Tianji

From: Dyncast <[email-masked]> on behalf of Liyizhou <[email-masked]>
Date: Thursday, March 11, 2021 at 1:48 AM
To: Barry Greene <[email-masked]>, 刘鹏 <[email-masked]>
Cc: dyncast <[email-masked]>, Michael McBride <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

Hi Barry,

Cheers,

Yizhou

 

 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Mar 2021 21:29:09 -0500

If the UE had a way to ask an informed server, there would be no need 
for the UE to have a "significant amount of new logics".
And we would not have to worry about overloading routing with behavior 
and data that it does not need.  And we would naturally get the needed 
stickiness.

Yours,
Joel

On 3/11/2021 8:06 PM, Tianji Jiang wrote:
> Based on the objective that has been laid out by Dyncast initiative, a 
> client intends to find the ‘most suitable’ server for a type of service. 
> The critical use cases and the corresponding deployment settings as 
> specified in Dyncast drafts are most mobile-related edge-computing 
> scenarios. So, considering these together, if we put the 
> server-selection intelligence at an end client (like a UE) itself, then 
> the UE would require significant amount of new logics.
> 
> Moreover, it is always challenging to determine (a) how a UE could do 
> this type of ‘selection intelligence’; (b) what are the “consensus 
> selection criteria’ across numerous UEs; (c) how a service instance 
> (i.e., a server) in an IP domain could signal the update-to-date metrics 
> to UEs, etc. All these would require the involvement of both UEs (like 
> utilizing URSP) and mobile core (saying 5GC), aside from the work in IP 
> domain . IMO, these are way beyond the scope. So, all the **new logics** 
> related to Dyncast would be best addressed in IP network.
> 
> *From: *Dyncast <[email-masked]> on behalf of Liyizhou 
> <[email-masked]>
> *Date: *Thursday, March 11, 2021 at 1:48 AM
> *To: *Barry Greene <[email-masked]>, 刘鹏 <[email-masked]>
> *Cc: *dyncast <[email-masked]>, Michael McBride 
> <[email-masked]>
> *Subject: *Re: [Dyncast] edge capability feedback
> 
> Hi Barry,
> 
> DOTS signaling channel is more for light weight info exchange regarding 
> what the potential attack is between DOTS client and DOTS server. It is 
> not relevant to where and what are the reachable serving address and 
> also it is hardly the case a single client talking to a number of servers.
> 
> For metrics sync or distribution, a metric agent needs to distribute the 
> metrics to a number of D-Routers so that each can make the own choices 
> when a service demand reaches.
> 
> So DOTS signal channel was not designed for such purpose and it is a bit 
> hard for me to imagine what kind of changes would be required to let it 
> carry those metrics info and make such info flooded out.
> 
> Cheers,
> 
> Yizhou
> 
> *From:*Dyncast [mailto:[email-masked]] *On Behalf Of *Barry Greene
> *Sent:* Thursday, March 11, 2021 11:34 AM
> *To:* 刘鹏<[email-masked]>
> *Cc:* dyncast <[email-masked]>; Michael McBride 
> <[email-masked]>
> *Subject:* Re: [Dyncast] edge capability feedback
> 
> 
> 
> 
>     On Mar 10, 2021, at 8:24 PM, 刘鹏 <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     The edge node could inform it's status to the D-routers based on the
>     metric, such as CPU load or other metrics for the specific instance
>     if defined in the furture, then the D-router could choose a suitable
>     edge considering both network and computing or other specific
>     status. We have some experimental verification and functional
>     implementation.
> 
> It is also should similar to Cisco Distributed Direct Routing Protocol 
> (1997ish), TIDP/TMP (early 2000s), and some other network oriented 
> shifting of edge loads.
> 
> What would be helpful is a review of all the past efforts (go back to 
> the ‘90s) and review what worked and what did not work.
> 
> -- Dyncast mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dyncast
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Mar 2021 07:16:43 +0100

On 12. Mar 2021, at 03:29, Joel M. Halpern <[email-masked]> wrote:
> 
> If the UE had a way to ask an informed server, there would be no need for the UE to have a "significant amount of new logics".
> And we would not have to worry about overloading routing with behavior and data that it does not need.  And we would naturally get the needed stickiness.

As far as I understand dyncast, I see the following two reasons for not simply falling back to an “ask a server” approach:

* Just-send.  See slide 35 on [1].  This assumes that saving that round-trip is a relevant consideration for some applications.  (It is hard to amortize the round-trip when progress (same slide) is needed; of course the client could proactively ask at the start of each new service period — but that creates a constant load.)
* The server may not know.  Even if the server is reached using anycast, it may not have a way to get input from the routing system that is knowledgeable about the specific network environment of the client.  This becomes relevant when the “last mile” provides choices and there is more than one edge server cluster close to the client.

It seems to me that dyncast has not previously been pursued mainly because there weren’t that many applications that could actually benefit from addressing these two considerations.  

Grüße, Carsten

[1] https://github.com/dyncast/ietf110/blob/main/dyncast-ietf110-side-meeting-full-deck.pdf

---

From: "Milheiro Mendes, Paulo Jorge" <[email-masked]>
Date: Fri, 12 Mar 2021 08:29:20 +0100

I fully agree that the logistics of having a client "asking a server" does
not align with the aim of Dyncast, to the best of my understanding. The
advantage of any anycast type of solution is exactly having clients that
are agnostic of the servers that may provide an answer. The client needs to
ask the network itself. So it is up to D-routers at the edges to get to a
consensus about who should reply. Following what Tianji said, the issue is
about what are the “consensus selection criteria’ across D-routers and not
numerous UEs.

Cheers

*Dr. Paulo Mendes*

Senior Scientist

Central Research and Technology, XRC

*Airbus*

---- AIRBUS AMBER ----

On Fri, Mar 12, 2021 at 7:17 AM Carsten Bormann <[email-masked]> wrote:

> As far as I understand dyncast, I see the following two reasons for not
> simply falling back to an “ask a server” approach:
>
> * Just-send.  See slide 35 on [1].  This assumes that saving that
> round-trip is a relevant consideration for some applications.  (It is hard
> to amortize the round-trip when progress (same slide) is needed; of course
> the client could proactively ask at the start of each new service period —
> but that creates a constant load.)
> * The server may not know.  Even if the server is reached using anycast,
> it may not have a way to get input from the routing system that is
> knowledgeable about the specific network environment of the client.  This
> becomes relevant when the “last mile” provides choices and there is more
> than one edge server cluster close to the client.
>
> It seems to me that dyncast has not previously been pursued mainly because
> there weren’t that many applications that could actually benefit from
> addressing these two considerations.
>
> Grüße, Carsten
>
> [1]
> https://github.com/dyncast/ietf110/blob/main/dyncast-ietf110-side-meeting-full-deck.pdf
>
> --
> Dyncast mailing list
> [email-masked]
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 12 Mar 2021 07:58:57 +0000

Hi Carsten & Joel,

Please see inline.

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: 12 March 2021 07:17
To: Joel M. Halpern <[email-masked]>
Cc: dyncast <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

[DOT] this becomes even more of an issue if your periods are rather small, e.g., a few requests long, making the 'control load' a significant proportion of your overall efficiency. 
* The server may not know.  Even if the server is reached using anycast, it may not have a way to get input from the routing system that is knowledgeable about the specific network environment of the client.  This becomes relevant when the “last mile” provides choices and there is more than one edge server cluster close to the client.
[DOT] I may use a separate application-level server (the one 'who knows') pushing all metric information to that server who serves as a 'dispatcher' of sort, providing the D-BID to be used based on the latest information. But it comes back to the dynamicity issue above, also discussed in the Dyncast use case draft, leading to inefficiencies (possibly not meeting requirements of the applications). Complexity also arises since the 'one who knows' may not be well (enough) placed, requiring placement approaches for improving to support dynamicity. Again, the use case draft points this out.

It seems to me that dyncast has not previously been pursued mainly because there weren’t that many applications that could actually benefit from addressing these two considerations.  
[DOT] A healthy pushback, as in Joel's response, is often good. But you point at the main issue: behaviours may emerge (in the form of the applications you mention) that require an adjusted view on what routing should provide to them. That's why we've long evolved from the simple "send packet from source A to destination B" and have seen a plethora of input being used to make decisions, at least in parts of the network, here in Dyncast at the ingress point, i.e., the d-router. Adrian's presentation at the RTGWG yesterday pointed to an emerging discussion on this (and the draft discussing this at https://tools.ietf.org/html/draft-king-irtf-challenges-in-routing-01).

Grüße, Carsten

---

From: Luigi IANNONE <[email-masked]>
Date: Fri, 12 Mar 2021 08:48:50 +0000

Hi,

I agree with you all that Dyncast has several benefits compared to a server based solution.

However, I would like to come back to Barry's point: DDoS.

AFAIR we did not touch that much this issues, yet, it is important to consider the case of a malicious attacker trying to abuse Dyncast.
What kind of mechanism should Dyncast include? Can DOTS somehow help? (I do not know this technology so I do not have an answer)

Certainly in the next version of the architectural document we should start to provide a security analysis at least from an architectural perspective ;-) 

Ciao

L.

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Dirk Trossen
Sent: Friday, March 12, 2021 8:59
To: Carsten Bormann <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: dyncast <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

Hi Carsten & Joel,

Please see inline.

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: 12 March 2021 07:17
To: Joel M. Halpern <[email-masked]>
Cc: dyncast <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Mar 2021 10:03:51 +0100

> AFAIR we did not touch that much this issues, yet, it is important to consider the case of a malicious attacker trying to abuse Dyncast.

I think we need to distinguish the client as an attacker and the server as an attacker.

Beyond what any network user can do, the most interesting angle a dyncast client can use is resource exhaustion by creating fake state.
Not creating state per client (Option 5) is probably the only realistic mitigation.

I haven’t really thought about server-side attacks.  Servers will be able to create state, and there needs to be some active state management (not just against attacks, but also against malfunctions such as continuously rebooting or respawning servers).

> What kind of mechanism should Dyncast include? Can DOTS somehow help? (I do not know this technology so I do not have an answer)

DOTS is really about the victim (or their collaterals) talking to the network to mitigate an attack that cannot be otherwise managed.  Let’s try to make that unnecessary :-)

> Certainly in the next version of the architectural document we should start to provide a security analysis at least from an architectural perspective ;-) 

Indeed!

Grüße, Carsten

---

From: "Meiling Chen" <[email-masked]>
Date: Fri, 12 Mar 2021 18:15:22 +0800

Hi,
It's really worth talking about whether DOTS can be applied to new fields.
As one of the DOTS contributors, I may think DOTS is not so suitable to solve the problem existed in Dyncast, 
DOTS use client to send mitigation request to DOTS server, It's C/S structure.
the scope of DOTS definition mainly in Signal channel and Data channel which between DOTS client and server.
Signal channel use CoAP based on TLS or DTLS to transmit mitigation request which triggered by DDoS Alarm.
The main function of the data channel is data exchange, which requires a reliable transport mode and uses RESTCONF based on TLS.
the protocol which will be used in Dyncast should be reliable, however, data channel is not lightweight enough.

Best Regards,
Meiling.
 
From: Carsten Bormann
Date: 2021-03-12 17:03
To: Luigi IANNONE
CC: dyncast; Dirk Trossen; Joel M. Halpern
Subject: Re: [Dyncast] edge capability feedback

 

 
 
Indeed!
 
Grüße, Carsten

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 12 Mar 2021 06:42:40 -0500

You don't want the client to ask a server the question?
Are you planning to have these applications run without DNS?
Whether the server is actually DNS or is some other protocol that is 
used instead, there is no need for this problem to cause any more delay 
than DNS.

And saying that the server won't know the answer seems rather odd.  If 
we design the system so that the servers get the information, then they 
get the information.  And then can apply whatever policies, logic, 
calculation, etc that is needed to make the per-suer decision.  In fact, 
since the servers can also have user poliy information if we want, they 
are better able than the indiivdual routers to do this kind of thing.

If we are not going to go this route, then we need to get rid of the 
user state requirements and recast the flow stickiness in a way that 
does not have forwarding routers doing flow-stateful forwarding.

Separately, if we really don't think the UE can issue the queries, then 
lets use an approach like LISP where we can still decouple the 
information from routing, and use an edge encapsulation to represent the 
decision.

It just seems to me that involving the UE is simpler, particularly 
because the problem we are trying to address is new applications, not 
existing ones.

Yours,
Joel

On 3/12/2021 2:29 AM, Milheiro Mendes, Paulo Jorge wrote:
> I fully agree that the logistics of having a client "asking a server" 
> does not align with the aim of Dyncast, to the best of my understanding. 
> The advantage of any anycast type of solution is exactly having clients 
> that are agnostic of the servers that may provide an answer. The client 
> needs to ask the network itself. So it is up to D-routers at the edges 
> to get to a consensus about who should reply. Following what Tianji 
> said, the issue is about what are the “consensus selection criteria’ 
> across D-routers and not numerous UEs.
> 
> Cheers
> 
> *Dr. Paulo Mendes*
> 
> Senior Scientist
> 
> On Fri, Mar 12, 2021 at 7:17 AM Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On 12. Mar 2021, at 03:29, Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      > If the UE had a way to ask an informed server, there would be no
>     need for the UE to have a "significant amount of new logics".
>      > And we would not have to worry about overloading routing with
>     behavior and data that it does not need.  And we would naturally get
>     the needed stickiness.
> 
>     As far as I understand dyncast, I see the following two reasons for
>     not simply falling back to an “ask a server” approach:
> 
>     round-trip is a relevant consideration for some applications.  (It
>     is hard to amortize the round-trip when progress (same slide) is
>     needed; of course the client could proactively ask at the start of
>     each new service period — but that creates a constant load.)
>     * The server may not know.  Even if the server is reached using
>     anycast, it may not have a way to get input from the routing system
>     that is knowledgeable about the specific network environment of the
>     client.  This becomes relevant when the “last mile” provides choices
>     and there is more than one edge server cluster close to the client.
> 
>     It seems to me that dyncast has not previously been pursued mainly
>     because there weren’t that many applications that could actually
>     benefit from addressing these two considerations.
> 
>     Grüße, Carsten
> 
>     [1]
>     <https://github.com/dyncast/ietf110/blob/main/dyncast-ietf110-side-meeting-full-deck.pdf>
> 
>     -- 
>     Dyncast mailing list
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dyncast>
> 
> The information in this e-mail is confidential. The contents may not be 
> disclosed or used by anyone other than the addressee. Access to this 
> e-mail by anyone else is unauthorised.
> Airbus cannot accept any responsibility for the accuracy or completeness 
> of this e-mail as it has been sent over public networks. If you have any 
> concerns over the content of this message or its Accuracy or Integrity, 
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated 
> virus scanning software but you should take whatever measures you deem 
> to be appropriate to ensure that this message and any attachments are 
> virus free.

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 12 Mar 2021 12:39:52 +0000

Joel, 

See my response before about using a server. I am not saying you cannot use a server per se; the question is more whether or not the server is capable of providing the metric-based decision in time and efficiently - granted that efficiency may not be my concern though but given that efficiency might hit my latency budget available, I may still need to care. 

As for the client state issue, the discussion in the side meeting aimed at highlighting that this is indeed a core issue since certain options to handle affinity stickiness will indeed create such client state, while solutions such as those outlined by Carsten (or option 2 for that matter) won't. 

As for the involvement of the client, I am having trouble to see how we can have any solution that wouldn't involve any change at the client to start with. I'm with you on the point that I won't worry about this if the target are 'new applications' anyway. 

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: 12 March 2021 12:43
To: Milheiro Mendes, Paulo Jorge <[email-masked]>; Carsten Bormann <[email-masked]>
Cc: dyncast <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

You don't want the client to ask a server the question?
Are you planning to have these applications run without DNS?
Whether the server is actually DNS or is some other protocol that is used instead, there is no need for this problem to cause any more delay than DNS.

And saying that the server won't know the answer seems rather odd.  If we design the system so that the servers get the information, then they get the information.  And then can apply whatever policies, logic, calculation, etc that is needed to make the per-suer decision.  In fact, since the servers can also have user poliy information if we want, they are better able than the indiivdual routers to do this kind of thing.

If we are not going to go this route, then we need to get rid of the user state requirements and recast the flow stickiness in a way that does not have forwarding routers doing flow-stateful forwarding.

Separately, if we really don't think the UE can issue the queries, then lets use an approach like LISP where we can still decouple the information from routing, and use an edge encapsulation to represent the decision.

It just seems to me that involving the UE is simpler, particularly because the problem we are trying to address is new applications, not existing ones.

Yours,
Joel

On 3/12/2021 2:29 AM, Milheiro Mendes, Paulo Jorge wrote:
> The advantage of any anycast type of solution is exactly having 
> clients that are agnostic of the servers that may provide an answer. 
> The client needs to ask the network itself. So it is up to D-routers 
> at the edges to get to a consensus about who should reply. Following 
> what Tianji said, the issue is about what are the “consensus selection criteria’
> The information in this e-mail is confidential. The contents may not 
> be disclosed or used by anyone other than the addressee. Access to 
> this e-mail by anyone else is unauthorised.
> Airbus cannot accept any responsibility for the accuracy or 
> completeness of this e-mail as it has been sent over public networks. 
> If you have any concerns over the content of this message or its 
> Accuracy or Integrity, please contact Airbus immediately.

---

From: "Dirk Kutscher" <[email-masked]>
Date: Fri, 12 Mar 2021 15:27:31 +0100

Hi all,

I think the point that Joel is making that Dynacast, while it can be 
specified on paper and possibly be implemented, seems to ignore the way 
that 99% of all applications (including hyperscaler-driven edge) work 
today.

Now, that can be fine (as you say, this is for new applications), but 
still some of the motivation and design question are debatable:

* "just send": Really? It's difficult to imagine that you wouldn't setup 
a security context with an AR support function in the edge. For anything 
session-oriented, the extra RT is neglectable.
* Metric Agent: How realistic is it that OTT services would share that 
info?
* D-Router: Additional per client-state, application knowledge and 
per-client state in the network -- not sure that's convincing

IMO, the problem here is that Dynacast tries to apply a layer-3 (IP) 
hammer to a much bigger problem (that, today, requires a set of tools 
and different systems to interoperate). Now, the state of the art (OTT 
CDN etc.) is not ideal, for sure.

But if you think Dynacast through, you would end up with a telco-style 
service network -- where the telco infrastructure is heavily involved in 
application-relevant decision making (and would probably run the 
corresponding services, too) -- i.e., the opposite of what the world is 
converging to today.

I am not against discussing this (especially because there are problems 
in todays networks), but if you are considering a green-field approach 
anyway, then you wouldn't necessary start from adding application 
awareness to layer 3.

Instead, I would think about:

* what are functions/services and their instances?
* who owns and controls them?
* how should service classes and service instances be named?
* what is the security model (this should probably be higher in the 
list)?
* How are applications actually distributed, load-balanced scaled etc.?

The key architectural question is how get balance adding the required 
support to the network and avoiding application-specific knowledge in 
the network.

Since we haven't seen answers to these questions yet, it feels premature 
to present Dynacast as an engineering effort -- I would expect this to 
be a good topic for research (and there is IRTF COINRG that is concerned 
with exactly this topic).

BTW, even if you accept constraints from running over existing networks, 
there are IMO better way to map (secure) naming and smarter forwarding 
logic to IP (without necessarily requiring application knowledge), such 
as https://tools.ietf.org/html/draft-muscariello-intarea-hicn-04.

In conclusion, I really don't want to derail this work, but IMO, this 
requires a broader, possibly more principled approach that just adding 
anycast and service routing entities to an IP network -- it's more than 
an IP engineering problem.

Best regards,
Dirk

On 12 Mar 2021, at 13:39, Dirk Trossen wrote:

> Joel,
>
> See my response before about using a server. I am not saying you 
> cannot use a server per se; the question is more whether or not the 
> server is capable of providing the metric-based decision in time and 
> efficiently - granted that efficiency may not be my concern though but 
> given that efficiency might hit my latency budget available, I may 
> still need to care.
>
> As for the client state issue, the discussion in the side meeting 
> aimed at highlighting that this is indeed a core issue since certain 
> options to handle affinity stickiness will indeed create such client 
> state, while solutions such as those outlined by Carsten (or option 2 
> for that matter) won't.
>
> As for the involvement of the client, I am having trouble to see how 
> we can have any solution that wouldn't involve any change at the 
> client to start with. I'm with you on the point that I won't worry 
> about this if the target are 'new applications' anyway.
>
> Best,
>
> Dirk
>
> used instead, there is no need for this problem to cause any more 
> delay than DNS.
>
> we design the system so that the servers get the information, then 
> they get the information.  And then can apply whatever policies, 
> logic, calculation, etc that is needed to make the per-suer decision.  
> In fact, since the servers can also have user poliy information if we 
> want, they are better able than the indiivdual routers to do this kind 
> of thing.
>
> Separately, if we really don't think the UE can issue the queries, 
> then lets use an approach like LISP where we can still decouple the 
> information from routing, and use an edge encapsulation to represent 
> the decision.
>

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 12 Mar 2021 15:06:45 +0000

Hi Dirk,

Thanks for those comments. Please see inline for comments.

Best,

Dirk

From: Dyncast [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: 12 March 2021 15:28
To: Dirk Trossen <[email-masked]>
Cc: dyncast <[email-masked]>; Joel Halpern Direct <[email-masked]>; Carsten Bormann <[email-masked]>; Milheiro Mendes, Paulo Jorge <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

Hi all,

I think the point that Joel is making that Dynacast, while it can be specified on paper and possibly be implemented, seems to ignore the way that 99% of all applications (including hyperscaler-driven edge) work today.

Now, that can be fine (as you say, this is for new applications), but still some of the motivation and design question are debatable:

  *   "just send": Really? It's difficult to imagine that you wouldn't setup a security context with an AR support function in the edge. For anything session-oriented, the extra RT is neglectable.
[DOT] even your session may be short and an extra RT (to what? An app server? DNS -> not just additional RT an issue?) may well be an issue for the first transaction.

  *   Metric Agent: How realistic is it that OTT services would share that info?
[DOT] we’ve only started discussion on those metrics, even to the point that those metrics may well be simple opaque values, obfuscating semantics, over an agreed action set. Even if they were ‘semantic-rich’, edge services (often done in deeper collaboration with net provider) may well share metrics, given the possible benefits from doing so in terms of performance. It is desired that those metrics are generic (as said, even to the point of being opaque values) to limit application knowledge going southbound.

  *   D-Router: Additional per client-state, application knowledge and per-client state in the network -- not sure that's convincing
[DOT] the client state is one of the options discussed in the side meeting, but it’s not the only (and possibly not at all) way to go. Not sure what application knowledge beyond metrics (see above) you are referring to.

IMO, the problem here is that Dynacast tries to apply a layer-3 (IP) hammer to a much bigger problem (that, today, requires a set of tools and different systems to interoperate). Now, the state of the art (OTT CDN etc.) is not ideal, for sure.

But if you think Dynacast through, you would end up with a telco-style service network -- where the telco infrastructure is heavily involved in application-relevant decision making (and would probably run the corresponding services, too) -- i.e., the opposite of what the world is converging to today.

[DOT] I’m not seeing where you get this conclusion that dyncast would drive app/network integration. I feel that it’s strong leap from exposing additional traffic steering information to ending up in a strongly integrated telco-style service network.

I am not against discussing this (especially because there are problems in todays networks), but if you are considering a green-field approach anyway, then you wouldn't necessary start from adding application awareness to layer 3.

[DOT] We should maybe dig deeper into your understanding of application awareness here. Unlike other proposals, we are, for instance, not suggesting to stick appIDs to information being used for routing. If we had opaque metric values, little inference back to the application would be possible. In conclusion, I feel that you have an understanding of dyncast that does not match with what we intend to do.

  *   what is the security model (this should probably be higher in the list)?

The key architectural question is how get balance adding the required support to the network and avoiding application-specific knowledge in the network.

[DOT] You concisely and well summarize the key architectural question and Dyncast is exactly about this! The metric discussion is the one point where the intention is to avoid (too much) application-specific knowledge as much as possible while still allowing for reasonable support for anycast routing decisions. In what’s been discussed so far, I don’t see how application-specific knowledge (beyond binding identifiers for application instances and metrics in a form that is still being discussed) is being widely introduced into the network.

Since we haven't seen answers to these questions yet, it feels premature to present Dynacast as an engineering effort -- I would expect this to be a good topic for research (and there is IRTF COINRG that is concerned with exactly this topic).

[DOT] I don’t deny that there’s a wealth of service routing questions. Some of those I raise myself in the COIN RG although I don’t see COIN specifically focused on routing questions but certainly on those around distributed, including in-network, applications. As an engineering effort, however, Dyncast is exactly aiming at improving on the existing anycast methodology by looking into a more insightful decision basis for the anycast routing decision.

BTW, even if you accept constraints from running over existing networks, there are IMO better way to map (secure) naming and smarter forwarding logic to IP (without necessarily requiring application knowledge), such as https://tools.ietf.org/html/draft-muscariello-intarea-hicn-04.

In conclusion, I really don't want to derail this work, but IMO, this requires a broader, possibly more principled approach that just adding anycast and service routing entities to an IP network -- it's more than an IP engineering problem.

Best regards,
Dirk

Joel,

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: 12 March 2021 12:43
To: Milheiro Mendes, Paulo Jorge <[email-masked]<mailto:[email-masked]>>; Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Cc: dyncast <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dyncast] edge capability feedback

Yours,
Joel

Cheers

*Dr. Paulo Mendes*

Senior Scientist

*Airbus*

---- AIRBUS AMBER ----

Grüße, Carsten

[1]

<https://github.com/dyncast/ietf110/blob/main/dyncast-ietf110-side-mee
ting-full-deck.pdf>

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

If you are not the intended recipient, please notify Airbus
immediately and delete this e-mail.

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

---

From: Tianji Jiang <[email-masked]>
Date: Fri, 12 Mar 2021 16:02:52 -0800

>From the critical use-cases and deployment scenarios discussed in Dyncast initiative, I can derive 5G EC would be a typical deployment environment.

In 5G EC (3GPP TS 23.558, TR 23.748), there is already scheme that discusses how an EAS (EC App Server, or service instance in Dyncast term) could inform a UE (client) of its states. The control logics are fairly complicated to signal metrics to an entity (presumably being the UE, which then would involve another challenging point of URSP setting). The signaling process will have to involve AF/NEF/PCF/SMF/AMF, etc. in 5GC. If the 'entity' is a configuration server, if the server is not in 5GC, then the previous similar signaling logics will be triggered. Dyncast will have to avoid it.

Moreover, the above logics (and 3GPP documents) do not include to collect the metrics of IP-networks over which UE traffic transmits to EAS (service instance). 

Further, the 3GPP EC documents also discuss how to best enable EC applications, mentioning the use of EES/ECS (at server side), EEC (at UE/client side). Its logics are not simple either. 

Therefore, I do *not* think 'having client talk to server directly' is a good direction to go.

On 3/12/21, 4:39 AM, "Dyncast on behalf of Dirk Trossen" <[email-masked] on behalf of [email-masked]> wrote:

    Joel, 

    
    
    Best,
    
    Dirk
    
    -----Original Message-----
    From: Dyncast [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
    Sent: 12 March 2021 12:43
    To: Milheiro Mendes, Paulo Jorge <[email-masked]>; Carsten Bormann <[email-masked]>
    Cc: dyncast <[email-masked]>
    Subject: Re: [Dyncast] edge capability feedback

    

    
    Yours,
    Joel

---

From: Luigi IANNONE <[email-masked]>
Date: Sat, 13 Mar 2021 08:38:11 +0000

Hello,

Thanks Dirk K. for your feedback. I think we have more work to do in clarifying the Dyncast objectives and scope.

However, I wanted to add a couple of comments inline, but first let me cite what IMO is the key point:

[DOT] You concisely and well summarize the key architectural question and Dyncast is exactly about this! The metric discussion is the one point where the intention is to avoid (too much) application-specific knowledge as much as possible while still allowing for reasonable support for anycast routing decisions. In what’s been discussed so far, I don’t see how application-specific knowledge (beyond binding identifiers for application instances and metrics in a form that is still being discussed) is being widely introduced into the network.
[Luigi] That is exactly the point. Dyncast is not about application-specific knowledge, it is about implementing an anycast model that allows to sending a service demand to the “most appropriate” instance of that service. Dyncast does not care “what” service is, the objective is to provide an architecture that can accommodate any type of service. Obviously we touch topic like “metrics” but it is not about which one to use. The question dyncast is trying to answer from the “metric” perspective is: how to provide a way such that instances (or another entity in their behalf) can state how much are willing to receive more demands and encode such willingness in a service agnostic way.
Dyncast does not touch  the question: “Given a Service and its instances which metrics do or are suitable to  characterize its status?” This question is application-specific and more research oriented. May be COINRG  is the place to discuss it, or may be somewhere else, but not in Dyncast. If you use Dyncast you already answered that question for your service and you want to use the infrastructure provided by Dyncast to implement it.

Other comments inline.

Ciao

L.

From: Dyncast [mailto:[email-masked]] On Behalf Of Dirk Trossen
Sent: Friday, March 12, 2021 16:07
To: Dirk Kutscher <[email-masked]>
Cc: dyncast <[email-masked]>; Joel Halpern Direct <[email-masked]>; Carsten Bormann <[email-masked]>; Milheiro Mendes, Paulo Jorge <[email-masked]>
Subject: Re: [Dyncast] edge capability feedback

Hi Dirk,

Best,

Dirk

From: Dyncast [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: 12 March 2021 15:28
To: Dirk Trossen <[email-masked]<mailto:[email-masked]>>
Cc: dyncast <[email-masked]<mailto:[email-masked]>>; Joel Halpern Direct <[email-masked]<mailto:[email-masked]>>; Carsten Bormann <[email-masked]<mailto:[email-masked]>>; Milheiro Mendes, Paulo Jorge <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dyncast] edge capability feedback

Hi all,

  *   Metric Agent: How realistic is it that OTT services would share that info?
[DOT] we’ve only started discussion on those metrics, even to the point that those metrics may well be simple opaque values, obfuscating semantics, over an agreed action set. Even if they were ‘semantic-rich’, edge services (often done in deeper collaboration with net provider) may well share metrics, given the possible benefits from doing so in terms of performance. It is desired that those metrics are generic (as said, even to the point of being opaque values) to limit application knowledge going southbound.
[Luigi] Applications do not even need to explain the “metrics” to the network layer they just need to provide values that can be used to make a decision. It’s the essence of shortest path, you choses the shortest whether the metric expresses the number of hops, the bandwidth, or latency the algorithm does not care they are just values.

  *   D-Router: Additional per client-state, application knowledge and per-client state in the network -- not sure that's convincing
[DOT] the client state is one of the options discussed in the side meeting, but it’s not the only (and possibly not at all) way to go. Not sure what application knowledge beyond metrics (see above) you are referring to.
[Luigi] “affinity” in different forms is nothing something introduced for the first time by Dyncast. There are ways out there to deal with it. Certainly there is a scalability aspect to take care of, that is one of the reasons the D-Forwarder has been proposed. The discussion is more about what algos exists that answer the affinity requirements of Dyncast? Yes is a tough problem, but it does not mean that it cannot be solved.

[Luigi] I think we are mixing things here. Telcos networks do perform application-related TE, hence some efforts like APN. But it is not related to Dyncast. Dyncast is about service instance anycast, and it is a routing problem.

Best regards,
Dirk

Joel,

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: 12 March 2021 12:43
To: Milheiro Mendes, Paulo Jorge <[email-masked]<mailto:[email-masked]>>; Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Cc: dyncast <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dyncast] edge capability feedback

Yours,
Joel

Cheers

*Dr. Paulo Mendes*

Senior Scientist

*Airbus*

---- AIRBUS AMBER ----

Grüße, Carsten

[1]

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 13 Mar 2021 13:48:30 +0100

On 2021-03-13, at 09:38, Luigi IANNONE <[email-masked]> wrote:
> 
> Obviously we touch topic like “metrics” but it is not about which one to use. 

We do have some requirements, though.

I think the most important requirement on the application-side metric is that it can be combined with a network-side metric in a way that allows to make routing decisions in a d-router.

So, indeed, it cannot encode information that would need application-level knowledge (“business logic”) to combine and compare.  

As I said in the meeting, the obvious metric will be based on latency and its dispersion (variability).  Anything that is compatible with this metric will do, too (so there is space for adding secret sauce, too).

Grüße, Carsten