RE: Q:Why router with ATM interface comes out earlier than pure SONET interface?

Mailman List Mirror (Read Only)
1

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

2

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.