There is currently a big debate about technologies employed when using Keyboard Video Mouse (KVM) systems to connect expert users in control rooms or engineering centers with remote, back-racked server- or PC-targets. At its core, it appears to be a technology discussion. Traditionally, KVM systems employed a dedicated network for the connection of users and targets and used a proprietary communication protocol, optimized for the various applications and needs of customers to control and manage the KVM system as well as the target applications and systems.

More recently, systems using the Internet Protocol (IP) as the transport mechanism carrying KVM payload information are promising lower cost of purchase through “Commercially Off The Shelve” (COTS) available equipment providing larger economies of scale and lower “cost per transported bit” at the time of purchase. When acquiring systems with an expected lifetime of over seven or ten years, a proper commercial evaluation has to take into account capital (CAPEX) and operational (OPEX) expenditures. As such, it is much less a technology and much more a commercial, in some case a philosophical discussion.

This discussion is fueled by a number of key hypothesis to take into account when planning and selecting a KVM solution.

1. Technically, KVM systems can be separated into two technical solutions which are very close to each other in terms of system performance.
2. Commercially, open standard solutions typically offer lower cost of acquisition (larger markets provide better economies of scale).
   a. Lower capex for IP based systems.
   b. Difficult to assess, hidden operating cost during system lifetime.
   c. Some customers don´t take this total cost of ownership (TCO) into account.
3. KVM systems support a wide variety of applications with varying needs of security.
   a. Public safety and military applications.
   b. This is now expanded to include what is coined critical infrastructures (public safety, military, power and water supply, core telecommunication infrastructures).
   c. Mission critical commercial process control in nearly any industry vertical.
   d. Non mission critical commercial and governmental applications (office infrastructures with limited real-time needs).
4. Increasing number of cyber-attacks within connected IP networks (aka the Internet), generally increase the risk of wide area and large-scale network outages.
5. Most cyber-attacks exploit technical and human or process vulnerabilities and are, as such, difficult to defend against.
6. Increasing number of intelligent devices with automatic machine communication (IoT, IIoT, M2M communication, autonomous driving, etc.) increases traffic volume and mixes physical and logical network infrastructure thus increasing the overall risk of being a victim of a successful attack.
7. The discussion about technology selection is more driven by the needs of suppliers not the needs of users and customers.
   Let us take a closer look:

Addressing Hypothesis 1

KVM system performance is often evaluated on the basis of these points:

1. How easy is it to connect various types of sources and source applications?
2. How many endpoints are supported?
3. What is the latency/round trip delay of the system from the perspective of the user?
4. How long does it take to switch from one target application to another?
5. Which video standards and resolutions/framerates are supported?
6. Which serial data connections (USBx.y) are supported?
7. Which APIs of proprietary equipment are supported?
8. How flexible is the control switching to accommodate various workflow requirements?

As usual, the devil is in the detail. That said, small differences can have a huge impact. Lets look at scalability for instance. In a dedicated system like the IHSE Draco switch, each switch is designed to host a maximum number of inputs and outputs. Going one above the maximum requires a new chassis. In an IP based system, this can become a challenge to understand as various inputs can share switching capacity. System performance becomes a question of number of inputs and current load on each input. This can lead to congestion, in which case the switch manufacturer´s packet drop/congestion algorithm kicks in. To avoid this situation, each input and traffic type must be assessed carefully upfront and the maximum load needs to be factored in. If you want to avoid spending that safety margin in the bandwidth, connectivity becomes a function of traffic parameters and statistics.

Congestion scenarios and subsequent switch or router behavior have to be evaluated and agreed prior to system implementation. This is critical as switch congestion amounting to buffer overflows lead to dropped packets. In order to maintain overall operation by the switch infrastructure understanding the employed congestion management, the impact on various traffic types and the statistical expectations for overload situations occurring drive the IP switching system configuration and throughput design.

This IP based concept also makes scalability predictions much harder. Yes, theoretically, IP based systems are infinitely scalable. In reality, varying network load and additional endpoints/target devices may overload parts of the IP switch structure and appropriate scaling may require a much larger network re-shuffle than one would expect based on the additional load applied. Such matters are further complicated when sharing the IP network with other applications than the KVM system. At that point, non-mission critical traffic may drive switching congestion and hopefully the switch parameters have been set accordingly.