Re: [Dyncast] edge capability feedback

["Milheiro Mendes, Paulo Jorge" <[e-mail]>]

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]> wrote:

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