> The problem is that, when there is congestion, two "side-by-side" tests,
> comparing priority traffic to non-priority, the priority traffic latencies
> are often worse than those of the non-priority traffic (using ping) and
> are highly variable. Application (http/ftp) throughput is also lower than
> expected and virtually the same (some would say worse!) as the
> non-priority traffic. Some packet loss also occurs on both classes of
> traffic.
I've seen that too. Are you using priority -queueuing inside WFQ or
just two WF queues with different bandwidth (weight) parameters?
I have a configuration where my best-effort queue has low weight
setting (so it doesn't get served so often), and strict priority
queueing is also active in that WFQ group to protect latency
sensitive traffic. I also run WRED so that the drop-parameters do
not overlap (all BE traffic drops before I touch my latency sensitive
packets). During congestion the delay of all traffic is growing, but
the priority packet delay grows actually faster than BE traffic. When
congestion continues to exist the delay of priority queue gets stable
and the BE traffic beguns to drop very aggressively. Worst case
delay with one 2 Mbps serial link during congestion have beeing about 140ms.
At that time almost all BE traffic is dropped. Anyway, it seems that
the CBFWQ with the priority scheme protects packets from beeing dropped
rather than beeing served first. If you can tolerate the delay though it
might be usable also for some delay sensitive apps.
Jorma
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:20 EDT