Hmm. How would you assure per-application Quality-of-Service
the network explicitely know about application behaviour, i.e. signalling
those parameters and establishing some state within network nodes - read:
connection oriented ? How would you ? Even IP's approaches to this problem
Clearly define your requirements. Otherwise this discussion is academic.
Give me a scenario and I'll engineer you an IP QoS traffic engineering
How many "different" application specific behaviors does one need and make
up a manageable quantity of CoS across a service provider network? I don't
think you'll ever see more than half a dozen or so anytime soon.
How exactly do you sell 64 different classes of service to customers? "I
would like CoS #57, please." -- "Would you like fries with that, sir?" How
is Cos #57 different from CoS #56 or #58?
Signaling assumes connection oriented networking. The question is whether
you really need to "signal" across the core of a network. Why does the
entire core need to know about everything?
IP QoS is fundamentally different from a traffic engineer point. You don't
define pipes, like in ATM. You don't associate QoS characteristics to a
given pipe, because you don't have pipes like in ATM.
You define rates, you define drop policies and queuing policies on a per
<insert the a defineable *packet* characteristic here>. My point being that
all you ATM QoS bigots need to stop thinking like ATM and forget the idea of
a connection pipe at the transporrt layer, and listen to us IP QoS bigots
:). Perhaps we actually do have a point, and one doesn't actually need ATM.
Am I making any sense? I think a Q&A model for this discussion would be
best, especially considering the "bandwidth" limitations of all