Re: Reg: Quality of Service routing

[Barry Dykes <[e-mail]>]

I think that some other factors occur here also.  Real delay problems 
aren't
in regards to bandwidth.  Lack of bandwidth causes excessive queuing.  
Queuing comes in different forms and sizes or depths.  Some 
applications
can be sensitive to deeper queues.  Many router and switch vendors have 
multiple queues for this reason.  Some have high priority queues with 
very shallow buckets.  QOS can allow a router/switch to "park" a packet 
in a shallow queue while waiting for it's turn at the outbound 
interface.  It really may not matter that the actual line is only 
running at 1/4 capacity.  But more how many packets are contending for 
that interface at the same time, and who should have priority to it.  
Such is the way of bursty traffic.  All packets will be delivered in 
this scenario, only some have minimum delay characteristics that must 
be met and therefore win in the first contention within the 
router/switch.

Barry

> Masilamany Raguparan wrote:
> > 
> > Raghu,
> > 
> > | Do we need QoS routing if we have enough infinite (I mean
> > | large ) bandwidth.
> > |
> > | >From my poor knowledge:
> > |
> > | We need QoS routing b'cos we have limited BW and we want
> > | to give priority to QoS flows. If some one comes with
> > | a Tx system which supports 100s Gb/s,(say 128 channel WDM system)
> > | Do we need to support the "special"  status for the QoS flows.
> > 
> > Nature of the traffic can be very bursty and suck up your 100s of Gb/s
> > bandwidth easily at any given time slot. Therefore, having just large bit
> > pipes does not solve the QoS problem.
> > 
> > Your delay = propagation time + queuing time + processing time equation
> > certainly works, if you have enough capacity left on the link at the time
> > of your request.
> >
> 
> Let me bring the economical and philosophical component into this
> discussion 
> that I tried not to touch so far but probably needs being spelled out:
> 
> 1. Any amount of bandwidth can be thrown at the problem. 100 Gb/s on
> transmission media
> 	and beyond are not a dream but as CPU, bus & memory technologies taught
> us, 
> 	matter of years at most. 
> 2. CPU problems, memory bandwidths, complicated lookups,
> per-flow-queining in ASICs and other 
> 	"traditional-router" problems that QMA brings up can be solved based on 
> 	the fact that "pigs with enough thrust fly
> 	just fine" (Ross) and made ATM such a hard sell. Thrust being here on
> one hand 
> 	IP being open and amazingly scalable (with hacks of course ;-)
> technology, 
> 	on the other hand the expected (and for some companies already real)
> significant
> 	revenues from networking and on the third hand progress in ASIC
> technology. 
> 3. Any amount of a free (or perceived as free) resource on this planet 
> 	has or is being depleted
> 	if it has any value. why is a question that has seemingly simple
> answers but can
> 	run very deep. I highly recommend http://pespmc1.vub.ac.be/Default.html 
> 	Therefore I believe that we'll always face congestion in today's model
> of the 
> 	Internet, no matter how much bandwidth you are willing to throw at the
> problem. 
> 
> Which leads to the core of what I try to say: QoS routing is just one
> possible mechanism
> how to provide certain guarantees about certain resources to the user.
> What the resources
> are and what other mechanisms could be used (network engineering or
> over-engineering, 
> shaping, CAC and others exist) depends on the pricing model which is
> basically a function 
> you try to optimize on. Since pricing in the Internet today is basically
> flat at 
> the end-user level, there is little or no incentive to provide
> guarantees and therefore 
> deploy something along the lines of QoS routing. Given a different
> pricing (and an according
> billing, that's of course the tough part ;-), different mechanisms could
> be 
> necessary and being deployed. The picture is particularly twisted IMHO
> since lots of things 
> you'd want to do are not necessarily
> what is possible (or being perceived as possible) from the technological
> perspective and 
> therefore widely different perceptions of what reality of data
> networking on the scale of 
> the planet should be clash in entertaining fireworks onto each other in
> recent years.
> 
> I hope that unifies or at least spells out lots of implicit assumptions
> that I sensed in 
> the different mails sent to this thread ...
> 
> 		thank you
> 
> 		--- tony