[25611] in North American Network Operators' Group
RE: Traffic engineering tools
daemon@ATHENA.MIT.EDU (Vadim Antonov)
Fri Oct 22 19:25:13 1999
Date: Fri, 22 Oct 1999 16:23:41 -0700
From: Vadim Antonov <avg@kotovnik.com>
Message-Id: <199910222323.QAA20101@kitty.kotovnik.com>
To: abender@tns-inc.com, akyol@pluris.com, nanog@merit.edu
Errors-To: owner-nanog-outgoing@merit.edu
> First of all, a multicommodity flow problem is not NP-complete
> provided that the individual flows are an order of magnitude or so
> smaller than the link capacities so that you can use a fluid approximation.
> Moreover, you can come up with a heuristic that works pretty well. I believe
> you must have heard of greedy algorithms.
My friend prof. Plotkin says greedy algorithms were shown to produce
horrible results in pretty trivial topologies.
(He is the authority in MCF problems, btw).
In any case, doing MCF computations in real-time is out of question even
with simplistic approaches. Do it at a rate of 500 times a second -
that's what you need to deal with real-life bursts of routing updates.
> It is **so** easy to label a problem NP complete these days.
It is so easy to miss pretty trivial solutions to problems deemed
complicated. The goal of a scientist is to find an interesting problem,
and live off it for a while. The goal of an engineer is to evade
interesting problems :)
In fact, Pluris boxes by the virtue of doing the load-sharing trick allow
traffic to be treated exactly like liquid flow - thus making the traffic
engineering problem trivial. The one-router-per-POP ideology also allows
to satisfy acyclicity criteria for load-shared destination-address forwarding,
making label switching and associated complexity simply unnecessary.
--vadim
(who believes in KISS principle)
