MCS was designed from the outset to deliver a secure web service solution, out of the box, with no reliance on any additional external applications or system services.
This approach enabled the MCS solution to deliver an integrated web and data services architecture, such as browser access anywhere/everywhere, while removing threats associated with support of server scripting, binary execution, fraudulent URLs and other operating system threats exposed through access to OS data layer assets. Penetration attacks that are so common to commercial web-server applications cannot impact MCS because of its secure web framework.
The MCS satellite architecture extends MCS testing services across any size of global/cloud network. Delegating testing services (client or server roles) to MCS satellite applications, allows the MCS solution to adopt the same integrated web architecture benefits afforded to MCS. This approach allows the MCS management application to reside in a private (client or server) and secure network domain, independent of and isolated from the higher threat of public domain deployments.
The MCS Satellite architecture was designed to deliver a cost-efficient secure software and hardware solution. The MCS Access Series hardware satellite was uniquely designed to deliver MCS compatible server/client testing services, embedded on a single solid-state platform, devoid of any commercial operating system. Eliminating the operating system layer, and with it, the additional threat layers such as, file system, executable binaries, scripts, utilities , sensitive system data and memory assets, delivers a testing platform that is safe from the significant threats that target and virally spread directly from commercial OS platforms. The Embedded satellite design allows MCS Access Series satellites (server and client) to be deployed safely in the public domain without the costly security infrastructure mandated for such deployments.
The solid state architecture delivers an extensible Quality Assessment web solution that supports both client (portable) and data-center deployments. Eliminating the OS layer also delivers close to zero percent overhead (‹0.04%) for highly accurate connection measurement void of OS inaccuracies, with the added benefit of low operational running costs and almost zero heat emissions.
MCS Software satellite delivers the same architecture as the Access Series hardware satellites. Software satellites implement the same MCS web testing services on commercial OS platforms such as Windows, Linux, MAC, Android and iOS while also delivering a very thin footprint for both server and client testing roles. Software satellites operate the same integrated access anywhere/everywhere solution to support VM environments, global and cloud-based networks while delivering an architecture that eliminates access to the underlying file system, executable binaries, batch scripting or OS data assets. Software satellites implement a single no-install-required thin executable, however, to support reboot recovery and other system interrupt requirements, software satellites support an installation process where required.
Viral data threats that spread through file penetration attacks are eliminated as part of the satellite security architecture. The Satellite data management engine has no requirement for an underlying file system, therefore all data assets solicited from MCS by any satellite (hardware or software) operates strictly as a one-way street. All files delivered to a satellite, regardless of platform, can never be accessed, retrieved or returned to its source via the OS. Independent OS penetration threats and other application threats that share the commercial platform with the MCS satellite will obviously still exist.
Much like a video streaming service, such as Netflix, VoIP also utilizes buffering to ensure smooth communication. As everyone knows, if the buffer runs out of data the service will fail.
High peaks and discards are events that drain the Jitter buffer, causing the quality of the call to deteriorate rapidly. Just reporting average Jitter won't provide insights into any threats to the jitter buffer.
To understand equilibrium consider this...
There are two families at a hotel wanting to go to the airport to catch the same flight. One is a family of four and one is a family of eight.
The airport is an hour away based on the maximum speed of the road. The taxi carrying the family of four is able to do the maximum speed for the road and gets to the airport in one hour and they make the flight.
The taxi carrying the family of eight has a problem and can only travel at half the maximum speed of the road and arrives at the airport in two hours, so they miss the flight.
The performance measure of these two examples. Taxi one is four passengers in one hour. Taxi two is eight passengers in two hours. Both of these are therefore four passengers per hour, yet the family of eight had a terrible experience.
How does the user distinguish between the four passengers per hour that is good versus the four passengers per hour that is bad? This defines equilibrium. The only way to distinguish is knowing that the second taxi had eight passengers. The equilibrium SHOULD have been eight passengers per hour, but came in at four, which is bad.
Any test that does not strictly control and understand the precise payload that is being measured can never report an accurate result.