The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

On Sat, Dec 07, 2002 at 11:06:02AM +0800, Jing Shen wrote:
> Although Eric's idea is taken by many people , our experiements shows
> this
> is not the truth at least with the situation of our testbed.
> 
> In fact we set up a small testbed consisting a Linux based MPLS engine.
> In order to focus on difference between forwarding performance
> difference
>  between MPLS and IP, we use CBR traffic with static routing table.
> 
> The testbed is consist of  3 hops of MPLS(IP) forwarder between source
> and 
> destination. The experiments shows that:
> 
>   If the hardware and software system is kept at the same level, then:
>   1) TCP throughput of MPLS is a little smaller than IP when path MTU is
> the same.
>      and difference increases when path MTU decreases.

MPLS packets are 4 bytes (or more) bigger than IP packets.  If you do
not allow for this in your link MTU, then you have smaller effective
bandwidth inside TCP.  Allow for that in your link MTU (as any
reasonable implementation should) and you don't have this problem.

>   2) For UDP traffic,
>      a) when best-effort policy is applied, if link along the path is
> lightly loaded (below 30%)
>         e2e performance difference IP and MPLS is nearly the same while
> the IPDV of MPLS is 
>         smaller than IP forwarding; if the link along the path is
> heavily loaded, QoS of MPLS
>         is worse than IP forwarding. the same result is applied to loss
> rate.
>      b) when resource reservation is applied, both method could
> guarantee the e2e delay but
> 	MPLS shows better IPDV value with a little longer e2e delay.
> 
>   We found the reason for this phenomenon is the
> encapsulation/decapsulation procedure of MPLS, and
> the processing of MPLS forwarding. 

So this is a test of your forwarding equipment.  Equipment which takes
zero or negligible time to perform this encap/decap will not have this
problem.


>  Although we have not experimented with Cisco's express forwarding
> and the like, and we do not experiment with large scale system with
> real internet traffic pattern, we concern that the result could
> applied to large scale network.

I'm concerned about that too, because it means that you're building a
large-scale network out of Linux-based software-forwarding devices.
But even if you do have a performance hit at encap/decap, you only do
label push/pop at the edges of the network, so you'd only take this
hypothetical hit at the edges, making scale a nonissue for your
particular imaginary problem.


> The reason is, 1) a small testbed could
> be considered as a 
> emulation of tunnel through large network , and some of large network
> use LER-to-LER LSP;

See earlier point about performance hit at the edge only

>  2) we focus on forwarding difference between IP and MPLS, and we
> think technique like CEF and per-port cache could be applied to both
> technologies.

The fact that you're considering different lookup methodologies for IP
and MPLS suggests even further that what you're profiling is your
implementation, and not either 
		a) a purely hypothetical situation (a la OPnet or
		whatever)
		b) a particular router implementation

I have no problem with you testing your own implementation; I have a
major issue if you try to generalize those results to claim that your
specific behavior is in fact an artifact of the protocol itself.

> 3) the same queueing
> mechanism is applied to both 
> technologies in our experiments. 4) comparison should be taken at the
> same level of cost.
> 

I don't understand point #4.  What is 'level of cost'?

> The paper on this experiment will be published on Communication Journal
> ( Chinese) this month. 
> any comment will be highly appreciated.

Any chance of getting a version in English?



eric

> 
> regards
>         
> 
> > 
> > No, not really.  MPLS lets you apply QoS using EXP bits, just like you
> > can with IP Precedence; any mechanisms you can use with IP Precedence
> > to reduce jitter (various queing schemes) are equally applicable with
> > MPLS.  Using MPLS-TE can make you more likely to avoid congestion and
> > therefore less likely to experience delay and jitter, but from a
> > queueing perspective it's the same with MPLS and with IP routing.
> > 
> > eric
> > 
> > > Please let me know
> > >
> > > Thanks
> > >
> > > J.C.Ramesh Babu
> > > Technical Specialist.
> > > Communications and Products Division
> > > Infosys Technologies Limited
> > > Electronic City,
> > > Hosur Road,
> > > Bangalore.
> > >
> > > Ph #
> > > Off : 91-80-4166472
> > > Res: 91-80-6592375
> > 
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 
> -- 
> 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                                               *
> **********************************************************************