Share This Post

How does Nomad Enterprise determine network bandwidth and protect your network? Ping? Nope. Try Reverse QoS TM instead

How does Nomad Enterprise determine network bandwidth and protect your network? Ping? Nope. Try Reverse QoS TM 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 IGMP 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 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 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 over 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 QoSTM.

What is Reverse QoS TM?

Reverse QoSTM 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 QoSTM. You can see how some of the largest organizations in the world like HSBC, Verizon Wireless and AT&T are actually using Nomad in the video and documented case studies at http://www.1e.com/it-efficiency/software/nomad-enterprise-software-deployment/#casestudies


Why run Nomad 2012 vs nothing at all?

How does Nomad 2012 control your SCCM bandwidth management?
Nomad 2012 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 2012 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 onesite 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 2012 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 2012 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 2012 accounts for all scenarios.

Reducing your network infrastructure VS creating a single point of failure

Nomad also has Byte-level differencing,  client cache management and  Peer to peer based redundancy and distribution mechanisms of Nomad 2012 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 or even high availability and disaster recovery reasons and Nomad 2012 can cater for all these scenario where-as others cannot.

Additionally the OSD facilities of Nomad 2012 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 2012 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 2012 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.

Share This Post

Leave a Reply