[c-nsp] ASR9k Bundle QoS in 6.0.1

Adam Vitkovsky Adam.Vitkovsky at gamma.co.uk
Wed Jun 8 07:44:35 EDT 2016

> Robert Williams
> Sent: Thursday, May 12, 2016 1:06 PM
> >> Slightly relevant. How could such feature work, in principle, if different
> ports are offering significantly different rates of traffic?
> Yes, indeed! The mechanism would need to be both quick and consistent,
> although the current system is unpredictable and detached by its very nature
> - so any improvement would be good :)
> Although thinking about it, can't the central arbiter simply treat it as one
> virtual queue and distribute the 'tokens' to multiple NPs in a round-robin
> style? Would it be that significantly different from sending multiple separate
> streams to separate NPs as in the current model (when used for egress
> queueing multiple ingress ports to a single egress port)?
The ingress NP computes the hash and that will spit out the egress LC ID which gets programed to the super-frame header(s).  So packets of two ingress streams will end up with different egress LC IDs. So when FIA is requesting access it will treat them independently.

So for what you request to be possible the ingress NPU would somehow has to know that the hashing it's doing is not for ECMP but for a bundle and although hashing produces different LC ID for each stream all packets should actually be dumped into one special VOQ representing a bundle of 10GE entities on different LCs. The ingress FIA would then send frames from this common VOQ to egress LCs in a round robin fashion.
But with this we would actually decrease VOQ granularity.
(Which actually shouldn't be a problem since all ports in the system should be using the same method so it should never happen that one of the ports in the bundle would get congested resulting in HoLB for packets hashed to the other port (since all packets would be  in the same VOQ).
The most important caveat I see is that these VOQs would have to be carved up dynamically as you configure new bundles  and I don't think that's something that would fly.
(or there would be a set of these special VOQs preconfigured -but there would only be limited number of them resulting in a limited number of bundles you can create as well as these reserved queues would limit the available number of regular VOQs).


        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

More information about the cisco-nsp mailing list