>> QoS is paying more for a guaranteed level of quality of throughput
Aren't there actually multiple meanings here?
Technically, QoS is also used to refer to the specific mechanism by which a client-server pair are enabled to negotiate a connection of known performance characteristics. This mechanism is various defined by several RFCs (e.g., RSVP) and the assorted platform API calls which implement them.
Administratively, QoS refers to the bitrate characteristics used to provision a connection, i.e., it is a service agreement parameter.
Subjectively, as Frank has pointed out elsewhere, QoS refers to a subjective experience and as such is capable of various interpretations.
In a marketing sense, QoS is defined to be that buzzword which attempts to maximize revenue at the boundary of customer dissatisfaction ... by creating resources out of, er, hot air.
The distinction I want to draw is that even in the "pure" world, QoS in the limited technical sense above does have a role ... notably within the client and/or server protocol stacks and process scheduling. By making a QoS API call on NT workstation, I am changing the behavior of the protocol stack AS WELL AS emitting RSVP frames.
Saying that QoS is irrelevant in a space of infinite bandwidth ignores it's other implications.
Additionally, there is never a time when infinite resources are reliably available ... resources will be consumed to the limit of their availability, even when initially perceived as infinite ... even 20Gb disks fill up sooner than one thinks.
When pure exists, applications which challenge pure will exist.
There will always be a time where QoS has a role to play ... the role of prioritizing the relative performance of applications. |
