Best Effort QoS Drop Profile Input
Hello all, We are working on fine tuning drop profiles for customer edge routers (Juniper J-2320 in almost all cases) and I was hoping for some input from those who are smarter and have done this before. Basics: - Sites each have a single T1 into a service provider L3 VPN - Queue depth is 500ms - Sites typically will use 90%+ of their line rate while school is in session (education network) - Services offered include: real-time video (in a different queue) and best effort (serviced by the queue in question) - Nearly all BE traffic will be TCP (typical web, email, etc traffic) We were never able to find a good best practice for configuring drop profiles on edge devices. We've been using the following with OK results but I was hoping to have some external, more experienced eyes take a look... drop-profiles { be_any { fill-level 50 drop-probability 5; fill-level 70 drop-probability 20; fill-level 90 drop-probability 50; } Has anyone ever run across a publicly documented best practice for drop profile configuration? Does anyone have suggestions on ways to improve the configuration above? Any input is much appreciated, thanks in advance! -brad fleming
On Mon, 24 Aug 2009, Brad Fleming wrote:
We were never able to find a good best practice for configuring drop profiles on edge devices. We've been using the following with OK results but I was hoping to have some external, more experienced eyes take a look...
drop-profiles { be_any { fill-level 50 drop-probability 5; fill-level 70 drop-probability 20; fill-level 90 drop-probability 50; }
Has anyone ever run across a publicly documented best practice for drop profile configuration? Does anyone have suggestions on ways to improve the configuration above?
Any input is much appreciated, thanks in advance!
I think it's fine, personally I've been known to configure core network WRED with 0% drop at 40ms and 100% drop at 60ms (reasoning is that basically no application will be well suited by having its packets delayed much more than 40ms), though at the lower speeds you have, your values are probably better. Hm, just realised your "fill level" is in percent, right? Then I'd stop dropping packets earler if I were you, having 0% drop up until 250ms is not really helping interactive applications, you probably want to induce drop earlier (at 40ms or so), so file transfers don't fill up the buffer but hopefully the fewer packets/s of an ssh session still has low probability of being dropped (and fast-retransmit can do it's job fairly unnoticable to the user). So in your case, I'd have the first drop-probability much sooner, at 10% if you have 500ms buffering. Perhaps starting with a 1% at 10% and 3% at 20% buffer fill rate. -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (2)
-
Brad Fleming -
Mikael Abrahamsson