The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

> So, our experiments are set up to find out what's the essential
> part of MPLS networks if it's implemented on the same hardware 
> platform. ( like that of upgrading IOS version). In order to focus
> on switch routing itself, we don't invoke techniques like TE in 
> the experiments. And, we do the experiments between IP and MPLS with
> the same queueing mechanism, and the same packet classification 
> mechanism. 
> 
> The experiment results shows, no matter how network is loaded,
> if e2e bandwidth reservation is done packets transferring LSP show
>  smaller IPDV and a little higher e2e delay. As the testbed is very 
> small, we take the reason as: MPLS decap/encap smooth packet's entering 
> procedure  into queue of outgoing interface.

ok.  good.  great.  fine.  but you're testing a specific
implementation.  it may be yours, it may be mine, it may be someone
else's.  but any ipdv and other such performance characteristics are
not that of the mpls architecture, but of the implementation you're
testing.  I'm not sure if you agree with me or not, can you please
confirm that you do or don't?

> 
> On the other hand, if no bandwidth reservation is done: if network
> is lightly loaded there is nearly no difference in e2e delay between
> IP routing and MPLS switching, while MPLS shows bettter in IPDV; 
> if network is heavy loaded MPLS behaves worse in both aspects than
> IP does. As we know, the way to control jitter is smoothing packet
> transfer 
> by controling queueing behavior, and we find the overhead of IP routing
> and MPLS switching is nearly the same. This means in our testbed MPLS's 
> encap/decap introduces something good to jitter control.
> 

MPLS encap/decap changing delay/jitter characteristics for better or
worse is a byproduct of the implementation.

> We extend the result to a path consisting multi-hop because middle-LSP
> could be considered a tunnel connecting LERs, and also it directly 
> applies to LSPs consisting LERs. So, if e2e qos for individual
> connection
> is considered in MPLS network, it should take the LSP which pass a path
> as highly loaded as possible.
> 

I don't get this.  If you want qos, surely you want to strive for
low-load paths?

> >From the discussion above, I come to know that implementation details
> do have effect on e2e performance, and commerical implementation
> of MPLS may introduce negelectable overhead in encap/decap overhead.
> But it exists and accumulated result will come up when network is heavy
> loaded.
> 

Yes, it exists, but it _depends on the implementation_.  

> And, also delay/IPDV is affected by fluctuation in network, we consider 
> we extend the instant we observe. 
> 
> Some other people says that we could smooth any problem by
> overprovisioning.
> But, a phenomenon of current network is: sometimes when a part of
> network
> is heavy loaded the adjacent part idles. Why shoudn't we make use of 
> those idled resource ? 

I agree.

What does any of this have to do with policy routing, as you state
below?  Why do you give the impression that policy routing is only
necessary for MPLS networks, and not IP?  What, for that matter, is
policy routing?  I know what I think it is, but that's because we
happen to implement a feature called "policy-based routing".  I have
no idea whether this is what you refer to or not.  Also, if you
continue to insist on confusing architecture with implementation, you
may want to remember that a policy routing implementation will
probably have adverse effects on delay/jitter, as there's generally
more work involved in policy-routing a packet than in normal routing
or switching or whatever of the same packet.




eric

> 
> regards
> 
> 
> 
> 
> > 
> > On Mon, Dec 09, 2002 at 08:41:09PM +0800, Jing Shen wrote:
> > > It's main conclusion of our experiments that policy based routing must
> > > be used with MPLS if e2e QoS is considered carefully.
> > 
> > Why?
> > 
> > eric
> > 
> 
> -- 
> Jing Shen
> 
> State Key Lab of CAD&CG
> ZheJiang University(YuQuan)
> HangZhou, Z.J. 310027
> P.R.China
> 
> Tel: +86-571-87932423
> Mobile: (0)13516813753
> Email: jshen@cad.zju.edu.cn
> 
> **********************************************************************
> * The SunShine of life is made up of very little beams which is      *
> *  bright all the time                                               *
> **********************************************************************