Finland has become accustomed to high-speed mobile and fixed broadband connections. Much faster than the EU 'definition of high-speed broadband'. While the 5G marketing machine drums the same formula, "very high capacity and low latency," and another camp wants "fiber for every household," it is worth bringing other aspects of the decision-making into the discussion. It is good that our data network infrastructure in Finland is developing, but for the user, the speed of the application not tied to the network interface bandwidth. It is not worthwhile for anyone to pay. We will be happy to compare the speeds of subscriptions with the testing programs of smartphones and workstations with their default settings. This is an easy way to make sure we got what we paid for. Why then do business applications not seem to speed up despite network investments and promises? In the Internet world, almost all applications that require quality use TCP. In this protocol, the three most important performance-related variables are A) TCP window size, B) WAN transmission delay, and C) TCP packet loss. From this, one can easily calculate the maximum data transfer rate that can be achieved. The default TCP window size is the formula: (65535 bytes * 8 bits / byte) = bandwidth * 0.030 second bandwidth = (65535 bytes * 8 bits / byte) / 0.030 second bandwidth = 524280 bits / 0.030 second bandwidth = 17476000 bits / second An example is a 10Gbps WAN connection between Helsinki and Ireland, where the transfer delay E2E is about 30 milliseconds. The default TCP window size is 64KB (65536 Bytes) x 8 = 524288 bits, which is divided by the transfer delay of 0.030 (30 milliseconds). The best data transfer speed is 17476266 bits per second, only 17.4 Mbps. For example, if your workstation is at 120 ms in India, the maximum data rate is 4.3Mbps. Is the time low for the acquired capacity? To circumvent the initial TCP restriction, TCP Windows Size Scaling has been developed, which can increase the window size to almost 1 GB (GB). This would achieve a 10 Gbps connection, although it is a very theoretical calculation. (10 Gbps * 30ms / 1000sec) / 8bits / byte = window size (10000 Mbps * 0.030 second) / 8 bits / byte = 37.5 MB   Modern terminals and cloud services are thus adaptively and gradually increasing the size of the TCP window to achieve the maximum data transfer rate. In practice, it is not possible to provide or want to offer a very large window size due to other factors. One of the biggest challenges is the packet loss of the WAN network. If the packets are dropped from the paths of the onboard devices (like the unnecessary traffic, the incorrect configuration, or the prioritization of other applications) all the packets need to retransferred, this, in turn, significantly reduces the transfer rate. 2% packet loss drops the throughput by 6 to 25 times, depending on the transfer delay.  Another challenge is the TCP stack of the old terminal and the ability to buffer data that requires a considerable amount of central memory allocation and processing power. The business world, and especially the replacement of industrial production systems, is not realistic with a fast schedule, even though network capacity is available. TCP Windows Scaling is also not supported on old operating systems. A third challenge is a large number of simultaneous users of shared cloud services. 100% of resources cannot be allocated to one user or application. This is easy to verify with a network analyzer. In midsummer, I had a connection from the mobile. I transferred a 1GB compressed file from the public cloud to my workstation. My workstation is constantly proposing a much larger TCP window size, but the cloud service does not raise the value requested. The latency is about 130ms. My actual mobile subscription is 100Mbps, but the reality is about 0.5Mbps.

Is a 5G small latency true or just a marketing speech?

5G technology is often annealed as a low latency technology. Unfortunately, with the current cloud architecture, the benefit of 5G radio transmission delay or improvement to 4G is nonexistent. 99% of the transfer delay from Azure or AWS to the cloud is still remaining after the 5G transition. The TCP protocol works as in the example above, and the formula can easily calculate the final result. Thus, with the current cloud architecture shift, 5G does not change the performance of the application on the terminal, even if the speed of the interface and the result of the test program "speed test" are large. The transmission delay is only reduced by processing the application closer to the terminal and the usage event. This is called Edge Computing. For example, in an Ethernet local area network (LAN), the transmission delay is well below one millisecond (5-125 microseconds), packet loss, and delay variation are non-existent. The application control that requires fast response and processing has been implemented with local server processing and LAN over the last 25 years. Thus, Edge Computing is not a new concept but is rapidly evolving to expand cloud architecture to a seamless overall solution. As part of 5G technology, it is possible to implement the Edge Computing concept. However, I am quite skeptical about the possibilities of its implementation, especially in B2B solutions. Transferring the partial processing of industrial automation to host a local 5G operator and integrating it into a public cloud solution in the field of international business seems reasonable in terms of both technical implementation and contract law. Transferring application processing from a local network to a radio network does not improve the transmission delay but weakens it. In addition, the processing should work even if the WAN network is down. When 5G interior coverage significantly increases costs and there is probably a slightly different implementation model in each country, it is difficult to find a business case. For Consumers, 5G Edge Computing will be found in some time as an application for a mobile terminal.

Stick to The Hat - Optimize Your Network and Its Cost

In network optimization, latency, TCP window, and packet loss mean more. Here are four important things to get the best experience and cost optimization.
  • For SD-WAN solutions, you should not only consider the speed of the local Internet connection but the quality of the connection and the traffic profile. Internet capacity alone is not a guarantee of overall application speed.
  • Before planning to make larger decisions, you should be familiar with the traffic profile and the application's behavior when designing the WAN network. The WAN network is a large fixed cost for the company. Knowing the need and facts can save you a lot of money.
  • For WAN quality, packet loss and delay variation should be monitored or reviewed at least regularly. Even a small repair can significantly improve the user experience.
  • It is advisable to consider carefully the capacity of corporate mobile users with over 50Mbps subscriptions.
Hannu Rokka, Senior Advisor 5Feet Networks Oy