Re: [Dyncast] edge capability feedback

[Dirk Kutscher <[e-mail]>]

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