Subject: MPLS Performance analysis.....

From: B G Ramprasad Torati <[email-masked]>
Date: Tue, 23 May 2000 21:53:47 -0700 (PDT)

Hi

I simulated the LDP and MPLS packet switching parts of
MPLS by extending the network simulator 2.
Now I want to do the performance analysis between the
two forwarding paradigms( MPLS forwarding and normal
IP forwarding).

For this I have taken an example topology and did the
following things.
1. Using CBR agent I calculated the delays by using
loss monitor as the sink of the CBR packets. 
2. Using Ping agents I calculated the round trip time.

I did those using both normal IP and MPLS with LDP.
But I didn't get any difference between those two
forwarding paradigms. I calculated the no. of packets
lost using CBR agents. Still I got the same
performance for both the above. I used both Link state
and Distance Vector dynamic roting protocols while
doing this analysis.

So can anybody suggest how to do the performance
analysis. I am new to this, so please tell how exactly
I have to proceed in doing this analysis.

Thanks and Regards,
Ramp

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

---

From: Florian-Daniel Otel <[email-masked]>
Date: Wed, 24 May 2000 18:31:16 +0200 (MEST)

> two forwarding paradigms( MPLS forwarding and normal

Well, with the risk of getting flamed, i would argue that  if you want
to test _only_ the relative speed of MPLS switching vs. IP forwarding,
a simulated environment doesn't sound to be the most appropriate way of
doing this.

Even more, assuming  that you have access to  'real-world' code from a
vendor, comparing the relative speeds of the two forwarding paradigms
will be non-trivial: You will have to analyze the processing paths for
the two cases, install stubs in the software, etc.

All in all the relative performance analysis you want is irrelevant
IMHO: It all depends on the details of a specific implementation. So,
even that if, in theory, "MPLS switching is faster than IP forwarding
cause it's based on table indexing and not a longest-prefix match" (or
a similar mantra) I would take this type of  statements with a grain
of salt. Remember, "the devil is in the details".. 

Cheers,

Florian.

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 24 May 2000 12:44:16 -0400

G. Ramprasda writes,

> I have to proceed in doing this analysis.

You are missing the whole point of MPLS in your simulation.

MPLS transforms the problem of finding the next hop in the forwarding table
using in-exact match based on the destination IP address or a prefix to the
problem of finding an  exact match of the label. Typical, IP route look ups
are expensive and, the best of the binary search algorithm for route look up
have the complexity of log (base 2) 2N,  with N being the number of routing
table entries. The original algorithm implemented in BSD Unix had worst case
time of O(W**2), where W is the length of address. Moreover, the search time
is un-determinsitic as average and worse case search will take different
times. This is totally unacceptable for high speed routing where several
terabits of data has to moved in a second. Here comes the MPLS for your
rescue. See, this has nothing to with the routing protocols, but how
forwarding information is looked from the forwarding tables.

With a label in a packet, you can now have exact match look up - in an index
array or a hash table. This means that you can do search in O(1) time.
Moreover the search time is deterministic. Therefore, now you can have route
look ups lot faster and in deterministic times. This is what MPLS is all
about.

You are not going to see any performance difference with four sources going
through four routers in your simulator. Create a few thousand entries in
forwarding table and send some high volume data - the effect will become
vary clear. Try this exercise in your simulator.

Now moving on to CR-LDP effects. CR-LDP provides the ability  to control the
traffic over certain routes quite similar to IP-source routing. But with LSP
previously set for you, the packet doesn't have to carry multiple IP
addresses in its header, And the route can be different than provided by
hop-by-hop forwarding. If you wish to study  this, then study how use of
CR-LDP affects the over all traffic/network dynamics of the network both
from end-applications perspective, and also taking the network as a single
unit. How much more traffic can now be pushed in the network while
maintaining similar end to end delays?

Have fun.

--brijesh

Ennovate Networks Inc.

---

From: David Charlap <[email-masked]>
Date: Wed, 24 May 2000 13:07:05 -0400

> of salt. Remember, "the devil is in the details"..

Also note that you can't move packets faster than line-rate.

A modern PC running the router entirely in softwar can probably keep up
with line-rate forwarding between two 10M ethernet ports.  Which is also
the best that even a highly optimized hardware-based MPLS box can do if
it is only equipped with two 10M ethernet ports.  (For that matter, the
PC might even go faster, since it won't be running any signalling
protocols in the wires.)

Now, if you step up to a larger configuration - say, 48 ports of 100M
Ethernet, or 16 ports of OC-3, you'll find that the PC can't possibly
keep up will full line-rate.  There are, however, IP routers that can
keep up - as will the optimized hardware-based MPLS box.

If you go to even larger configurations - say, 16 ports of OC-48, you
will probably find that none of the IP routers can keep up with full
line-rate, but I would expect many of the MPLS boxes to run at or close
to this theoretical maximum.

If you go even further, say, to 16 ports of OC-192, I don't think
anybody's hardware can keep up, whether IP or MPLS.  (At least not right
now.  Hardware is always improving.)

What I'm getting at is simple:  If you want to compare technologies, you
need to take into consideration what your hardware is capable of and
what your requirements are.

For some combinations of requirements, hardware and system software, you
will not see the same results that simulations and theories will
predict.  The theoretically "wose" technology may end up working
better.  Or you may notice no difference whatsoever.  And for other
combinations, the theoretical results will be absolutely correct.

-- David

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 24 May 2000 12:22:07 -0700

Brijesh Kumar wrote:
	[..]
> problem of finding an  exact match of the label.

The relevance of this observation on MPLS network performance
is rapidly diminishing. Routers can be built that perform the
IP header lookups fast enough to keep large pipes full, at which
point whether it is an IP lookup or an MPLS lookup is irrelevant.

	[..]
> traffic over certain routes quite similar to IP-source routing.

This is relevant to the performance question. MPLS allows 
non-shortest paths to be established, and utilized - the key to
optimal network-wide load balancing.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 24 May 2000 17:16:13 -0400

> point whether it is an IP lookup or an MPLS lookup is irrelevant.

Yes. Core vendors have built necessary pipelined ASICs that can do wire
speed forwarding at OC48 rates, or perhaps even at better speeds (?) with a
forwarding table of over 50,000 plus prefixes. For that they had to
implement some of the latest search techniques (such as controlled prefix
expansions or similar) in HARDWARE. However, with the label look up, even
low cost hardware can fill large pipes (just one add and one read
instruction).

Cheers,

--brijesh
Ennovate Networks Inc.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 May 2000 17:52:03 -0400

In message <[email-masked]>, Florian-Daniel Ot
> of salt. Remember, "the devil is in the details".. 

Florian,

The plain fact is that it just doesn't matter.  The shortest speed of
light delays in any WAN application is on the order of a few
milliseconds.  Queueing delay can be hundreds of milliseconds if the
outbound interface is congested.  Modern routers forward IP in a few
10s of microseconds (on fast interfaces).  If the path is the same and
the same queue is used, then the difference in forwarding speed
between an IP route lookup and an MPLS label lookup isn't even
measurable and in some (most?) routers the difference is exactly zero.

Curtis

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 24 May 2000 15:12:47 -0700

Brijesh Kumar wrote:
	[..]
> However, with the label look up, even

My point is that such distinctions are falling (have fallen?) into
just so much background noise compared to (a) the overall costs of
operating a network, and (b) the traffic engineering capabilities
of non-shortest path LSPs (which probably reduces operational costs
far more over a year than the few $$ savings in hardware associated
with the label lookup).  Not that your observation is wrong, just
probably not a key influence on "MPLS performance" overall.

cheers,
gja

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 24 May 2000 14:24:29 -0400

> I would strongly disagree with two statements presented above.
>

--
200 Nickerson Road        Phone 508 786 2117
Marlborough, MA 01752     Fax   508 460 3332
Lucent Technologies       [email-masked]
Core Routing, INS

---

From: Florian-Daniel Otel <[email-masked]>
Date: Thu, 25 May 2000 08:15:06 +0200 (MEST)

I couldn't rezist to beat up the dead dog with just one more posting...;>

> measurable and in some (most?) routers the difference is exactly zero.

That was my point exactly when i said that this type of measurement,
even done with production router software, is irrelevant. As some
people already pointed out, IP routing software can be (and is) done
as fast as MPLS switching, e.g. hardw implementation, pipelined ASICs,
hashing, advanced searching techniques, routing table compression, etc,
etc. It's a whole world here, i don't even dare to open this
Pandorra's box here..

Back to the original posting, I really cannot imagine any non-trivial
tests aiming to prove that  'MPLS is faster than IP' (yes, the
statement doesn't make much sense). One such example might
(arguably) be the ability to do source routing at lower costs than
IP-in-IP tunneling/ IP source routing.

Again, MPLS strongest points aren't performance but the network
engineering capabilities it offers,

Cheers,

Florian.

---

From: Florian-Daniel Otel <[email-masked]>
Date: Thu, 25 May 2000 11:01:04 +0200 (MEST)

> What are the network engineering capabilities MPLS offers extra over IP.

Well, it's a rather long story and I will not discuss them here. I suggest
you do a bit of basic MPLS reading first. A good start can be  the
IEEE Communication Magazine issues of Dec. 1999 and Jan 2000 and IEEE
Network Mag. of Mar/Apr 2000. They are general and recent enough to
provide enough food for thougt. 

Alternatively, look for general MPLS white papers and presentations
and read them w/ a critical eye. They should give you at least a
couple of hints.

> HOw I can show them using the simulation. I want to show how MPLS is
> advantageous over normal IP in as many aspects as I can, using my MPLS
> simulation (using ns).
> So please help in this.

Again, try to do some  homeworks first and then ask more specific
questions. For an good example on  how a simulation environment was
used to prove some of MPLS points please see

http://www.cis.ohio-state.edu/~jain/papers/mpls-te-anal.htm

> B G Ramprasad Torati

Good luck,

Florian.

---

From: B G Ramprasad Torati <[email-masked]>
Date: Thu, 25 May 2000 14:15:30 +0530 (IST)

HI

So please help in this.

Thanks and Regards,
B G Ramprasad Torati

---

From: "dave o'leary" <[email-masked]>
Date: Fri, 26 May 2000 07:00:55 -0700

>measurable and in some (most?) routers the difference is exactly zero.

In addition to latency considerations as outlined above, another
concern relative to the performance of the lookup engine is the
ability to keep up with line rates on the inbound side of the router,
that is, if the lookup engine can't keep up with line rate, there needs
to be a buffering mechanism on the router/switch ingress.  The
buffers by nature need to be limited in size and hence the possibility
for packet/frame drops, which of course affect the network performance
as seen by the end systems.

                                                 dave