Re: RED w/o bandwidth...

From: Venkataramanaiah.R (vramanaiah@gmail.com)
Date: Sun Nov 27 2005 - 15:19:18 GMT-3


Chris,

Ok.. Nice and detailed explanation and it is inline with most of my
understanding as well, but as i warned here are my follow up
questions..

1) Did you really mean that RED can't work on FIFO? If so, does the
queuing stratregy change from FIFO (Am afraid not) to something else
when bandwidth is configured under a class for that particular class.
I thought it is FIFO always under a particular class.

2) For the class-default, how does work RED work when just fairqueue
is configured. It still doesnt know how to measure the drop threshold
right? or does it behave like WFQ's CDT and not as a true RED, when
fairqueue is configured?

Thanks
-Venkat

On 11/27/05, Chris Lewis <chrlewiscsco@yahoo.com> wrote:
>
> Venkat,
>
> There are several concepts represented in your mail that need to be
> separated in order for a full understanding to be possible. I also think
> that some of this is not relevant to the R&S exam, but anyway, here is what
> I can tell you right now.
>
> First, in terms of deciding which packet to drop, FIFO is mutually exclusive
> from RED. One either decides to tail drop packets in the case of FIFO, or
> randomly drop packets before the tail drop case is reached via RED.
>
> If your question is "why do I need to configure bandwidth in order to
> configure RED" the answer is you don't J
>
> RED can be applied to an interface or a class. Looking at the interface
> application first
>
> interface Serial0/0
> no ip address
> random-detect dscp-based
> end
>
> Then looking at the interface gives the following:
> sho int s0/0
> Queueing strategy: random early detection(RED)
>
> So here we have no bandwidth or fair queueing defined in the configuration
> and RED can be applied. So the next question is, what happens when I try to
> apply RED to a class
>
> class-map match-all map1
> match protocol icmp
>
> Router(config)#policy-map test1
> Router(config-pmap)#class map1
> Router(config-pmap-c)#random-detect
> bandwidth on the class is required to issue this command
>
> So now we have different behavior. The reason for the difference is that an
> interface has a given throughput capability, and when that is reached, a
> queue will build up and RED can act upon that queue. By contrast, a class
> can have any throughput capability configured on it, so there is no natural
> throughput level (other than the interface capability) that will build a
> queue to enable RED to act. So think of a class as something virtual within
> the router that you need to define the capabilities of in order for RED to
> do its thing.
>
> Now the situation changes slightly for the default class.
>
> Router(config-pmap)#class class-default
> Router(config-pmap-c)#rand
> Router(config-pmap-c)#random-detect
> fair-queue or bandwidth on the class is required to issue this command
>
> The difference here is that the default class uses the remaining unallocated
> bandwidth (unallocated to other classes), so it does not strictly need the
> bandwidth statement, as it knows the amount of bandwidth left and can work
> with that.
>
> Now RED is in fact a dropping mechanism, and it needs a queue to operate on.
> As classes are virtual within the router (as opposed to a physical
> interface) some queueing strategy needs to be defined for the class to
> define how to build these queues, and for the class-default you are given
> the additional option of defining fair-queueing.
>
> There are two other RED options to be familiar with. Flow based (for
> interfaces only) and the ECN option. Flow based was created for non-TCP
> flows that do not back off in the presence of dropped packets. The ECN
> option is where you can set ECN in the packet instead of dropping it, so
> that you do not have to rely upon the dropping of a packet to signal
> congestion (and by implication hosts will know to back off without
> experiencing packet loss).
>
> Chris
>
> "Venkataramanaiah.R" <vramanaiah@gmail.com> wrote:
> Read the last but one para as,
>
> "Why can't random detect work on a FIFO queue. What i mean here
> is why i cant configure RED on a FIFO queue (w/o bandwidth statement,
> assuming bw
> command changes the queue to WFQ)."
>
> TIA
> -Venkat
> On 11/27/05, Venkataramanaiah.R wrote:
> > Hi Chris/all,
> >
> > Is there any theory behind, why CBWFQ class does not accept
> > random detect command w/o bandwidth command?
> >
> > Might be a silly question, but just want to get the basics clear..
> >
> > Does the queuing strategy get changed for the class when
> > bandwidth command is configured.. May be WFQ..?
> >
> > Why can't random detect work on a FIFO queue. What i mean here
> > is why i cant configure RED w/o bandwidth statement (Assuming bw
> > command changes the queue to WFQ).
> >
> > Warning : I may have more questions based on your response.
> > Hope this warning does not prohibit you from answering the above
> > questions :-)
> >
> > Regards
> > -Venkat
> >
>
>
>
> ________________________________
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.



This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:08 GMT-3