Re: [Dyncast] edge capability feedback

[Dirk Trossen <[e-mail]>]

Hi Dirk,

Thanks for those comments. Please see inline for comments.

Best,

Dirk

From: Dyncast [mailto:[e-mail]] On Behalf Of Dirk Kutscher
Sent: 12 March 2021 15:28
To: Dirk Trossen <[e-mail]>
Cc: dyncast <[e-mail]>rg>; Joel Halpern Direct <[e-mail]>om>; Carsten Bormann <[e-mail]>rg>; Milheiro Mendes, Paulo Jorge <[e-mail]>
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.

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.

[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

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

-----Original Message-----
From: Dyncast [mailto:[e-mail]] On Behalf Of Joel Halpern Direct
Sent: 12 March 2021 12:43
To: Milheiro Mendes, Paulo Jorge <[e-mail]<mailto:[e-mail]>>; Carsten Bormann <[e-mail]<mailto:[e-mail]>>
Cc: dyncast <[e-mail]<mailto:[e-mail]>>
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:

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 <[e-mail]
<mailto:[e-mail]>> wrote:

On 12. Mar 2021, at 03:29, Joel M. Halpern <[e-mail]
<mailto:[e-mail]>> 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

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

--
Dyncast mailing list
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dyncast
<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.
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.

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