No Throttling!?

throttle v. to regulate the flow (e.g. of fuel to an engine)
1E had an awesome few days in Minnesota for this year’s MMS! If you managed to get there I’m sure you had a great experience yourself and learned a lot from the great sessions and speakers (you may have attended some of the nine sessions co-presented by our very own Mike Terrill, Troy Martin and Keith Garner with our friends from Dell, TrueSec and CoreTech). During periods of, shall we say ‘rest’, the attendees inclined to use urinals may have been curious about a campaign against throttling. Or maybe you observed this campaign to seek out and eradicate this particular evil in the form of a marching protest or a mascot milling around.
The throttling that this particular campaign was out to stop was not the strangulation of people by application of pressure to the windpipe, but instead the eradication of network throttling, specifically in the context of distributing Configuration Manager content to devices throughout your network. The argument of this uprising was that “throttling” is bad, “predictive bandwidth harvesting” is good. But what does that actually mean?
Throttling generally means regulating the flow (of network traffic in this case) by some form of restriction at the source. It is important to understand the difference between limiting and dynamically regulating the flow of traffic, as the term throttling is often used to describe both. When you’re driving, you use the accelerator (gas pedal) to dynamically regulate the flow of fuel to the engine (and therefore your speed) according to the conditions ahead. This is similar to the way 1E Nomad works when it needs to download content across the WAN from a remote Distribution Point. If your car is fitted with a speed limiter that you set to 30 mph, you can dynamically adjust to some extent (up to 30 mph) but will never go above that, even if the road ahead is completely clear. This is similar to the way the Background Intelligent Transfer Service (BITS) works.
The No Throttling camp assert that their “packet-based network protocol predicts how much traffic will be entering the WAN in real time, by reading the length of router queues”. Let’s take a look at that. Imagine you have a flight you need to catch for an important business meeting. As your taxi pulls up at the airport, you see a school bus unloading into departures. You can see through the glass that there is currently hardly anyone at the check-in desks (your first ‘router’ if you will) right now, but by the time you’ve paid the taxi driver and obtained that all important receipt for expenses, 30 children and 5 stressed responsible adults are now in the queue.

Now, being an organized school trip, they all arrived with two hours to spare before their flight. As a busy person, your time is more valuable – you can’t afford to be so leisurely and probably left it quite late. If you had got there just 30 seconds earlier, things would be different. But now you have 35 people ahead of you and you have to wait until they are all checked in. When they arrived, the responsible adults ‘read the length of the queue’ (hardly any) and joined it. How could they predict that you, whose flight leaves in just 40 minutes, was about to arrive and would be delayed – might even miss your flight – by their action. So you wait, you check in and make your way to security (your next ‘router’ in the path between check-in and your plane). Guess whose there already? You wait again while 30 school boys and girls take their shoes off, remove iPads from their bags and progress through the scanner to the gate (the next router).
Now let’s consider the same scenario where a reactive, dynamic regulation of flow, similar to that implemented by Nomad is used. The school bus arrives at the airport, but just one of the responsible adults leaves with a couple of children to join the queue. That responsible adult starts checking in the first children and radios back to another responsible adult on the bus to say there is hardly any queue – send a couple more children. You pay your taxi driver, wait for the receipt and go in to the departures. There are just 3 children in front of you in the queue. Another group of important looking people also join the queue behind you. The responsible adult sees there are important people that probably need to get through, so they radio back to the bus to let the others know – don’t send any more children just yet. Within a few minutes, both you and the other group of important looking people are through check-in and on your way to security (where you won’t have to wait for 35 people as most of them are yet to join the check-in queue).

The point is, it is impossible to predict what is going to happen on a network, or when important content is going to be presented to the network. However it is positioned, bandwidth management can only ever be reactive, whether that is a reaction to a queue length, or reaction to the effect of your own and other users on the network. Rather than pushing content onto the network, Nomad pulls content from the Distribution Point. The Nomad client in the remote site will act like the responsible adult that requests only a small amount of data each time. Rather than fill an empty queue with no further control over regulation of that content as it makes its way through the network, Nomad regulates the flow by requesting small amounts of data and dynamically adjusting the rate of those requests based on the effect it is having itself, the ability for the agents involved to process those requests and the unpredictable actions of other more important users of the network. If that is throttling, then why eradicate it?
1E Nomad has been enabling software distribution to remote devices while preventing it from slowing down important business traffic for nearly 15 years. To find out more about how we do it, check out this video on our website and also Troy Martin’s blog from 2014.