[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new WRR sched, updated TBF and "real" ingres implementation
On Fri, 28 Jul 2000, Devik wrote:
> I have no router with 12.x IOS :-| ... But in 11.x I'm pretty sure
> about this. When I did "sh in s0" with WFQ set I've seen there was
> always packets siting in WFQ queue and about 5 flows active.
> At the time I turned the shaper on there was no longer any packets
> in output queue. Hence I spoke with our local cisco support and
> they said "yes it's true but it should be much better in 12.x".
Very interesting indeed. They were probably reffering to the CAR thing
they have as shaping.
> > take a look at the "continue" construct (i still see no good reason to
> > have input shaping)
> if I understood it correctly, when I want SMTP inbound traffic
> to take at most 10% of link in time of congestion and more when
> link is not congested I will attach 26kbps policer with
> "continue" action and then 256kbps policer. It will ensure
> at least 26kbps for SMTP but it can also "borrow" from whole 256kbit
> link. Am I right ?
thats right. You can have the 256Kbps policing shared by multiple flows as
well. So they each have their own base share and they fight for the
> But when policer starts dropping how can I ensure that all TCP
> flows will be dropped fairly ? And how can I say how to distribure
> extra bw ?
cascade policers. Look at the "color aware" example.
> I think I could use something like ingres CBQ instead of ingres
> policer - when CBQ class is not overlimit it doesn't delay packet.
> When it is overlimit, it can both delay packet or drop packet.
Are you assuming infinite buffers in the "delay"?
Why is packet dropping when a flow oversubscribes such a bad thing?
> So I can do the same as with policers but also I can specify
> what to do with extra bw.
Well you can specify what to do with the extra bandwith with policing as
well. In times of congestion, you drop when the total allocated limit
(256Kbps in your case) is exceeded.
The policer decides that you have infact exceeded the 256Kbps based on
history (EWMA); so when it says you are congested, it really means you are
congested. Even if you queue at that point, you queue will fill up very
very quickly (again as i said earlier, unless you have infinite buffer
> In another words, when we allow using ANY qdisc as ingres it will
> be backward compatible with current solution, it will be cleaner
> (ingres qdisc is a bit different than other qdiscs) and it will
> allow much more advanced things ..
> What do you think ?
To add queueing to ingress is trivial as i said in the earlier email.
to have other queueing disciplines (CBQ, Prio etc) attach to it after that
is also trivial.
I just havent heard anything that is convincing to say we need this.
Take a look at all router vendors and show me one that does ingress
queueing. If you find one it's because they are stuck with architectural