The MPLS WG Archive

["Donkin, Richard" <rdonkin@orchestream.com>]

> -----Original Message-----
> From: Geoff Bennett [mailto:geoff.bennett@marconi.com]
> Sent: 20 April 2001 09:40
> To: HANSEN CHAN
> Cc: Donkin, Richard; MP LS; mpls-ops@mplsrc.com; mpls@UU.NET
> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI??
> 
> 
> Hard QoS architectures are hard to build.  ATM got it right for the most
> part, but there would be a strong argument that the way ATM does QoS (on a
> VC basis) will not scale to networks as big as the Internet. With MPLS we
> can aggregate things nicely, but in my mind this is not QoS, it's CoS.
The
> tradeoff we seem to be faced with is the "quality" of our QoS architecture
> vs its scalability.

This is quite true - I have yet to see anyone doing hard QoS in a highly
scalable way.  Back in the mid-Nineties, there was much talk of public ATM
networks providing SVCs to customers, but this did not materialise, and the
same has happened with RSVP in the IP world.
 
> ATM also has the advantage that it's Connection Oriented from end to end.
> One of the reasons it can deliver such a hard QoS assurance was that the
> application itself is able to negotiate with the network to ask for the
> explicit QoS requirements, and to get the network's agreement that these
> resources were available.  To duplicate this with MPLS we'd have to extend
> RSVP signalling to the host (or maybe to the voice gateway in a VoMPLS
> installation).  I know this has been discussed, but is at a very early
stage.

The real advantage here is application signalling of QoS, connection
orientation is just the simplest way to implement this - if such signalling
can interface with a connectionless core (see the RSVP to DiffServ mapping
work in the IETF), you can get the best of both worlds.  Of course, building
such a network is still a research topic, involving bandwidth brokers that
make admission control decisions for the DiffServ core.  The RSVP community
is also working on scalability improvements (in router state and signalling
overhead), which may help in this area through aggregation.

There are very few applications that can generate ATM or RSVP signalling -
Microsoft provides a GQoS API in Windows 2000 that addresses this, but it's
not clear how many applications use this (and many of them will just signal
the application + user identity, allowing a policy server to assign a
DiffServ marking rather than a hard QoS).  Until we have smarter middleware,
or network gateways that generate such signalling, this chicken and egg
problem (no apps, so no hard QoS networks, so no apps) will probably
continue.
 
> Another advantage of ATM in terms of QoS is the fixed cell size.  Any
> fixed-PDU technology will have the edge over a variable PDU technology
when
> it comes to QoS.  Before I ignite a cells vs frames debate let me say that
> I believe the (many) advantages of a variable length PDU infrastructure
> (especially at very high speeds) outweight the QoS benefits of fixed PDU.
> In other words, I'll go along with the assumption that if you're
> transmitting at a high enough speed, the CoS you can squeeze out of a
> variable PDU network will one day be "good enough" (if you over-provision
> the network sufficiently).

I don't think you need to overprovision the core network if you are using
variable size PDUs - as long as you fragment large packets/frames at the
link layer on lower speed links, the higher speed links will take care of
themselves (assuming a reasonable upper bound on PDU size).

This is now somewhat off the topic of MPLS, but in theory you could have a
mapping from flow-based RSVP into RSVP-TE so I guess there is some relevance
to MPLS in the longer term if this can be worked out.  In practice, most
people seem to be building CoS networks with MPLS, and would be more
interested in mapping per-flow RSVP onto DiffServ and MPLS CoS, mediated by
a bandwidth broker for the MPLS/DiffServ domain.

Richard


--
This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed.  If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited.  If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents.  Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated.