[e2e] how far it queues?

[David P. Reed]

With respect to the folks who devote huge energy to this "QoS" research, I 
would point out that there is little evidence that the problem takes the 
form that is assumed in the research.

As you point out, the QoS techniques have a payoff only at those times when 
demand exceeds capacity for a period of time, and presume that there is 
"lower priority" traffic accessible within the narrow context of the router 
that can be delayed or dropped.

The information available in local contexts about the knobs that can 
control the global sources of contention is very limited, and also the 
scope of action is limited.

At best, then, router-based QoS is dependent on application level 
management of priority.

If applications don't take the primary role in assuring QoS, a router 
acting on its own only transfers the problem to other routers, which will 
back up and congest as well.

So the big problem in achieving QoS is what we call an "end-to-end" problem 
that must be solved outside the network.  At best QoS can be an 
optimization of that.

The QoS research field has steadfastly pursued an agenda which tries to put 
the QoS function entirely within the network routers.   It's not surprising 
that it has largely failed to do so.  It can only succeed when the 
statistics of traffic fit relatively simple parameterized models, or when 
it takes into account the much larger factors surrounding the network, such as:

- economic incentives to add capacity to the network when QoS goals are 
more easily achieved that way,

- administrative behavior, such as moving bulk email transfer to nighttime,

- user response to poor quality of service by taking actions available to 
the user,

etc.
At 12:13 PM 10/2/2002 -0300, Alexandre L. Grojsgold wrote:


>Hi,
>
>As a curious net admin, and having read a lot about QoS, I got engaged in
>searching more detailed information on what really goes on inside the
>boxes, trying to figure out how far can QoS mechanisms really improve the
>way packets are forwarded. Or how much QoS features actually and
>noticeably make life better to privileged traffic.
>
>
>Up to my undestanding, give that interface speeds are mostly fixed and
>routers can't do much to push bits faster down the cables, and given that
>most of present days routers easily operate at wire speed, the only thing
>a router can do to increase the quality of service figures of a given flow
>is to change the way its individual packets are queued at the output
>interface they are supposed to go.
>
>It means that the influence of QoS processing over a flow will be more
>noticed for long queues than for short ones. It means also that if queue
>length is zero most of the time (meaning that the interface is idle or
>just starting to transmit a packet), QoS will do little - most of the
>time. And that for hi speed interfaces, where a typical 1500 byte packet
>will be completly sent in a sub-milisecond time frame, passing around a 3
>or 4 packet queue is not of much help.
>
>
>Again, trying to figure out how things happen in real life, with real
>traffic, to my bigest surprise I failed miserably in finding papers and
>articles that showed queue behavior and mean queue lengths within internet
>routers.
>
>
>Maybe I used the wrong search engines, maybe I am asking myself the wrong
>question :(
>
>
>Any hints? What I am trying to find out is the mean length of an output
>queue in a typical router, within a typical (backbone) mesh, in normal
>non-congested operation.
>
>
>-alexandre.