Mailing List Archive

QOS Mechanics - PLP and drop-profiles behaviour
Under test, I set my scheduler drop-profiles to be acting only against tcp
traffic. Now, if I wind a queue up so that it is heavily congested but only
with UDP streams, I still see the sub-queue classified as 'high'
drop-priority more aggressively dealt with than the 'low' drop-priority
classified sub-queue (I use the term sub-queue here for the diferentiation
between high and low drop priroties.)

In fact, even if I remove all drop-profiles so that allegedly everything
uses the default-drop-profile <fill-level 100 drop 100> I see the same as
above on TCP and non-tcp traffic. Do I assume from this that the PLP status
that is used internally to differentiate the high and low traffic within a
queue (show class-of-service forwarding-table ) IS used during heavy
congestion to differentiate between the classifications..? That is, the
high/low dichotomy isn't just for differnent WRED drop-profiles to be set?

In fact, I'm sure this is happening and although it is in fact useful to
prioritise the 'low' sub-queue during heavy congestion for all traffic, I'd
like to know how it works so I can possibly set a non-tcp drop-profile set
to compliment the internal handling based on PLP...

Damon Pegg
Network Development
Easynet plc
t: 0207 900 7075
f: 0207 900 4443
m: 07931 406206
e: damon.pegg@uk.easynet.net
w: www.easynet.com
QOS Mechanics - PLP and drop-profiles behaviour [ In reply to ]
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@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@uk.easynet.net
DP> w: www.easynet.com
DP>
DP> _______________________________________________
DP> juniper-nsp mailing list juniper-nsp@puck.nether.net
DP> http://puck.nether.net/mailman/listinfo/juniper-nsp

--
Jeremy Wallace <jeremy@skwire.net>
QOS Mechanics - PLP and drop-profiles behaviour [ In reply to ]
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@skwire.net]
Sent: 11 February 2004 14:34
To: Damon Pegg
Cc: 'juniper-nsp@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@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@uk.easynet.net
DP> w: www.easynet.com
DP>
DP> _______________________________________________
DP> juniper-nsp mailing list juniper-nsp@puck.nether.net
DP> http://puck.nether.net/mailman/listinfo/juniper-nsp

--
Jeremy Wallace <jeremy@skwire.net>
QOS Mechanics - PLP and drop-profiles behaviour [ In reply to ]
Wednesday, February 11, 2004, 12:45:28 PM, you 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> 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..?

it is not used.

DP> That is, the
DP> high/low dichotomy isn't just for differnent WRED drop-profiles to be set?

I don't know exactly what you did but if all is default setting
there is no differentiation or different treatment between plp set
or not set for WRED unless you define a different behavior. If you
still see a difference then you need to look at your test bed to
get an explanation.

Josef


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> 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@uk.easynet.net
DP> w: www.easynet.com

DP> _______________________________________________
DP> juniper-nsp mailing list juniper-nsp@puck.nether.net
DP> http://puck.nether.net/mailman/listinfo/juniper-nsp