Most Net Techs that I have talked to have heard of quality of service (QOS) but few actually understand what it is. Some have no idea what QOS is supposed to do, while others think that it is the end all be all solution to constrained bandwidth. I am here to tell you that you are all most likely wrong. Instead, QOS is one of the many tools at the disposal of the Net Tech to manage the bandwidth that he/she has, and ensure that critical traffic is able to get across the network with minimal delays.
About a year or so ago, myself and another warrant who was out here helping out with a rotation were looking at the configs for the unit trying to understand what exactly was going on with the QOS. It took us several hours to really understand it. This got me thinking about putting together a small white paper to hand out to net techs to try and explain it to them, and get them to understand what it does, and more importantly what they need to do to make it work. My short paper turned into about a year long project and a 19 page paper. During the process of researching everything, I discovered that I was wrong with a lot of the things that I thought I knew.
My original intent was to post the entire paper here and then leave a pdf copy for everyone to download but after spending just 30 minutes trying to get it all input into WordPress and formatted correctly, I got frustrated and gave up. So instead, I am writing this brief introduction, and just posting the paper here for you to download and look at.
So what are you downloading? Well, the main file is “QOS WIN-T Inc 1A”. It is a 19-page document that explains in a fair bit of detail what QOS is, how it is implemented in WIN-T Inc 1A and what you as a net tech need to do. The next file is a Visio file that lays out step by step an example of QOS at work. The description of the what is going on is included in the first document but the Visio file really helps to lay it out. The final file included is a QOS bandwidth calculator. I didn’t make the calculator, although I have modified it a little bit. Unfortunately I am not sure who made it (I got it somewhere along the road) but whoever did….Thanks
Please note, this paper applies to WIN-T Inc 1A only although a good chunk of it applies to 1B also (I just haven’t taken the time to sit down and figure that all out yet). I plan on writing more about this in the future. If you have questions or additional comments, please send them my way so that I can fix anything that I may have overlooked.
Due to some concerns by a number of people, I have decided to temporarily remove the documents from my site here and posted them to MilSuite. As much as I hate MilSuite for a number of reasons, for right now it is the only way I can store FOUO documents.
Yes, QoS is largely misunderstood, and depending in who you talk to it has different meanings. I work at DISA Europe and part of my duties is to oversee the CONEX here. Drives me crazy that when they mention QoS in reference to a GAA, they are really talking about bandwidth percentages for voice, NIPR and SIPR, etc.
QoS from a net tech percentage is much different. Without getting in.the weeds too much, I’ll just say that while many of us, myself included for a long time, have a hard time wrapping our heads around the way Cisco does their packet tagging for it. But QoS is an end-to-end deal. Its only affective if the same tagging schemes are used throughout the entire length of the packet’s journey, from desktop to end host/server/what have you. If a BCT NT2R’s QoS doesn’t match the Hubs’ then it really means nothing.
Troy MacDonald agree that having the hub and the BCT match is important but I don’t think it will ever happen except possibly in a deployed environment if the division dictates the QOS (which I don’t totally agree with). I would hazard to guess (and Christopher Culp might be able to confirm or deny this) that the RHNs aren’t running QOS for the BCTs other than probably voice and management traffic. So while you don’t get the full bang for the buck by not having matching markings on both side, you still get prioritized traffic for half the journey. The other thing that we’ve seen through out network monitoring here at NTC is that the bulk of the traffic is between the BDE and the BNs with a smaller percentage (just how much that percentage is changes from unit to unit) going out of the unit to either the GIG or the division. I will preface that by saying though that 52ID (the notional division at NTC) is really only a replicated division so we don’t get as much interaction between the BDE and Div that you would normally see.
Troy Ward, you are right about the 52ID traffic. From my experience in Afghanistan, there was a significant traffic transitting the Division network as many of the FOBs, at least at that time, were connected through the Black Core backbone over fiber or LOS links. Though this connection scheme changed the whole QoS dynamic, what with higher bandwidth and lower latency paths. Though after digging into how they configured their BGP, OSPF and MPLS routing, it looked more like a CCIE Test experpt did the configuring versus someone with real world experience. Often, if a link took a hit then about half of our AOR would loose connectivity while the entire thing reconverged.
Let the BDEs do their own QoS but understand that once it leaves their tunnel, it will be translated to a common QoS if the traffic terminates elsewhere, i.e. the division or another BDE)
Correct that the RHN is not doing anything during a routine mission configuration for QOS other then what is in the standard wint configuration. We would not be opposed to making special changes for specific high priority missions on a case by case basis but I wouldn’t see us doing it for every mission 1200 plus times per year.
Troy Ward, your write is awesome and we can only wish that everybody in the community has the same understanding and passion as you do regarding QoS. Here’s my two cents:
I agree with Chris Westbrook and let the BDEs (and BNs) do their own QoS. At any hub, traffic is transient and rarely is their any transient congestion, because the bulk of the communications is within the BDE network and if there’s any ‘inter-mesh/network’ communications requirement – standard WIN-T QoS policies will do their job. There’s no services/servers at the hub users are accessing so ‘gee whiz’ QoS configurations is moot. Any major or large QoS adjustments made at the hub were done on deployments were inter-BDE communications are more prevalent. Now… the majority of your QoS adjustments will be at the BDE in those ACLs…. and like you mentioned in your paper Troy, the configurations is the framework, those ACLs identifiying what is being filtered and QoS’d will make that network better. They have to be populated.
I find where the understanding and inner-workings of QoS becomes extremely critical is when you’re developing QoS from scratch.
The one problem I saw with QoS was that the trigger for it is set to 4096 on the interface, well in very rare occasions I have seen the bandwidth getting to that point to trigger the QoS. The traffic is still moving slow and I still want to prioritize the packets, so for me bringing that trigger bandwidth did the trick.