Latency 101: Getting From There to Here
Welcome back, once again, to the CableLabs 101 series! In our most recent post, we discussed the fiber portion of the hybrid fiber-coax (HFC) network, as well as the coherent optics technology that’s widely considered to be the hyper-capacity future of internet connectivity. Today, we’ll focus on a topic of growing importance for many of the new applications in development—a topic that significantly impacts the user experience even if it’s not well known. That topic is latency.
What Is Latency?
Simply put, latency means delay.
In our post about coherent optics technology, we pointed out how quickly light can travel through a piece of fiber-optic cable: an astonishing 128,000 miles per second. However, as incredibly fast as that is, it still takes time for light to carry information from one point to another.
Imagine for a moment that you’re reading this blog post on a computer in New York City. That would mean you’re about 1,600 miles away from the CableLabs offices here in Colorado. If we assume that the entire network between you and our offices is made of fiber (which is close enough to true for our purposes), it would take a minimum of 0.0125 seconds—or 12.5 milliseconds (12.5 ms)—for the text to travel from our server to your computer.
That’s not a lot of time, but distance is not the only source of delay—and those delays can add up.
For example, to read this post, you had to click a link to view it. When you clicked that link, your computer sent a request to our server asking for the article. That request had to travel all the way to Colorado, which also took the same minimum of 12.5 ms. If you put the two times together, you get a round-trip time (the time it takes to go somewhere and back), which in our case would be a minimum of 25 ms. That’s a longer amount of time, but it’s still pretty small.
Of course, the server can’t respond instantly to your request. It takes a moment for it to respond and provide the correct information. That adds delay as well.
In addition, these messages have to traverse the internet, which is made up of an immense number of network links. Those network links are connected by a router, which routes traffic between those links. Each message has to hop from router to router, using the Internet Protocol to find its way to the correct destination. Some of those network links will be very busy, and others won’t; some will be very fast, and some might be slower. But each hop adds a bit more delay, which can ultimately add up and become noticeable—something you might refer to as lag.
Let’s try a little experiment to illustrate what we’re talking about.
If you’re on a Windows computer, select Start, Programs, Accessories, Command Prompt. Doing so will open up a window in which you can type commands.
First, try typing the following: ping www.google.com
After you hit Enter, you should see some lines of text. At the end of each line will be a “time” in milliseconds (ms). That’s the amount of time it took for a ping request to get from your computer to Google’s server and for a response to come back, or the round-trip latency. Each value is likely different. That’s because each time a ping (or any message) is sent, it has to wait a small but variable amount of time in each router before it’s sent to the next router. This “queuing delay” accumulates hop-by-hop and is caused by your ping message waiting in line with messages from other users that are traversing that same part of the internet.
Next, try typing the following: tracert www.google.com
You should see more lines of text. The first column will show a hop number (the number of hops away that point is), the next three will show times in milliseconds (since it checks the latency three times) and the final column will show the name or the address of the router that’s sending you the message. That will show you the path your request took to get from you to the Google server. You’ll notice that even as close as it is (and as low as your latency might be), it had to hop across a number of routers to get to its destination. That’s how the internet works.
(Note that you might have some fields show up as an asterisk [*]. That’s not a problem. It simply means that the specific device is configured not to respond to those messages.)
If you’re on a Mac, you can do the same thing without needing a command prompt: Just search for an application on your computer called Network Utility. To send a ping in that app, click on the Ping tab, type in www.google.com and click the Ping button. Similarly, to check the route, click on the Traceroute tab, type in the same website name and click the Trace button.
What Is Low Latency?
A term you might have heard is low latency. This term has been getting more and more attention lately. In fact, the mobile industry is touting it as an essential aspect of 5G. But what exactly is low latency, and how does it relate to our definition of latency?
The reality is that there’s no formal definition of what qualifies as low latency. In essence, it simply means that latency is lower than it used to be, or that it’s low enough for a particular application. For example, if you’re watching a streaming video, low latency might mean having the video start in less than a second rather than multiple seconds.
However, if you’re playing an online game (or perhaps using a cloud gaming service), you need the latency to be low enough so that you don’t notice a delay between moving your controller and seeing the resulting movement on your screen. Experiments have shown that anything above about 40ms is easily noticeable, so low latency, in this case, might mean something even lower than that.
How Do We Achieve Low Latency?
Reducing latency requires us to look at the sources of latency and try to figure out ways to reduce it. This can include smarter ways to manage congestion (which can reduce the “queuing delay”) and even changing the way today’s network protocols work.
Reducing latency on cable networks is something CableLabs has been working on for many years—long before it became a talking point for 5G—and we’re always coming up with new innovations to reduce latency and improve network performance. The most recent of these efforts are Low Latency DOCSIS, which can reduce latency for real-time applications such as online gaming and video conferencing, and Low Latency Xhaul, which reduces latency when a DOCSIS network is used to carry mobile traffic.
How Does Low Latency Affect Me and My Future?
Achieving low latency opens the door to do things in near real-time: to talk to friends and family as if they were close by, to interact in online worlds without delays and to simply make online experiences quicker and better. In the long term, when combined with the higher-capacity networks currently in development, low latency opens the door to new technologies like immersive interactive VR experiences and other applications that have not been invented yet.
The future looks fast and fun.
Enabling the Cable Networks for Mobile Backhaul
With 5G and small cell densification on the near horizon, mobile networks need economically viable backhaul solutions. Cable operators are well positioned with fixed networks to bridge that gap, and many operate mobile networks themselves. Could we be on the verge of fixed-mobile network convergence? Things seem to be pointing in that direction, but it won’t happen without technology developments to make DOCSIS and LTE networks compatible.
A big element of this compatibility is aligning the typical network latency between DOCSIS and what is required for backhauling LTE. Today’s DOCSIS upstream access latency is higher than the allocated budget (Fig 1) and solving the latency problem is key to enabling cable networks for mobile backhaul.
Our solution: together is better
About a year ago, a lightbulb moment led to a solution which led to a joint project between CableLabs and Cisco that I wrote about last October. You can read about it here.
To recap, instead of operating as two independent networks, we want to coordinate the DOCSIS channel access procedure with information made available by LTE, so that the DOCSIS process can start while the LTE transactions are still going on. When two systems work hand-in-hand, we achieve better end-to-end latency. (Fig 2)
With the CableLabs team supplying expertise in mobile and John Chapman’s (Cisco Fellow and CTO Cable Access) team developing the pipelining API on the CMTS, we jointly built a proof-of-concept (PoC) using open source LTE small cells and the Cisco cBR-8 CMTS.
What we have been working on
Since my blog last October, we have been working on characterizing DOCSIS latency with increasing load on the DOCSIS channel. Using the pipelining method, the series of ping packets we sent from the User Equipment (UE) achieved an upstream latency of ~1-2 ms on the DOCSIS link (Fig 3). The latency remained consistent when we loaded up the DOCSIS link with other upstream traffic of up to ~60% of the channel capacity. Above this loading point, the latency gain with our pipelining method became more significant compared to no pipelining, albeit creeping above the 1-2 ms range.
At this point, skeptical readers might be wondering, what’s the penalty for sending the LTE scheduling information across the DOCSIS link? We coded our LTE scheduler to send a “Bandwidth Report” (BWR) messages every 1 ms. A 80-byte BWR message, therefore, incurs 640 kbps, a minute amount compared to DOCSIS speeds that are now in the multi-Gbps range.
On the other hand, it is possible that the data predicted by the LTE scheduler might not actually arrive at the DOCSIS link, causing under-utilization of the DOCSIS grants. So, how many DOCSIS grants are issued by the CMTS but are not used with the BWR method? We performed tests and observed a respectable number. We will be reporting more on the upcoming webinar (details see below).
We have also been working on a fronthaul setup. Initial results showed that more latency gains can be expected with BWR compared to backhaul. More on that later.
- We have been demonstrating the proof of concept to CableLabs members since last summer. CableLabs and Cisco will once again hold a joint demo at the upcoming Mobile World Congress.
- The joint team is wrapping up the PoC work. We worked together on perfecting the pipelining operation and designing the new BWR message. We will take this baseline design to the CableLabs Mobile Backhaul Working Group that I am currently leading. Given the interest from CableLabs members, my goal is to get LTE and CMTS vendors together to agree on protocol and message details, so that cable operators can get the latency benefit regardless of which LTE and CMTS equipment they choose to deploy.
- Additionally, in building the PoC, we have accumulated expertise on how to perfect the BWR algorithm to optimally predict the amount of data and time egressed from the LTE side. We will pass this knowledge on to the LTE implementers during the specification work.
I am holding a webinar with John Chapman on Thursday, February 15th at 8am Pacific / 11am Eastern / 5pm Central European Time. It is open to the public and we hope to see you there.
For those of you attending Mobile World Congress, I am holding a joint demo with John Chapman at the Cisco booth number 3E30, Hall 3 Hybrid Hall.