[j-nsp] QOS Mechanics - PLP and drop-profiles behaviour

[Damon Pegg]

lol.  That's a little sensitive I'm afraid...

Lets take a summary of a simple and not entirely dissimilar scenario ;)

I have the maximum 4 queues, Q0 - Q3.  Each has a high and low drop
precedence, which is seen internally as PLP 1 for high and PLP 0 for low
drop-precedence.  Lets say for simplicity's sake that I have 1 IP Prec value
mapped into each of my subsequent 8 levels of service in my IP prec/exp/dscp
classification.  

I then have 8 drop-profiles defined, one for each of the above.  These can
be TCP or non-tcp or both. 

I then have a scheduler that allocates bandwidth, buffer allocations and
assigns drop-profiles.

My maint point here is that the Junos documentation states that these PLP
values that distinguish between the two levels in each queue only have
relevance when the drop-profiles are defined for them under the schedulers
configuration; i.e. High is treated more aggressively by WRED than low
within each queue (presuming your associated drop-profiles dot his, though
actually you could specify the reverse!)  However, even if I remove the
drop-profiles from my scheduler so all queues use default drop-profile, a
congested scenario will result in traffic within a queue with different PLPs
being treated differently, presumably by the WRED mechanism..?  So PLP does
seem to have an associated 'weight' for the WRED even if not user-defined...

damon.

-----Original Message-----
From: Jeremy Wallace [mailto:jeremy at skwire.net]
Sent: 11 February 2004 14:34
To: Damon Pegg
Cc: 'juniper-nsp at puck.nether.net'
Subject: Re: [j-nsp] QOS Mechanics - PLP and drop-profiles behaviour


Damon,

Could you post your class-of-service config to help clarify what you are
configuring on the Juniper?

Thanks,
Jeremy.

On Wed, 11 Feb 2004 11:45:28 -0000
Damon Pegg <damon.pegg at uk.easynet.net> wrote:

DP> Under test, I set my scheduler drop-profiles to be acting only against
tcp
DP> traffic.  Now, if I wind a queue up so that it is heavily congested but
only
DP> with UDP streams, I still see the sub-queue classified as 'high'
DP> drop-priority more aggressively dealt with than the 'low' drop-priority
DP> classified sub-queue  (I use the term sub-queue here for the
diferentiation
DP> between high and low drop priroties.)
DP> 
DP> In fact, even if I remove all drop-profiles so that allegedly everything
DP> uses the default-drop-profile <fill-level 100 drop 100> I see the same
as
DP> above on TCP and non-tcp traffic.  Do I assume from this that the PLP
status
DP> that is used internally to differentiate the high and low traffic within
a
DP> queue (show class-of-service forwarding-table ) IS used during heavy
DP> congestion to differentiate between the classifications..?  That is, the
DP> high/low dichotomy isn't just for differnent WRED drop-profiles to be
set?
DP> 
DP> In fact, I'm sure this is happening and although it is in fact useful to
DP> prioritise the 'low' sub-queue during heavy congestion for all traffic,
I'd
DP> like to know how it works so I can possibly set a non-tcp drop-profile
set
DP> to compliment the internal handling based on PLP...
DP> 
DP> Damon Pegg
DP> Network Development
DP> Easynet plc
DP> t:    0207 900 7075
DP> f:    0207 900 4443
DP> m:    07931 406206
DP> e:    damon.pegg at uk.easynet.net
DP> w:    www.easynet.com  
DP> 
DP> _______________________________________________
DP> juniper-nsp mailing list juniper-nsp at puck.nether.net
DP> http://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
Jeremy Wallace <jeremy at skwire.net>