Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI??

From: "Aris Kyriakopoulos" <[email-masked]>
Date: Thu, 19 Apr 2001 14:17:52 -0400

Hi David,

No argument about the fact that the ATM QoS model has more features and is 
more mature than the IP QoS model.  However, in order for non-ATM 
applications (specifically IP) to take advantage of ATM QoS, you need to 
be able to translate the IP QoS requirements into ATM signalling.

As far as I am aware, there is no way you can do this in a 
dynamically-routed IP network.  Sure, you can map static IP routes to ATM 
(S)PVCs.  Even then, what mechanisms are there to distinguish between 
different IP flows over the same route (e.g. by ToS, TCP/UDP ports)? 
Because to ATM, all IP packets are created equal, right?  To me, this is 
one of the good reasons to use MPLS: using ATM switching hardware to 
provide IP QoS.  Even though the IP QoS model is not as rich as ATM's, at 
least ATM LSRs provide some sort of QoS mechanism for IP that CLIP/MPOA 
simply do not.

I agree that RSVP and CR-LDP probably need to provide better delay 
information than they currently do in order to support delay-sensitive 
applications.  That is the key, though; these metrics need to be added to 
IP QoS.  Or maybe the IP QoS model needs to be extended to have 1-to-1 
mapping with ATM QoS.  At least on ATM LSRs.

Regards,
Aris

David Charlap <[email-masked]>
Sent by: [email-masked]
04/19/2001 01:44 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: ATM-LSR do they use OSPF/IS-IS or PNNI??

> I agree with your points above. However, I don't think there is
> anything stop MPLS implemented with a hard QoS mechanism like ATM
> has done. A good LSR with the necessary traffic management
> infrastructure (queuing and scheduling) can achieve the same
> level, if not better QoS.

One clear advantage of ATM is that ATM provides more parameters for
tuning QoS than RSVP or CR-LDP do.

None of the current MPLS signaling protocols provide a way to specify
delay characteristics as part of QoS.  ATM's QoS allows signaling of
delay and delay variation.  RSVP's ADSPEC object allows the collection
of delay information, but there is no way to request that the network
try to establish an LSP that conforms to particular delay
characteristics.

Delay information is important for circuit-emulation and for real-time
streaming applications (like voice/video).

Of course, delay factors are much less of a problem today (with
extremely fast backplanes and OC-x interfaces) than they were in the
recent past (with slower backplanes and DS-x interfaces), but I don't
think we're yet at the point where they can be completely ignored.

I think there are still some applications where delay and delay
variation are important even on today's hardware.

Of course, there's no reason why delay characteristics couldn't be added
to either RSVP or CR-LDP in the future.

-- David

---

From: Eric Rosen <[email-masked]>
Date: Thu, 19 Apr 2001 14:48:40 -0400

I think this is a good time to repeat a remark that Luca Martini made at the
PWOT BoF in Minneapolis:

        If people wanted the ATM  service model, we'd all be run-
        ning ATM to the desktop now.

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 19:13:57 -0400

Eric Rosen wrote:
> 
> I think this is a good time to repeat a remark that Luca Martini
> made at the PWOT BoF in Minneapolis:
> 

That's incredibly oversimplified.  I'm rather surprised to see you take
such a cheap shot in this group.

There are a great many reasons why ATM hasn't displaced Ethernet on
people's desktops, including the price of switch ports and a routing
protocol that would have a hard time scaling to the size of the
internet.

The fact that most people don't run ATM to their desktop doesn't mean
that ATM-style QoS wouldn't be appreciated over non-ATM media.

-- David

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 19:14:20 -0400

Aris Kyriakopoulos wrote:
> 
> No argument about the fact that the ATM QoS model has more features
> and is more mature than the IP QoS model.  However, in order for
> non-ATM applications (specifically IP) to take advantage of ATM QoS,
> you need to be able to translate the IP QoS requirements into ATM
> signalling.

Correction: In order for MPLS applications to take advantage of ATM QoS.

There are other ways of running IP over ATM, even though they are not
popular as core technologies.

> dynamically-routed IP network.  Sure, you can map static IP routes
> to ATM (S)PVCs.  Even then, what mechanisms are there to distinguish
> between different IP flows over the same route (e.g. by ToS, TCP/UDP
> ports)?

Assigning any QoS other than best-effort to IP traffic requires some
degree of policy control.  DSCP bits may be used, so can source
addresses, physical interface, L4 information, etc.

> Because to ATM, all IP packets are created equal, right?

Once the packet gets into the ATM VC, there is no IP, just cells.  It is
the edge router (which puts the IP packets into the VC) which must have
the ability to classify the packets and determine what goes where.

Which is exactly the same in the MPLS world.  Once a packet is in an
LSP, it is forwarded according to that LSP's rules.  Yes, a certain
amount of per-packet QoS is available if E-LSPs are used, but the edge
router must still do the bulk of the packet classification - to
determine what LSP to put the packet on and to determine what the EXP
bits should be set to.

> To me, this is one of the good reasons to use MPLS: using ATM
> switching hardware to provide IP QoS.  Even though the IP QoS model
> is not as rich as ATM's, at least ATM LSRs provide some sort of QoS
> mechanism for IP that CLIP/MPOA simply do not.

The host-side software for CLIP/MPOA (when ATM is run to the desktop)
can and does provide the ability to setup application-specific VCs with
different levels of QoS.  There's no reason why an edge device (serving
to gate an IP network into ATM) couldn't do the same thing.

As for ATM switching hardware, there's no reason why non-ATM hardware
can't do the same thing.  ATM hardware has some definite problems when
it comes to MPLS - VC (label) merging is difficult, cell tax, no native
label-stacking mechanism, etc.

> information than they currently do in order to support delay-
> sensitive applications.  That is the key, though; these metrics
> need to be added to IP QoS.  Or maybe the IP QoS model needs to be
> extended to have 1-to-1 mapping with ATM QoS.  At least on ATM
> LSRs.

There's no need to use the ATM-style parameters.  As a matter of fact,
many wouldn't be appropriate without modification anyway, since they are
in terms of cells, not bytes or IP packets.

The IntServ parameters (used by RSVP) are very good for what they
specify.  They just don't specify enough.  But IntServ is extensible. 
There's no reason why additional services couldn't be defined that
contain delay parameters.

-- David

---

From: Eric Gray <[email-masked]>
Date: Thu, 19 Apr 2001 19:36:27 -0400

David,

    You can't exactly do ATM style QoS over non-ATM media.

    The thing that allows an ATM switch to contemplate delay
variation separately from delay is the fact that ATM switches
switch data in fixed size chunks.  When the size of data chunks
can vary, the only practical way to control delay variation is to
try to control delay.  Therefore, with IP packets on non-ATM
media, you can't even begin support two knobs for delay and
delay variation.  So why would you undertake to add complexity
by trying?

--
Eric Gray

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 19:51:52 -0400

> delay variation.  So why would you undertake to add complexity

Variable-size frames don't make it impossible.  It just means you are
forced to work with a coarser granularity (defined by your configured
MTU size.)

-- david

---

From: Eric Gray <[email-masked]>
Date: Fri, 20 Apr 2001 08:38:39 -0400

David,

    I'm sure some smart person or another has written a paper
on this, but I don't have the time to do a full-blown literature
search right now.  While what you are saying is technically
true, I believe it has very little applicability in practice.
You can see that this works by imagining that an implementation
might treat MTU propagation time exactly the same way that ATM
treats cell propagation time.

    But this is very ugly.  It is so coarse that many would be
hard pressed to consider it a useful guarantee.  It also seems
to require deliberately inserting latency (N times an MTU
propagation time) for all affected traffic (to allow for packet
shuffling to accomodate the guarantee).  And it would be
very difficult to allocate forwarding resources efficiently and
still deliver guaranteed delay variation deterministically.

    Without making any moral judgement about why it is so,
many people are more concerned about having a bounded
delay than they are about having a bounded delay variation.
And with a bounded delay, you get bounded delay variation
for free.

    My opinion: there are two models here and trying to make
technologies support both models may not be a good idea.

--
Eric Gray

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Apr 2001 14:29:42 +0100 (BST)

On Thu, 19 Apr 2001, Eric Gray wrote:

> switch data in fixed size chunks. 

How does this help variable-sized AAL encapsulations?

L.

I've always wondered.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>