The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Dec> msg00129



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[MPLS-OPS]: Jitter and MPLS

  • From: Eric Osborne <eosborne@cisco.com>
  • Date: Sun, 8 Dec 2002 23:22:06 -0500
  • Cc: "'jshen@cad.zju.edu.cn'" <jshen@cad.zju.edu.cn>, Eric Osborne <eosborne@cisco.com>, "J.C.Ramesh Babu" <rameshbabu_j@infosys.com>, mpls-ops@mplsrc.com, mpls@UU.NET
  • User-Agent: Mutt/1.2.5i
  • X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562

On Sat, Dec 07, 2002 at 08:43:01PM -0500, Naidu, Venkata wrote:
> Jing & Eric,
> 
> -> 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:
>   
>   I think your discussion is little deviated. What I understood 
>   from Jing's description is that, he didn't apply any form of TE 
>   (neither IP-TE nor MPLS-TE) in his network. Jing's measurements 
>   are based on straight line topology of 3 nodes, comparing IP and
>   MPLS (forwarding) performance only.

Just to make it clear, I'm not talking about TE either.  TE is just a
more granular way of routing that can reduce the likelyhood of
congestion; once you have congestion, QoS kicks in and it doesn't
matter whether it's TE or LDP or whatever (ignoring any
implementations that do per-LSP scheduling for TE; since the once I
know best doesn't do that, I can't speak to it).  

> 
>   IMHO, in such a small topologies, the amortized performance
>   improvements (overall gain of all operations in the worst case)
>   may not be significant.
> 
>   In such straight line topologies (with out applying any form
>   of queuing differentiation or some form of TE in the topology),
>   I don't think MPLS out performs IP just because of MPLS 
>   fast forwarding nature (may be small amount of improvement).

May be small amount of performance hit.  May be large amount of
{improvement|performance hit}.

>   Remember that, there is no much difference between IP QoS techniques
>   and MPLS QoS techniques (same classes, same queuing
> methodologies).

Agreed - this is what I said to begin with.

>   The major difference between IP and MPLS is in TE techniques.

Well, for this discussion, yes.   

>   This discussion reminds me of old draft:
>   ftp://ftp.netlab.ohio-state.edu/pub/jain/ietf/draft-bhani-mpls-te-anal-00.
> txt
>   Where, it is clearly shown that, there is a significant improvement 
>   in the throughput of the UDP & TCP flows when MPLS-TE is applied.
> 

I agree with this draft, although I don't think it's showing anything
revelationary.  If you put the same amount of traffic along a set of
links that has bandwidth X, and you do the test again with a set of
links of bandwidth Y, and Y >> X, then performance will be better.
This is irrespective of TE or not.  In the picture on p. 3 of the
draft, just make the diverse paths equal-cost and ECMP will probably
work fine.

>   However, can the same performance improvements are achieved using 
>   IP-TE methods (at least near to the performance of MPLS-TE) is 
>   still an open ended question? 
>   

Yes, it is an open-ended question.

>   Some very interesting research has been done to prove the above 
>   question. But, "at what cost?", "with how much ease of configuration
>   & maintenance?", "with what added benefits?" are still unanswered.
> 

I agree completely.



eric

>   Finally, I strongly feel that, the performance matrices change a lot
>   from small topologies to real-complex topologies. We can't directly
>   map the simulation results to real-world topologies. In any case,
>   the average/amortized performance measurements & analysis of 
>   real-world complex topologies is not an easy task. If there is 
>   any such work, I will be very glad to know. 
> 
>   Thank You.
> 
> --
> Venkata.