> 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.vitkov...@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 postmas...@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
---------------------------------------------------------------------------------------
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
