[j-nsp] Re: verify QoS operation

[Guy Davies]

> Rainer Clasen
> > > 
> > > Erdem Sener wrote:
> > > >  show interfaces <interface-name> extensive --> where you
> > > can see how
> > > > much traffic is transmitted/dropped for each queue.
> > > 
> > > These are outgoing stats. I'm looking for incoming Stats - in
> > > case I can't look at the output counters on the 
> neighboring device.
> > 
> > A receiving device has no way of knowing how the 
> transmitting device 
> > implemented classification, queueing, scheduling and congestion 
> > avoidance for each class of traffic.
> 
> Uhhm, sorry for being inprecise. I actually don't care what 
> the transmitting device did internally. I do want to know how 
> the emitted packets (having DSCP or mpls-exp set) match in my 
> incoming BA classifier.

But isn't this the point.  If you don't trust what your upstream is
doing wrt classificatio and you can't influence them to do what you want
and provide evidence then you should simply reclassify based on what you
trust (i.e. the protocol, the src/dst ip address, whatever...).  You
cannot tell by being only on the downstream (even if you have
administrative access to the upstream) if packet has been classified in
accordance with your PHB for egress.  The only way you can guarantee a
consistent BA/PHB across your network is by knowing what happens at the
egress onto each hop.

> > This decision is made at each hop
> > and can be based on different models at each hop, 
> particularly if your 
> > devices support different queueing, scheduling and congestion 
> > avoidance algorithms.  Assuming that the packets are marked at the 
> > ingress to the network, you can see the number of packets arriving 
> > marked with a particular class based on a particular 
> marking (although 
> > I don't think JUNOS actually records those stats).
> 
> jepp, these stat's are exactly what I'm looking for.

But will this actually tell you anything beyond the fact that you're
receiving traffic of particular classes in a particular proportion?  It
doesn't tell you if any high priority (low latency, low jitter, low
loss) traffic is being prioritized onto the link.  If that's not
happening, the end to end perceived behaviour will not match your
requirements.

> > However, this gives absolutely no
> > indication of whether the transmitting device is actually 
> queueing and 
> > scheduling packets appropriately (for some value of "appropriate") 
> > since you have no idea of the rate at which packets for 
> each class are 
> > arriving at the transmitting device.  Each device is 
> responsible for 
> > the QoS of outbound packets.  There is little benefit to 
> implementing 
> > QoS inbound since the resource has already been utilized by 
> the time 
> > you get to make a choice whether or not to drop a packet.
> 
> You're absolutely right. 
> 
> It's just that our network crosses some administrative 
> borders - and I want to check what I'm receiving from another 
> department. Or to put it in other words: I'm looking for an 
> indication that they're setting the DSCP properly. Jepp, I 
> can write up a firewall filter + counters to check this, but 
> it'd be a lot more comfortable to take a quick glance at the 
> incoming classifer stats ... (which also indicates if my 
> classification matches their tagging).

But there's little in the received packets that will help you identify
whether they are being handled correctly by your immediate upstream (or
devices even further upstream).  Inbound stats (if they existed) based
on each class of service wouldn't indicate whether someone is
classifying based on your BAs.  It would indicate what proportion of
traffic arriving on your interface had a particular marking (and nothing
more).  In order to check whether your upstreams were using the same BA
to mark packets, you'd have to re-classify each packet based on your
choice of BA parameters and then identify the number of packets on which
you had to do a rewrite (not sure that is even possible).  If that
number were small/zero, then you know that the upstreams are doing the
right thing.  If the number is high, then you can only assume that
they're not doing things the way you expect.

Rgds,

Guy  

This e-mail is private and may be confidential and is for the intended recipient only.  If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed.  If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it.  We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free.  You should undertake your own virus checking.  The right to monitor e-mail communications through our network is reserved by us.