Re: [Dyncast] edge capability feedback

[Tianji Jiang <[e-mail]>]

>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" <[e-mail] on behalf of [e-mail]> 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]>om>; 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