KB,
"If broadband content delivery ends up requiring, at a minimum, a high degree of QOS than I believe that ATHM will have a hard to match service."
Earlier I stated that the term "virtual" was subject to colloquial and semantic interpretation. But when it comes to the potential for confusion, "virtual" has nothing on "QoS:"
1 - "QoS" is often used as a general blanket descriptor in the most subjective of ways, as in: "The Public Switched Telephone Network's quality of service is far better than VoIP's, in my opinion." Or, "the quality of service on Compuserve's network is very high."
And then the nerds get their hands on the term:
2 - "QoS" also connotes more specific criteria with regard to transmission performance parameters which can actually be measured. In this case, protocols are used to enhance QoS, such as ATM's CBR and IP's RSVP, diff-serv, etc. Semantics come into play here, too, since the switch-head regime refers to QoS, while the IP crowd cites "class of service," or CoS. And then there is Type of Service, or ToS, etc.
While traffic conditions remain relatively tame (which is being maintained by ATHM and others, by imposing use restrictions on telecommuting and multimedia at this time), QoS, as in (1) above, will remain high.
In order to keep it high as traffic becomes less tame, or as it becomes more erratic and voluminous, either one of two things or both must take place. Those two measures are to either increase bandwidth carrying capabilities per user, at both the user interface and on the backbone, or/and, invoke QoS enhancing protocols, as in (2) above.
While CableModem standards do take some of these QoS protocols into account, I'm not sure if they are being implemented universally, or if they would work with end points outside of their own boundaries due to either proprietary approaches used, or vendor incompatibilities, or differing choices of protocols, or all of the above.
QoS is NOT a no brainer, under any circumstance, especially in heterogeneous network environments. In ATHM's own closed network it stands a greater chance if it's invoked in an intramural sense, because of the uniformity which is made possible under a single roof. But I don't know how it will play when calls or sessions are established with "the outside world."
But protocols are only one part of the balancing act. And protocols mean nothing if the architecture isn't strictly administered. Network architecture goes beyond bandaid protocols, and network "design", incidentally. But NA is a whole 'nuther thread.
The other part is bandwidth, itself, which, in an increasingly unpredictable environment, is much more important, eventually demanding of nothing short of glass.
You can surmise for yourself what the variables are and what it will take if things get out of control. More bandwidth, more QoS enhancement. It's a constant balancing act.
Many think that QoS protocols, alone, without massive increases in bandwidth as time goes by, wont stand a chance. Others will seek to use the protocols, while limiting bandwidth, in order to create "value propositions" as they differentiate themselves by being able to give good quality over limited capacity pipes.
The question then comes back to this: How much wider can ATHM's partners and CableLabs pry the pipe open, when the time comes, for more bandwidth when it's needed.
Right now, the CableModem providers are already using artificial means to stem demand (ref: use controls). How much longer can "that" last. And what does this restrictive policy-setting so early in the service's history portend as things get tighter before they get looser?
Regards, Frank
|
