[j-nsp] QoS when there is no congestion

[Adam Vitkovsky]

> Andrey Khomyakov
> Sent: Tuesday, November 15, 2016 4:27 PM
>
> I think this is where I was misunderstood. Firstly, "proper" user
> *shouldn't* (see points about policers) hurt, but "proper" requires research
> into your whole network. The point I was making was based on the OP's
> initial statement that there is no congestion in the network, QoS will not help
> anything, because as long as the packet is not being buffered (queued), it
> won't have a chance to be reordered by QoS, but rather will go straight to the
> tx ring.
>
Well, even with cut-through switching, packet bodies are always buffered in the HMC DRAM while in-flight(i.e. header is undergoing lookup) until the complete packet is ready for TX when the contents are read from the HMC. And my understanding is that modern boxes are not using tx or rx rings/interface hold-queues.

> Again, I can't state this enough: the OP explicitly stated lack of congestion
> *anywhere in the network*. The rest are assumptions made that OP simply
> doesn't realize that there is congestion on the network.
>
> So put it simply, if there is no congestion *anywhere* QoS is a lot of effort
> with very little to no payback and new risks coming from potential for
> improper configuration and additional complexity.
> If there is congestion, then by all means, make the business case that
> additional complexity and configuration management costs are lower than
> simply increasing the size of the pipe where congestion is. Hence YMMV
> note.
> At the end it all comes down to $$$. If you can demonstrate that tinkering
> with QoS is cheaper than not, I agree, go with QoS.
>
Yes indeed designing QOS is the most tedious and complex task during network design because it is very closely tight to HW capabilities.
But in order to evaluate whether there is no potential for any congestion anywhere, including the boxes themselves, you need to dwelve into the architecture of boxes, once you understand what resources you have at hand on each device, then mapping your traffic flows (which, by the way, you have to do in the "throw more BW at the problem" approach anyways) and writing the QOS policy is the easy part.

adam


        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------