Remember the good old days? When transporting audio was no more complicated than plugging in a T1 or dialling up on ISDN? Data (and clock) went in one end and generally came out the other end in an orderly fashion, no great drama.
The upsurge in IP and the availability of lower cost bandwidth has, for some time now, promised a new level of performance at a fraction of the cost. Being able to connect to literally anywhere with automatic routing has proven a great leap forward. Having to co-exist with all the other traffic on the net brings its own individual challenges however � namely the absence of delivered clocks (more of an IP issue than the internet per se), high levels of jitter in received data, out of order deliveries or a much higher likelihood of data not even being delivered.
As manufacturers develop new and better ways to exploit this new bandwidth though, things have been settling down in terms of reliability. Some of the top-end units can send and receive data with such high reliability as to be almost mundane but looking under the hood uncovers a complex world of packet replicators, re-sequencers, streaming diversity, payload forwarding, distributed intelligence and everything in between. Now, if you�re like me, what I don�t understand makes me nervous � and tends to leave me floundering for manuals when it goes wrong.
So, in an effort to make a little more sense of it all, this and upcoming blogs will take a look at this toolbox of new technologies � explaining how they work, what’s good (and not so good) about each of them and how best to tailor this toolbox to suit the needs of particular applications. For each �tool�, as with everything, the quality of implementation will vary from manufacturer to manufacturer but it’s the technology itself that we�ll focus on, how it works and what differentiates the good tools from the great tools.
Side-note: For me, a good tool performs its task in the application(s) it was designed for and can improve delivery reliability to a greater or lesser extent. A great tool delivers significant improvements in performance as a minimum, is data agnostic, works�without compromising quality or latency and doesn�t impose restrictions on either the data being transported or require specialist hardware to work. Generally, it will favour open standards (RTP for real-time audio etc) so as to maximize interoperability and present the best chance of being applied to multiple applications.
So let’s start by looking briefly at what, for me at least, has proven to be one of the great tools of the recent past – packet replication – that has seen such success as to be adopted by pretty much all IP transport manufacturers in some form as well as integration into formal standards (the SDP profile specifications used in SIP, for example, have been updated to include packet replication in its supported streaming modes). It has seen great success for dropped packet protection in open Internet applications but also in LAN applications where seamless link redundancy is required.
PACKET REPLICATION AND THE MULTIPATH METHOD: �
Again, while the quality of the implemented feature varies from one manufacturer to another, there is little doubt as to the effectiveness of the multi-path solution for networks running open internet and network path redundancy�solutions. The idea, brilliant in its simplicity, is founded on the basis that if one network offers, for example, 1% packet loss performance (99 percent delivery reliability), then the same packet sent over 2 such networks, offers 0.01 percent (1 percent of 1 percent) packet loss performance � or 99.99 percent uptime assuming that the 2 networks share no routers or other resources and the performance of the two is not related.
In situations where completely independent network paths cannot be achieved, stream diversity algorithms can �inject� diversity at the encoder unit to improve things but it does leave the network vulnerable to outages where the outage occurs at a node(s) that is common to both streams.
At the receiver, as the payload of each received packet is identical in its content, the stream is re-built packet by packet using data from any of the stream(s) being received � normally on a first-come-first-served basis. Done correctly, this solution should add no additional latency to an IP link and should allow the quality / bitrate to be set higher than would normally be possible on the individual links. It�s the opposite of the more traditional multi-homing solutions where only one copy of the stream is split over multiple connections and the load is balanced based on the performance of each line.
From personal experience � packet replication provides excellent WAN performance. I�ve seen an open-internet link from Belfast to Miami (which is a brutal line to run a single link on) run flawless for months even though each of the individual lines recorded thousands of dropped packets and Loss of Connection events.
For LAN installations (where individual dropped packet events are not so much a concern, it�s the links themselves that need protecting), a �simple� 1+1 link multi-path setup offers complete link redundancy for 24 / 7 operation.
Note: one of the nice �side-effects� of the packet replication technology include the opportunity to schedule maintenance on one of the lines without affecting the on-air signal � means they don�t have to be scheduled for 2am, which can make things a little easier.
And, yes, as with all great technologies, because it�s a standards-based (RTP) technology it can be transplanted onto some of the upcoming �AES67 technologies� � Ravenna, Livewire, WheatNet etc.
�
