Episode X: Lord of the Latencies

Authors: Fatih E. NAR Chief Architect at Red Hat, Fatih Baltacı & Kursat Aktas Founders at Ddosify

1.0 Introduction

Network latency ,briefly, is the time it takes for a data packet to traverse from source to destination. In the level of Gandalf wisdom; that is the time between now (where you are) and then (the inevitable end that will serve you).

There are certain factors that impact latency on the network fabric such as; the physical distance between source and destination, number of hops and their contributions to time passing etc. In the network fabric we have algorithms in place to find the best optimal data paths to overcome (or minimize at least) the overhead brought by intermediaries, however we “still“ cannot overcome the physics of nature to shorten the real distance or increase the speed of communication beyond certain limits (speed of light) yet.

Therefore location of the consumer who initiates the transmission is critically important and with 5g we have better leverages on where we deploy applications (edge computing) and how consumers can reach them (edge applications) in better/performant ways to achieve low latency.

Figure-1 Immigrant Hobbits with Multi-Point 5G Edge Infra Coverage in NA

In this study we present a way to observe variable point of origin (i.e. service consumer location can change/vary/shift) network latency.

• Such knowledge can/may guide workload placements to act based on traffic demand, as well as varying traffic origin location, to deliver better consumer experiences.

2.0 Solution

With introduction of service based architecture (sba) by 3gpp and selection and enablement of local break-out, the consumer traffic can be routed from overlay fabric (gtp) and reach desired destination (ie consumer / enterprise applications) in most effective ways. This enabled low latency communications to be realized in the real world with edge computing (Link1).

There are various reasons that consumer experience can vary over time due to changing latency;

1. Due nomadic access, i.e. users change their locations hence mobile coverage varies for signal strength, network load, physical distance to consumed application location.
2. Ever-changing traffic patterns per geo-location, due to nature (rain, storm etc), increasing population (more users per cell), change in physical environment (more buildings), network fabric loads and availability etc.

Figure-2 Latency Factors

When we encounter dynamic latency measurements in application schedulers as well assigned user service location, we would be in charge of the user experience and can manage it based on continuously collected data where data not only tells us about latency but also can help us create insights about our state of end to end 5g solution for scalability , availability and resiliency.

In our solution we gather latency metrics towards each 5g platform with two views:

• Picking the right serving location based on the user’s given/predicted geo-location at given time,
• Creating an alternative serving location list based on changing underlying platform conditions.

We partnered with Ddosify, a platform built for measuring the distributed computing latency at the global scale and load testing the API endpoints. The Ddosify offers three different options for different use cases;

1. Ddosify engine is an open-source, lightweight, high-performance load generator designed for single pane of view load testing.
2. Ddosify checker is a devops tool capable of measuring the latency of an API endpoint across 25 countries.
3. Ddosify cloud combines these two tools (engine and checker) on the same platform. It is a distributed observability platform created for geo-targeted latency & load testing of the API endpoints with continent, country, state and city level breakdowns..

In this study we leveraged Ddosify cloud to dynamically (with variable point of origin) measure the latencies across multiple 5g edge platform locations with respect to programmable edge (i.e. API) endpoints, observing their state of availability.

3.0 Sandbox

Figure-3 Texan Hobbits with Multi-Point latency

We perform 5g edge platform api access latency measurements with respect to current location of request origination vs servicing locations. Based on observed measurements (Figure-3) and current location of a Frodo Ewing (No Baggins in Texas Y’ALL!); he will be served better with low latency in given locations below (in order):

• Dallas TX : 15ms
• San Antonio TX: 24ms
• Houston TX: 33ms

As much as traffic origination point(s) get close to the 5g edge platform, the 5g experience will get better. As much as they go away from 5g edge platforms, the latency will increase. However hobbits might get better latency wrt to from other available 5g edge platforms depending on their direction of journey and their speed.

NOTE: Color Code in Figure-3/4/5 for latency observation locations:

• Green <50ms,
• Orange <100ms,
• Red > 100ms.

Figure-4 Floridian Hobbits with Multi-Point Latency

Say governor blocks 5g edge infrastructure deployment and still you can be served by the closest edge location with a possible low latency, (Figure-4) thanks to “our precious” fiber backbone between States.

Figure-5 Variable Point of Origin Latency Observations — Global Map

We assume so far so good, latency grows based on distance right? Yes and No. Yes it does but not necessarily you are jailed with that limitation (Figure-5). We can create a molecular edge platform replicator (Hub Cluster to Rule’m All) that can clone your edge infrastructure and yet you can use it with a single entry point (Link2). By combining the power of RH-ACM with the sweet strength of anycast ip (Link3) for your distributed edge platforms.

I hear you saying ; our favorite cloud provider offers LBaaS with geo-aware traffic distribution, which might be true in a “statically” programmed fashion, ie there is no continuous latency measurements in place to monitor active platform latencies , all static routing (!), most you can get out is health checks to see if your platform(s) has a heartbeat while having a heart attack, not necessarily telling you your platform will fulfill your needs at that given time.

Would you like to give a try to see the latency to your edge infrastructure around world? Global Edge Latency Tester (<- Link4) is at your service.

4.0 Key Findings

1. Don’t expect too much out of hobbits, they are not usually (at least most of them) adventurous people to travel/move away, they are pretty static. But some of them are pretty restless for travel and can go places not many can dare to, when those do go they need to be taken care of with low latency and that is not a one time job, it is a continuous effort.
2. Hobbits are known for their complaints, if the service degrades or is not satisfied their expectation -> they will fuss big time about it. Hence better to have a good fall-back/redundancy plan.
3. Hobbits are not rich but not poor (they may claim but not necessarily true) either, you need to convince them that what you offer will improve their lives and moods as well.
4. Nature is unpredictable (Gollum/Sméagol variance), better to have a distributed edge(s) with “eyes” on them.

5.0 Closure

“All we have to decide is what to do with the latency that is given us.” — Gandalf

Now it is time to incorporate this “precious” knowledge ring into workload placement policies with a Wizard (coming soon).