[e2e] how far it queues?
David P. Reed
dpreed at reed.com
Wed Oct 2 09:17:54 PDT 2002
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
At 12:13 PM 10/2/2002 -0300, Alexandre L. Grojsgold wrote:
>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
>Maybe I used the wrong search engines, maybe I am asking myself the wrong
>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
More information about the end2end-interest