Subject: Re: [TE-wg] TE use in today's networks

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 7 Jun 2001 20:58:40 -0400

>> I think, manual "Optimization" of weights (even small number if
    >> weights) based on the huge topology is a real disadvantage.
 
    > this doesn't have to be done manually -- it could be automated. The
    > basic idea is to know the current topology and offered load in your
    > network by measurement and to have a tool that can select weights that
    > satisfy some objective function (and, perhaps, try to minimize the
    > number of weights that need to change from the existing configuration).
    > Then, you need a way to effect weight changes in the network
 
Ahem. I feel a major, major rant coming on.

The image that comes to mind, hearing of these schemes to try and do traffic
engineering with this approach of carefully selected single metrics, is that
of a person trying to proceed down the street by standing on an upright car
tire and making it rotate with their feet, like some sort of demented
relative of a log-rolling contest.

You can see someone with great balance getting away with it - but it's
fundamentally not a workable idea. To paraphrase Dorothy Parker, "This is not
an idea to be tossed aside lightly. It should be thrown aside with great
force."

Trying to accomplish any optimization of traffic arrangement, or any equally
sophisticated goal for a path-selection system, by means of carefully tweaked
metrics on network elements, used with an existing dynamic single-metric
path-selection system, is just deeply confused. Let's step back for a second,
and think about what's really happening here,

The *whole idea* behind using a *dynamic* autonomous path-selection system is
*to respond in real-time to unplanned changes in network topology*. (After
all, if one doesn't need dynamic response, one could just install static
routes - which can equally well be computed offline, and installed
automatically, as posited above - and be done with it.)

If one *does* need dynamic response, it should be intuitively obvious that
even if one can find a set of weights that produces the result one wants in
the base case, then the resulting traffic pattern, once chance has taken some
random set of elements out of service, is probably not going to be one that
comes anywhere near meeting whatever goals one has.

I suppose one might respond that "well, we don't mind living with non-optimal
(by our lights) path selection during temporary outages, it's the base state
we care about". However, I would have thought that it was precisely during
temporary outages - when the network has *fewer* resources available to it to
carry traffic - that one needs *better* path-selection than on average.

If the network was that over-provisioned that it was OK anyway during an
outage, then why on earth did it need some sort of non-trivial path-selection
in the base situation? Similarly, if the system is getting acceptable
path-selction during periods of outages, when it's using metrics which aren't
tuned for that case, are the paths that are selected during normal operation
by untuned metrics really going to be that bad?

The whole notion that one can select single metrics for network elements,
ones that can truly meet complex path-selection goals over a wide range of
subset topologies, is misguided. There's just not enough information
available, nor a complex enough algorithm to process it. The answer is
simple: stop trying to drive a screw with a hammer.

If i) one has some complex goal for how one would like paths for traffic to
be selected, and ii) one wants the system to be able to respond to outages in
a dynamic and autonomous fashion, then one has to bite the bullet and create
a path-selection system which can meet those goals. It has to a) make the
needed information available, and b) incorporate those goals in the algorithm
used to select paths.

    >> (In my opinion these implementations [MPLS with precomputed backup
    >> paths] are going to be mature in foreseeable future).
 
    > The key issues are when will this capability be available, how
    > complicated is it to manage, and how much better/faster is it than the
    > alternatives?

I remain highly dubious that anything of real value will be gained by this
technique optimized metrics - or, in more blunt terms, whether the slight
potential improvements are large enough to be worth the energy being expended
on this technique.

	Noel

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 08 Jun 2001 09:05:30 -0700

Noel,

> Ahem. I feel a major, major rant coming on.

Attached e-mail that was posted to the irtf-rr mailing list seems to be
relevant to the discussion.

Yakov.
----------------------------------------------------------
From: Yuval Shavitt ([email-masked])
Date: Thu May 17 2001 - 08:41:54 EDT 

In the paper below we give an example that shows that regardless
of the weights you assign to links in OSPF the possible gap between
MPLS TE capabilities and OSPF which equally splits the traffic
among multiple paths in as high as can be.

In other words, weight setting for OSPF cannot replace MPLS as 
a traffic engineering tool. 

Yuval 

http://www.eng.tau.ac.il/~shavitt/pub/DIMACS01-17.ps 

> 
> Our work is basically a theoretical result with an attemp to find some 
> practical applications. 
> I agree that it is too early to say how ready or how ususful it can be for 
> real world networks. 
> I am aware of some of its limitations. One of them is that it sometimes 
> needs to split traffic 
> unequally between two or more equal weight shortest paths in order to 
> achieve the optimal 
> traffic engineering which is doable by MPLS (uneqal split between two LSPs 
> between the same 
> source-destination) but for some reason difficult to do by OSPF at present 
> time. Another is that 
> we may be able to set appropriate link weights to optimize the long term 
> network performance in the 
> statistical sense, but we don't want to change link weights dynamically 
> reacting to traffic 
> fluctuations in real time. I welcome critics or sugegstions to make it more 
> practical. 
> 

-- 
Yuval Shavitt
Dept. of Electrical Engineering - Systems
Tel Aviv University, Tel Aviv 69978, Israel
Tel: +972 3 640 8659  Fax: +972 3 640 7095
URL: http://www.eng.tau.ac.il/~shavitt
Networking Research Center, 
Bell Labs, Lucent Technologies
Holmdel, NJ 07733
URL: http://www.cs.bell-labs.com/~shavitt

---

From: Jennifer Rexford <[email-masked]>
Date: Sat, 9 Jun 2001 15:53:05 -0400 (EDT)

Noel,

> If i) one has some complex goal for how one would like paths for
> traffic to be selected, and ii) one wants the system to be able to
> respond to outages in a dynamic and autonomous fashion, then one has
> to bite the bullet and create a path-selection system which can meet
> those goals. It has to a) make the needed information available, and
> b) incorporate those goals in the algorithm used to select paths.

Sure, nicely put.  You could undoubtedly define a better routing
framework than OSPF/IS-IS for traffic engineering.  Existing IGPs are
not all that flexible (e.g., they do destination-based forwarding,
they do not make flexible use of mutliple shortest paths, and they do
not make any use of non-shortest paths).  I think you could say the
same thing for QoS mechanisms -- that per-flow mechanisms are "better"
than aggregate QoS mechanisms, which is better than no QoS.  The
question isn't whether you can do better than the existing technology;
you surely can.  The question is how much you would gain (in network
efficiency) and how much you lose (in network and management complexity).
And, what should a network operator do in the meantime as the "better"
protocols and mechanisms are developed and tested?

> If one *does* need dynamic response, it should be intuitively
> obvious that even if one can find a set of weights that produces the
> result one wants in the base case, then the resulting traffic pattern,
> once chance has taken some random set of elements out of service, is
> probably not going to be one that comes anywhere near meeting whatever
> goals one has.

While this is theoretically true, experiments suggest that in practice
the weights that are good in the base case often work pretty well in
the failure case; when they don't, a change or two does the trick.
Also, this is a question of time scale.  Changing weights to adapt to
time-of-day traffic changes, longer time-scale traffic shifts, and the
addition of new routers/links, seems reasonable -- and preferable to
the alternative of keeping the weights fixed.  

(You could also imagine that you have enough resources allocated for
the "high priority" traffic to receive the required service even under
the failure scenario, and just do weight changes to improve the
performance seen by the "low priority" traffic.  Or, you could imagine
using explicit routes for the "high-priority" traffic and using the
label-switched paths selected based on the weights in the base IGP for
the remaining traffic.)

> The answer is simple: stop trying to drive a screw with a hammer.

What if you don't have a screwdriver and the hammer works pretty well?

-- Jen