[c-nsp] ASR9k Bundle QoS in 6.0.1

[Adam Vitkovsky]

> Saku Ytti [mailto:saku at ytti.fi]
> Sent: Wednesday, June 08, 2016 11:44 AM
>
> On 8 June 2016 at 11:53, Robert Williams <Robert at custodiandc.com> wrote:
>
> Hey,
>
> > My understanding is that the central arbitration has a few benefits, such as
> zero packet loss when there is an RSP failure (because every request is sent
> to _both_ arbiters at the same time, so when one RSP fails there is only one
> answer back, not two). Thus, the packet in flight is still transmitted without
> loss. Critical when you have very sensitive BFD over MPLS tunnels traversing
> the chassis. There may not be a quick enough 'detection' of the failed
> RSP/arbiter on the core device to maintain data plane forwarded BFD
> relationships between up/downstream nodes.
>
> But is that really so? Why can't we do this with 100% separated fabrics with
> distributed arbiters? The linecard could resend fabric request if it does not
> receive reply in n microseconds, to handle failover with no loss?
>
We are actually talking nanoseconds here.
Arbitration has to finish with a maximal match (2 or 3 iterations of the selection algo.) for all the VOQs every couple of nanoseconds.
There's no time to waste here waiting for retransmission.

> > The second benefit, relating to my original question :) - is that backpressure
> from a congested egress port can be applied 'globally' to all ports on the
> chassis, via the virtual output queues. This should (in my opinion) open up
> the door for centralised egress queueing because it seems to me that the
> pieces are all there, and, maybe, it is now in place from 6.0.1 onwards so that
> bundles may support it across all member ports.
>
> I don't think the arbiter experiences the traffic in higher precision than NPU, I
> don't think it can discriminate between actual WAN ports.
>
On ASR9k the arbitration granularity level is per egress 10GE entity.
So by releasing tokens for this 10GE entity (represented by a particular VOQ on all ingress LCs)  the NPU can regulate how much traffic it will receive from all ingress LCs for this 10GE entity.

However if for example this 10GE entity is split into 4 queues on egress and each shaped to a certain BW -there's no way how the egress LC can control how much traffic it will receive for each of these queues. For what it's worth all the traffic it grants (whole 10Gbps) can actually be classified into only one of these 4 queues on egress -if this happens then excess traffic has to be actually buffered on the egress LC in the delay-bw packet buffer.



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
---------------------------------------------------------------------------------------