The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

David,

    I believe the IP model for control of delay variation
is to control delay.  This approach has its own problems,
but there are complexities associated with having distinct
knobs for delay and delay variation and these complexities
will probably get in the way of building an implementation
that will work this way with IP and still be reasonably
scalable.  Also, there's a well known 'tax' associated with
the approach that ATM uses to control delay variation.  :-)

--
Eric Gray

You wrote:

> 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