How To Make The Most Of Real-Time Applications

What does it mean for an application to be “real-time”? A technical definition might say that the program’s data must be processed within fractions of a second, so that it can be made instantly available as feedback. In an age of ubiquitous high-speed connectivity – from MPLS and broadband in the office, to 4G LTE connections on the go – end users have come to expect real-time performance from almost all applications, whether or not they are technically “real-time.” Attention spans are short, and company WANs and application designers are struggling to keep up and provide the best possible user experience.

To see how high expectations for performance have risen, look no further than the digital news industry. When Facebook launched its self-hosted, native Instant Articles service last summer, it did so by noting that traditional news articles take an average of 8 seconds to load on the mobile Web, an interminable amount of time for readers who are prone to abandon the endeavor for something else. News readers are not real-time applications, but their users now expect virtually instant feedback.


Ensuring real-time performance requires a lot of dots to be connected.

Companies everywhere have long faced similar challenges in ensuring top-notch performance for VoIP, video, UC and other truly real-time programs. But instead of redesigning applications from the ground up as Facebook, Apple (Apple News) and others have done with news services, they often look to make changes at the wide area network (WAN) level in order to improve application speed, reliability and uptime.

The stakes for real-time performance across the WAN

When something goes wrong with your email or Twitter client, the issue is often with the service provider or with some tiny flaw in the application’s design. Problems with apps such as VoIP, in contrast, typically come down to a bottleneck on the WAN: insufficient bandwidth, excessive packet loss or significant latency can all jeopardize their performance.

“VoIP is dependent on everything else.”

These setbacks would simply slow down a non real-time app, but they render real-time ones unusable. For example, consider the technical details of VoIP implementation. It is dependent on so many things and there is little room for error from the get-go: Anywhere from 60 to 80 milliseconds of delay is usually a given, due to the sheer number of packets flowing in each direction of the connection.

This number then has to be placed alongside the similar slowdowns associated with protocols, codecs, routers and other applications on the network, as Phil Edholm explained for No Jitter. Utilizing PSTN or conference bridging to join IP networks further pushes things back and can bring VoIP to the edge of non-interactivity, even on a relatively low-delay network. People might be talking, but they won’t be having a conversation.

These are the constraints that network admins have to keep in mind as they consider the future of their WANs and how VoIP et al will be properly supported on them. It’s a fine line between crisp voice quality and unbearable lag or even regularly lost connections. Making the most of real-time apps will require:

  • Adequate network capacity, attainable through aggregating MPLS, broadband Internet and other links together.
  • Full access to all available circuits, even those earmarked for disaster recovery, for the most demanding applications.
  • Smart policies and prioritization mechanisms that adjust in real-time for apps like VoIP and video.

Some software defined WANs offer all of these capabilities toward the end of ensuring real-time performance. At the same time, they provide a reliable foundation for non real-time applications, too. Expectations for business applications are higher than ever, but meetable with smart solutions such as Talari’s THINKING SD-WAN.

Categories: Software Defined WAN (SD-WAN), WAN to Cloud