Hmm. How would you assure per-application Quality-of-Service without letting 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 are stateful.
Clearly define your requirements. Otherwise this discussion is academic. Give me a scenario and I'll engineer you an IP QoS traffic engineering solution. 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 participating parties.. Cheers, Chris -- Christian Kuhtz, BellSouth Corp., Sr. Network Architect <ck@bellsouth.net> 1100 Ashwood Parkway, Atlanta, GA 30338 <ck@gnu.org> "Legalize free-enterprise murder: why should governments have all the fun?" -- /usr/games/fortune