How does Nomad determine network bandwidth and protect your network? ping? nope. Try reverse QoS instead

Network Ping, DiffServ, QoS or something special?

There are lots of ways to calculate network bandwidth. A network ping can determine WAN speed but this is not ideal as many organizations disable ICMP for many security reasons. Windows firewall alone blocks a lot of ping traffic by default due to the inherent security issues that can be associated by it.
DiffServ can give good Quality of Service (QoS) but requires hardware investment that can utilize this technology not to mention some solutions leveraging this technology only calculates QoS on edge routers. This may be okay for route paths with a short amount of hops (number of routers in-between each edge router) but once we hit the big wide area network we become unable to determine how many hops we take. There’s also the issue of requiring clients to use this technology down at the network level.
This means we need drivers to create these special types of network packets that can utilize DiffServ effectively on each of our clients and Microsoft themselves once attributed that the reason why nearly all windows machines get the dreaded “blue screen of death” was because of drivers.

So how does Nomad do it? Reverse QoS^TM.

Nomad doesn’t want to use QoS. Why? QoS is literally Quality of Service. It ensures that certain packets are prioritised over other packets. What does this mean in laymen terms? It means that your packets compete for bandwidth over a link. This means that the link still can get saturated and that the prioritised packets get “right of way” over these saturated links.
What does Nomad do? Nomad uses a special system called Reverse QoS^TM.

What is Reverse QoS^TM?

Reverse QoS ^TM is a method that looks at the complete round trip time that it takes blocks of data to traverse a WAN link. It is able to back off or speed up accordingly in a safe manner. This is special because it can actually take everything into account. This includes high CPU utilization of a client down to even disk read latency from the OS. This is hugely beneficial to business due to the fact that network hardware such as router queues do not need to be accounted for as the solution is purely hardware based. It also means that Nomad is able to avoid using any system level drivers that risk a blue screen of death as previously mentioned which could cause havoc to your organization and possibly require the need to visit every system if there is a problem.

So what’s the problem with other methods?

Other methods for network bandwidth throttling soon start to break down when you have multiple network hops and routes through different switches on the way to an endpoint because the only look at edge routers and not the whole end-to-end WAN like Nomad does with Reverse QoS ^TM. You can see how some of the largest organizations in the world like Verizon Wireless, AT&T and Saint-Gobain are actually using Nomad in the video and documented case studies at our Resource Center.

Why run Nomad vs nothing at all?

How does Nomad control your SCCM bandwidth management?
Nomad is a pure software solution which dynamically manages the bandwidth of IT content distribution in order to prioritize business traffic over IT traffic instead of traffic competition where it’s business traffic vs IT traffic. Nomad does this by Reverse QoS™.
By using Nomad in your SCCM (ConfigMgr) designs for branch offices and SCCM bandwidth management you no longer have to deliberate whether one site should be your central location site vs another site. Instead when it comes to Microsoft SCCM WAN bandwidth management at branch offices you can target Applications and Packages without any additional SCCM branch office constraints due to the complete Nomad integration. There is no risk with using Nomad in your SCCM branch office design as it augments the System Center infrastructure rather than compete with it.
Many organizations have a list of key criteria which they want to ask about their environment when evaluating Nomad vs other methods for managing client systems at SCCM branch offices.
How many servers will they reduce to before creating a single point of failure? Nomad reduces the server infrastructure at Microsoft ConfigMgr branch offices more than any other product on the market. It does this without having to ask the question should I deploy this vs will this create a single point of failure because Nomad accounts for all scenarios.

Reducing your network infrastructure VS creating a single point of failure

Nomad also has Binary-level differencing, client cache management and Peer to peer based redundancy and distribution mechanisms of Nomad allow an organization to dramatically reduce infrastructure servers by 95% or more without creating any risk such as a single point of failure or unnecessary client overhead or kernel drivers.
The requirements for many organizations require multiple sites vs one site for many reasons: political, geographical, high availability, disaster recovery reasons, even servicing Internet-facing clients and Nomad can cater for all these scenario where-as others cannot.
Additionally the OSD facilities of Nomad allow organizations to supercharge migration projects without any additional staff and achieve the highest possible amount of automation on most client systems. The PXE Everywhere functionality that is native to the Nomad solution allows for PXE in branch offices to happen without any server infrastructure and still effectively managing the ConfigMgr bandwidth to the branch. Try Nomad for yourself and whittle your list of ten questions down to none and manage the Microsoft SCCM bandwidth for your branch office at one site like you would your central site – in other words manage them all the same.