Subject: RE: MPLS Performance analysis.....

From: Shahram Davari <[email-masked]>
Date: Wed, 24 May 2000 08:34:44 -0700

Hi,

The path taken by MPLS+LDP is exactly the same as the path taken by
IP+OSPF/IS-IS. To see any difference you must use CR-LDP and use a less
congested path for your LSP.

Regards,
Shahram

>-----Original Message-----
>From: B G Ramprasad Torati [mailto:[email-masked]]
>Sent: Wednesday, May 24, 2000 12:54 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: MPLS Performance analysis.....
>
>
>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: "Khaled Elsayed" <[email-masked]>
Date: Thu, 25 May 100 01:50:01 -0700

As other people said, it is not surprising you would get the same results. You would need to come up with a scenario where if you use tradional routing versus proper traffic engineering as in MPLS, the difference in the peformance will be clear. However, your scenario should be as realistic as possible, i.e. it can happen in an IP-based network. This is the difficult part. The rest should be easy.

BR,

Khaled Elsayed

---

From: Vishal Sharma <[email-masked]>
Date: Thu, 25 May 2000 11:29:47 -0400

Ramprasad,

It is unlikely that anyone will be able to give you a ready-made simulation scenario. I think
Florian made some good suggestions on the readings.

I think what is missing in your plan is a clearer objective. You sort of stated
it when you said :
>  want to show how MPLS is
> advantageous over normal IP in as many aspects as I can, using my MPLS
> simulation (using ns).
(I think it still might be useful to ask why you want to do this, and what
is the final purpose of doing this exercise.)

Assuming this is your aim, you have to ask yourself (a) in what respects is MPLS
stated to be better than IP and (b) what would be a way to design a simulation
to demonstrate that.

As Brijesh mentioned in an earlier email, a worthwhile comparison is really
to examine what MPLS provides in terms of traffic engineering capabilities
relative to either pure IP routing, or IP routing augmented with some
traffic engineering capabilities in the interior gateway protocols (IGP), such as
equal-cost multipath, or metric tuning.

If this is the aspect that one believes MPLS could be better in, then the following
could be one simple way to go about it.

So let's say that at a first-level you assume the following:
 (i) a network topology (the nodes, their locations) and parameters (the link capacities, and 
metrics).
 (ii) a traffic matrix for the network (that is, static demands; a simplistic scenario, but 
probably
a good starting point, especially if you consider backbone networks that carry aggregated
demands that are likely to be fairly constant [they might have some variation about a mean
value, but one could assume for starters that the variation is small]).

The aim of the comparison then could be to comapre the following (Brijesh already pointed
this out)
(a)  The delay experienced by the traffic, with and without MPLS traffic engineering.
(b)  The total amount of traffic that could be served, with and without MPLS traffic engineering.
(Given any traffic matrix, you may not be able to serve all of it, so you'd have to see
how much of the demand you can serve in the two cases.)

(We will ignore forwarding performance, since as people have pointed out, that is
 implementation dependent, and is not really a differetiator for MPLS anymore.)

Please note, that to do this your simulation will, in addition, have to run some algorithm(s)
that can decide exactly which MPLS LSPs to set up, and how much bandwidth to assign
to each of them to serve the traffic demands specified in your traffic matrix.

So in effect, what you will really be testing is the "goodness" of these LSP placement
algorithms, because the better these algorithms are in finding "good" paths through
the network (assuming that these paths can then be setup using MPLS signaling protocols), the
better is likely to be the performance of the MPLS-based scheme
relative to IP routing.

-Vishal

On Thursday, May 25, 2000 4:58 AM, [email-masked] [SMTP:[email-masked]] wrote:
> Hi,
>
>
> Can U suggest an example scenario of what U mentioned here with all the
> details of link bandwidths ,packet sizes, Type of packets ...etc. As I am
> new to this kind of analysis, I don't have any realistic scenario at
> present.
>
> Thank U very much
> B G Ramprasad Torati
>  On Thu, 25 May 100, Khaled Elsayed wrote:
>
> >
> > As other people said, it is not surprising you would get the same results. You would need to
> > come up with a scenario where if you use tradional routing versus proper traffic engineering as
> > in MPLS, the difference in the peformance will be clear. However, your scenario should be as
> > realistic as possible, i.e. it can happen in an IP-based network. This is the difficult part. 
The
> > rest should be easy.

---

From: [email-masked]
Date: Fri, 26 May 2000 12:54:42 +0100

You might also like to reflect not just on performance issues when all the
network is 'up' (so this is in the QoS domain), but also the behaviour when
part of the network goes 'down' (so this is in the availability
domain........though there is a mutation of failures=>QoS impairments in the
IP layer).  And and early issue you hit is:
"What are the defects that can occur in the MPLS layer, where are these
specified in terms of entry/exit criteria and consequent actions, how are
these detected, and how do we relate these to protection/restoration actions
(esp when LSPs are nested)?"

Regards, Neil

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 31 May 2000 09:04:45 -0400

David,
complicated not necessarily means slow. It's doable and it's done.

	Regards,
		Greg

> From:	David Charlap [SMTP:[email-masked]]
> Sent:	Tuesday, May 30, 2000 6:52 PM
> To:	[email-masked]
> Subject:	Re: MPLS Performance analysis.....
> 
> Curtis Villamizar wrote:
> > 
> > I was one of those people.  Doing the IP destination lookup is no
> > longer a limiting factor for modern routers.
> 
> Depends on the speed.  If you up the number and type of interfaces so
> that your fabric has to forward billions or trillions of packets per
> second, you will once again find differences in how the two forwarding
> engines (IP destination vs. label) perform.
> 
> Regardless of how fast the chips run, an IP best-match lookup is an
> inherently more complicated operation than the integer-matching lookup
> required by something that forwards based on label (or VC or DLC).
> 
> -- David

---

From: [email-masked] (Sean Doran)
Date: Wed, 31 May 2000 21:44:02 +0200 (CEST)

Eric Rosen writes -

| I  think that  what the  nastygram would  actually say  is that  you haven't
| really invented or reinvented anything  yet, but that when you actually work
| out all the details, you will not only find that your encapsulation overhead
| is  five times  as  large, but  that you  end  up with  no less  operational
| overhead and probably with considerably more.

The nastygrams tend to come from the other High Priest. -:)
(I guess he and I are allowed to call each other names over 
the occasional thing, since we tend to agree about so much else).

Actually, despite my own religiousness, I would agree that 
if you actually wanted to do large amounts of SSR-style ER
and were sensitive to overhead, that you probably would be 
crazy to do it with other than MPLS.

Of course, that does not imply that doing large amounts of
SSR-style ER in itself is not crazy, in my opinion.

	Sean.

---

From: Martin Cooper <[email-masked]>
Date: Wed, 31 May 2000 20:42:31 +0100

Sean Doran <[email-masked]> writes:

> MPLS is a condensation of a GRE-like data-in-IP
> encapsulation header, plus some related control planes to
> lay out an SSR (strict source route) across a routed,
> packet-switched network.

I must say that I visualise TE-tunnels as a lot of GRE
tunnels with static routes on each router nailing the
next-hops down, and with a control plane to change the
statics for provisioning.

> When you point that the IP overhead lets one choose
> between doing SSR ER and two different modes of LSR ER 
> (both of which require router cooperation -- one mode
> requires the decap-reencap dance above, the other merely
> processing of the LSRR option), you may end up in a nasty
> fight, being reminded that one of the reasons people don't
> like ATM is that there is lots of overhead.

Assuming Cisco kit though, don't IP packets with options
get punted by CEF to the process-switching path, or am I
thinking of non-CEF IOS versions?

> You are emulating a circuit-switched network on a
> packet-switched one, no matter how you slice things;
> if your underlying logical layer in a hybrid MPLS/IP
> core changes, both MPLS and IP have to reconverge,
> and this is generally not so ships-in-the-night (i.e., 
> typically MPLS is reliant upon the topology discovery
> protocol IP uses).  Extra stability here can only come
> through a time-to-converge trade-off.

I'm not sure I buy this -- are you sure that's how it
works? I was under the impression the hop-by-hop path
of a tunnel was somehow nailed down at each hop (like
you might want to with an EBGP-multihop peering route)
to prevent routing instabilities ripping up your pre-
established paths?

> How is MPLS any different?

Well, given the above uncertainty? Certainly it sounds
a bit unstable if the TE-tunnels have to rely on local
routing-table convergence before they can be used for
traffic.

> Ah, you're new to the IETF, too?  Welcome!

Rough consensus and working code so I hear...
sounds good if that's really how it works... :-)

M.

---

From: [email-masked] (Sean Doran)
Date: Wed, 31 May 2000 22:17:45 +0200 (CEST)

Brijesh - 

| ... using CR-LDP for certain traffic (or whatever else you have),
| or by going to each router in the network and creating suitable entries
| (manually or auto-magically under the control of a TE process) in the
| routers so that a particular class of traffic goes over a statically
| configured path.

One thing over which I am sometimes accused of being provocative
is the question of whether one can take the control plane (i.e.,
the manual or automagic process that behaves in a CR-LDP or RSVP
fashion) and use it with a "label" that is in effect an IP datagram.

I think it can, and that it addresses the possibility that this:

| the core assumption is, lots of TE is required.

is only partly true (i.e., "lots" but not nearly as much as normal
best-efforts Internet traffic _in some situations_.  (Such as a
well-provisioned backbone's core)).

	Sean.