TI API: DNS cache

[FabrizioMoggio]

Problem description for the traffic flow, to be redirected to the Edge, if the application always use the same FQDN, it is a task of the Edge DNS to associate the FQDN to the IP address of the local EAS Instance. This mechanism doesn't work if the App Client caches the DNS resolution

Expected action improve the TI API documentation

Additional context https://github.com/camaraproject/EdgeCloud/discussions/292

[gunjald]

I think in context of TI API we may need to talk about two scenarios. 1) When the Application Client on UE say an Android Application triggers a TI query, 2) When any other app say a cloud based application triggers the TI API for a given UE.

In 1), the Application Client source code has the logic that it has initiated a TI API and based on successful outcome it may expect the DNS query response will be updated with the target EAS instance though it is subjective that how long it can take the network to update. But from application client perspective it may need to keep trying sending the query till the received response contains the EAS IP which is different than the EAS IP it was earlier using.

In 2nd scenario, if the 3rd Party App fires the TI API for a UE I would expect that there is custom APIs which the Application client might be using to talk to 3rd party cloud Application and the cloud App will need to indicate the Application client to start the DNS query as the EAS IP may be changed due to TI API invocation and DNS cache will be updated soon. From this point onward the same behavior will be expected at Application Client as described in scenario 1 above.

Though this is my understanding that how TI API flow will work specially from the app client perspective but would like to know if this is correct or I am missing something? But one of the key point is that the network DNS is assumed to be updated as part of the TI API implementation to reflect the IP address of the EAS for application FQDN used by the app client on device.

[FabrizioMoggio]

Both the scenarios seem correct to me.

About the DNS update, I don't see how this is a task of the TI API.

The TI API leverages on the presence of an EAS instance up and running, with all the configuration needed, in the Edge Data Network.

When the EAS is installed, its endpoints must be exposed and the DNS must be configured for it to be usable. This must be done when the application is deployed and activated. This action must be performed if the Application is exposed via Internet (Public DNS configuration) or at the Mobile Network Edge (Edge DNS configuration). If a DNS configuration procedure is not active on the "deployment and activation" workflow, the Application will be never reached (independently by the TI API).

Is not suck a task (DNS Configuration) foreseen in the Edge Cloud API for application deployment? Not part of the NBI but part of the SBI obviously.

[gunjald]

So with last answer there comes an implicit requirement that the EAS DNS entries are updated in the network as part of the App LCM API which is though not specified and that may also need a discussion. In that case yes the DNS update may not be part of the TI API.

But now it seems there is some confusion that I am facing in my mind possibly due to some point I am missing in my understanding and would try to describe below,

Assuming that the EAS IP was updated in the network DNS and I am developing an application client which statically knows that the EAS instances are available in certain locations. In that case I can simply write the code to fetch the current location of the UE and compare it with the known static location to figure out the availability of an EAS instance. Then i can simply trigger Application Endpoint Discovery API which should return the EAS endpoint information. And now the application client can send the traffic to this EAS instance without the TI API.

But this may be wrong somewhere and there is few scenario I might be missing which may not be served by SED API and where the TI API is playing a role. Could you please indicate where in above flow the TI API is expected to be used?

[FabrizioMoggio]

It is a Telco Operator choice:

1) the Telco can open the UPF routing to everyone just with a simple network auto-IP configuration where the UPF knows about the EAS IP and routes every request accordingly. No TI API is needed. The Developer (say Netflix) can not differentiate between Standard and Premium users.

2) the Telco doesn't allow the transparent routing in the UPF and the UPF only routes toward that IP if a specific configuration is active. The TI API is required. The Developer (say Netflix) can now differentiate between Standard and Premium users. Standard users go to the Cloud service instance, Premium users go to Edge Service instance

The idea of the TI API is to enable the second scenario leveraging on network resources to provide to the Developer (say Netflix) some additional features, in this case having premium and standard users with different quality of service.

Then the TI API also move the UPF anchor point (data session) in the Edge UPF closer to the EAS. But this is another story.

[gunjald]

Talking about 2nd point "the Telco doesn't allow the transparent routing in the UPF and the UPF only routes toward that IP if a specific configuration is active. The TI API is required. The Developer (say Netflix) can now differentiate between Standard and Premium users. Standard users go to the Cloud service instance, Premium users go to Edge Service instance".

In my opinion the point of discussion Is that there is an ongoing traffic from the UE to say cloud application with a pair of source and destination IP. The presumption is that the IP packet should contain the destination IP (say IP1) with value that is assigned in some way to hosting environment of the cloud application e.g. Public IP assigned to a VM.

Now we bring in the same application to telco edge cloud environment and label it as EAS but for obvious reasons the IP assigned to this EAS instance on edge is say IP2 and "IP1 ≠ IP2".

My understanding is that in normal circumstances the destination IP present in the IP packet originating from UE should be IP1 when it is to be sent to cloud app and IP2 when it is to be targeted for EAS on edge cloud. The key point is that UE app is aware to whom it is sending traffic to i.e., to cloud app or to EAS and accordingly it is using the correct IP. This is where the network routing will easily deliver the packet without having a need to modify any IP header in the packets originated from UE. But in my opinion this scenario can be implemented by SED, DNS or App Endpoint discovery API by application client and I think we are aligned that TI API is not needed in this case.

Now where I may have assumed the role of TI API is in the hypothetical case when UE is say, in an ongoing session with a cloud app at IP1 and it is detected by either the cloud app or the application client that it can be served by the edge instance of the application i.e. EAS.

So the TI API is triggered with the traffic filter pointing to port of the cloud app and also the EAS identification information as defined in the API. Now my understanding was that it is the TI API implementation which would have triggered the specific traffic shaping functions in the mobile network which would have filtered out the traffic stream with the specified port given in the TI API for the given user and performed the two functions on the stream i.e., 1) change the destination IP from IP1 (cloud app) to EAS IP IP2 and 2) Route the modified filtered packets to the EAS. Please note that it is assumed that the packet delivered to EAS will have the destination IP as IP2 where it is listening to and that is the reason IP packet modification is needed from IP1(cloud app) to IP2 (EAS).

In the description above the key was that UE is not aware of the fact that where the packets are being processed i.e. at cloud or at telco edge. The entity which is invoking the TI API is having the responsibility to detect the change in UE location and based on this trigger the TI API and rest everything is in some way taken care by the TI API implementation which has the capability to communicate with network and configure the required network functions.

[FabrizioMoggio]

How the Application manages and configurates the flows is out of scope of the TI API whose only role is to configure the UPF to allow a traffic for a certain user to a certain EAS and move the anchor point of the UE to that UPF. I don't get why we are considering how the Service targets the right EAS? There can be many methods, the Developer will choose the best one according to the requirements of the Service. The main exposed Intent is: "activate the optimal routing for the closest EAS instance". How to "point" to that Instance is not in scope. In my mind that information was already known by the Application, because the EAS Instance was deployed via the Edge Cloud APIs but maybe, for some reason, also related to the network, the chosen EAS, in that very moment, could not be the one retrieved by the other EdgeCloud APIs. For this reason we should provide back the EAS IP address. This should solve any problem and it will be clear for the Developer what to expect.

Issue: https://github.com/camaraproject/EdgeCloud/issues/294

[gunjald]

I think now I am getting the actual meaning of the statement "activate the optimal routing for the closest EAS instance" from your comment. It means to me the application client is always aware of the destination IP of the EAS by various means like SED or App discovery or DNS or UNI which fixes the traffic endpoints between UE client app and the backend server or EAS.

And via the TI API there is a promise that the endpoints given above are fixed but the API will try to find a better route in the network by configuring the mobile network in some way that could be UPF rekselection or any other similar thing. Though it is not too intuitive to understand what happened internally but the impact could be more visible to end customers of the application in terms of the user experience if there is a perceived change.- And yes now with this understanding it is much clear that app client is aware of the EAS IP or port information before firing the TI API so there is nothing like IP translation kind of functionality really needed in context of TI API as i have previously written.

But technically speaking if the above understanding is correct then I think we need to slightly update the API description to make it more clear to developers on what they need to take care of while using the TI API.

[FabrizioMoggio]

I totally agree on improving the documentation to better specify what to expect. Introducing the EAS IP (https://github.com/camaraproject/EdgeCloud/issues/294) as returned variable also provide a way to add more documentation about the UE Client being the one that must point to the right IP.

[gunjald]

Now we are fully aligned :-)

To me the following description is just one way to convey what we have discussed "The generic architecture for the Service can foresee some Cloud instances of the Application, one or more Edge Instances of the Application. The TI API Consumer invokes the TI API creating a "TrafficInfluence" resource specifying the desired intent."

A suggestive change could be to above text, "The generic architecture for the Service can foresee some Cloud instances of the Application, one or more Edge Instances of the Application. The TI API Consumer invokes the TI API creating a "TrafficInfluence" resource that may include EAS identification information e.g., appId, edgeCloudZoneId etc along with the optional sourceTrafficFilters destinationTrafficFilters information to indicate the specific traffic flow to be optimally routed from UE to EAS in the network"

Of course the above suggestion is just indicative one from my side on what I will expect as API consumer but you may check any other way to include such intents from developer perspective.

[FabrizioMoggio]

Fixed with: https://github.com/camaraproject/EdgeCloud/pull/311

[FabrizioMoggio]

PR merged