[e2e] QoS vs Bandwidth Overprovisioning

[demir]

>         Bandwidth overprovisioning has worked for most of the
> last decade.  It appears not likely to cease being a useful
> approach anytime soon.  As time goes to infinity, no one can
> predict very accurately, me included.

It has worked because the services provided by "bandwidth
overprovisioning" has satisfied the needs of applications emmerged in the
Internet with support of "end point adaptivity" that is an implicit
service level specification (i.e. TCP congestion control and
avoidance). To me, that's why TCP-friendliness become an important
issue. The model (implicit service level specification + bandwidth
overprovisioning) supports the service expectations of vast amount of
Internet applications. However, there are applications that ask services
beyond (more quality) where the model can't provide the way it is
defined. That's where we need more costly QoS architectures. Currently,
the simple model works fine because of deployment issues with sacrifice
of eliminating more QoS-needy applications. I tried to describe the whole
spectrum in one of my previous emails as "expectation", demanding
"traffic" and available/provided "capacity". "expectation" might not be a
good word to express this though.

>         Sure.  We run lots of PC boxen with 133 MHz CPUs today.
> In setting up a CVS server recently, we deliberately bought
> the least expensive PC hardware we could obtain because its
> more than enough CPU performance and we could save a lot of
> money.  No one in my office is planning any upgrades either
> to the new Sun Ultra-3 CPU nor to the 1+ GHz PC CPUs, because
> we are satisfied with what we have.

I don't think that above anology is "complete" to defend the claim. 

Alper K. Demir