New to QoS

[shikamarunara]

Hello,

     I'm beginning to spend more time working with a researching QoS.  I've worked enough with it in the past for basic things, but I would like to develop a more fundamental understanding of its mechanics and logical design considerations.  My current organization is a bandwidth-rich environment that has always gotten around needing to implement QoS by having a considerable amount of bandwidth.  However, my suspicion is that in the long run we will eventually run into a situation whereby we will have a bottleneck and will need to manage traffic.  That said, I would like to prepare for a situation whereby we will not be able to provision, for whatever reason, Metropolitan Ethernet to a remote site.

     Let's assume that I have a remote site with a single T1 circuit.  The link will pass voice and data traffic and I need to give priority treatment to voice.  As marked packets enter and leave the site, QoS statements on the remote router/L3 switch and the central site's connecting router/L3 switch, by themselves, should be enough to ensure that traffic is being managed correctly on the WAN link, correct?  Even if QoS traffic management is not being done in the rest of the organization, at this point it should not be an issue as the rest of the org has plenty of bandwidth?

     My plan is to eventually have some kind of traffic classification and management in the rest of the network, but the process will take a while and will need to focus on bottleneck areas first.  Does this approach have any drawbacks that I may not be aware of?

[Giuseppe Larosa · Accepted solution]

Hello Shikamarunara,

your approach is correct and reasonable, I have seen customer networks using QoS tools on slower WAN links and not using them on fast MAN links.

Clearly this is not perfect as you haven't true end-to-end QoS everywhere, but it is a good starting point

The trade-off in real world is between the effort and the results you get.

Later after having shown the difference with QoS applied,  you can eventually extend it to other network sections

Hope to help

Giuseppe

[shikamarunara]

It sure helps, thanks Giuseppe.  I suspect that many techs are faced with this kind of thing and that this is going to be a fairly involved challenge to classify the organization's traffic logically.  Sounds like fun

[Joseph W. Doherty · Accepted solution]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not  be construed as rendering professional advice of any kind.    Usage of  this posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

Not so much a drawback, but for a caution, bottlenecks can be transient and often go unrecognized as causing intermittent network performance issues.

Many older network stack TCP implementations will not saturate high bandwidth links when also dealing with WAN latencies but the later generation network stack TCP implementations can.

Putting these two together explains why last month a coast-to-coast 100 Mbps MetroE link did not have transient congestion but this month it does, and it now needs QoS to protect VoIP.  The insidious thing is, many "classical" network monitoring tools (e.g. 5 minute poll of bandwidth utilization) won't see the difference between last month and this month.

PS:

On the other end of the spectrum, when you get down to links less than half of a T1's bandwidth, you can need to implement fragmentation of larger size packets so the transmission of even one large packet doesn't put your VoIP latency beyond what it needs.  Here too, the link might not appear congested, but we can have transient congestion (i.e. one large packet ahead of the VoIP packet).