Greg Shay Archives – The Broadcast Knowledge

As video infrastructures have converged with enterprise IT, they started incorporating technologies and methods typical for data centres. First came virtualisation allowing for COTS (Common Off The Shelf) components to be used. Then came the move towards cloud computing, taking advantage of scale economies.

However, these innovations did little to address the dependence on monolithic projects that impeded change and innovation. Early strategies for Video over IP were based on virtualised hardware and IP gateway cards. As the digital revolution took place with emergence of OTT players, the microservices based on containers have been developed. The aim was to shorten the cycle of software updates and enhancements.

Containers allow to insulate application software from underlying operating systems to remove the dependence on hardware and can be enhanced without changing the underlying operational fabrics. This provides the foundation for more loosely coupled and distributed microservices, where applications are broken into smaller, independent pieces that can be deployed and managed dynamically.

Modern containerized server software methods such as Docker are very popular in OTT and cloud solution, but not in SMPTE ST 2110 systems. In the video above, Greg Shay explains why.

Docker can package an application and its dependencies in a virtual container that can run on any Linux server. It uses the resource isolation features of the Linux kernel and a union-capable file system to allow containers to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines. Docker can get more applications running on the same hardware than comparing with VMs, makes it easy for developers to quickly create ready-to-run containered applications and makes managing and deploying applications much easier.

However, currently there is a huge issue with using Docker for ST 2110 systems, because Docker containers do not work with Multicast traffic. The root of the multicast problem is the specific design of the way that the Linux kernel handles multicast routing. It is possible to wrap a VM around each Docker container just to achieve the independence of multicast network routing by emulating the full network interface, but this defeats capturing and delivering the behaviour of the containerized product in a self-contained software deliverable.

There is a quick and dirty partial shortcut which enable container to connect to all the networking resources of the Docker host machine, but it does not isolate containers into their own IP addresses and does not isolate containers to be able to use their own ports. You don’t really get a nice structure of ‘multiple products in multiple containers’, which defeats the purpose of containerized software.

You can see the slides here.

Watch now!

Speaker

Greg Shay
CTO
The Telos Alliance

NAB 2019 saw another IP Showcase with plenty of talks on the topic on many people’s minds: PTP and timing in IP systems. It seems there’s a lot which needs to be considered and, truth be told, a lot of people don’t feel they have the complete list of questions to be asking and certainly don’t know all the answers.

So, here, Greg Shay from Telos talks about the learnings from his extensive experience with timing IP signals and with PTP under SMPTE 2059. He hits the following topics;

Must you always have a GPS reference for the PTP master?
Are PTP-aware switches always necessary?
Can you safely not use PTP Peer Delay requests / responses?
What is the effect of internal oscillator tolerance and stability when designing PTP client equipment?

To my ears, these are 4 well placed questions because I’ve heard these asked; they are current in the minds of people who are grappling with current and prospective IP installations.

Greg treats gives each one of these due time and we see some interesting facts come out:
You don’t always need a time-synchronised PTP master (pretending to be in 1970 can work just fine).
Compensating for PTP Peer Delay can make things worse – which seems counter-intuitive to the point of PTP Peer Delay requests.
We also see why PTP-aware switches matter and a statistical method of managing without.

This is a talk which exemplifies IP talks which ‘go deeper’ than simply explaining the point of standards. Implementation always takes thought – not only in basic architecture but in use-cases and edge-cases. Here we learn about both.

Watch now!

Speakers