RE: Q:Why router with ATM interface comes out earlier than pure SONET interface?
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
On Mon, 3 Aug 1998, Christian Kuhtz wrote:
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?
Many years ago I used an operating system from TI called DX10. It had two major process priorities, forground and background. This was all most people ever used but these actually were the lowest of 64 different priority levels. The rest of the levels were only used by people doing esoteric real-time applications. I think you'll find the same thing with IP QOS. Most people will use three priorities, best effort, faster, fastest. The other 61 higher priorities will only be used by people doing esoteric real-time things.
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?
Not the entire core, just the elements of the core that participate in a given circuit path. And then only for special applications that won't work without it.
You define rates, you define drop policies and queuing policies on a per <insert the a defineable *packet* characteristic here>.
But all packets sharing this definable characteristic and thus being treated in an identical manner, could be considere to be just like a connection pipe. And in some applications, these packets may indeed be a pipe carrying an IP tunnel between two points. Even in ATM there really are no pipes but with some combinations of settings the delivery of a data stream across an ATM mesh can be given characteristics that match those of fixed circuit delivery closely enough that it makes sense to call it a circuit. IP QOS is no different. The descriptive terms depend on what level you are speaking at. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com Check the website for my Internet World articles - http://www.memra.com
participants (2)
-
Christian Kuhtz -
Michael Dillon