Brain dump of my current list of things to do to assign. Should be

stored in somewhere more permanent than my gray matter and purple
sticky notes!

assign/assign_todo.txt

@@ -4,56 +4,9 @@
 # All rights reserved.
 #
 
-If anyone wants to work on any of these, please contact and discuss
-the issues with me (calfeld@cs.utah.edu).
-
-Things to do to assign.
-
-1. multiple switches per node / annealing links
-
-   This may actually not be so hard.  Currently assign decides how to
-   satisfy a vlink deterministically.  What we want to do is change it
-   so that the vlink mappings are chosen semi randomly so that they
-   become a part of the solution and subject to annealing.  When
-   adding in a node, for each vlink we need to figure out the possible
-   ways to satisfy it.  Possibilities include: a direct link to the
-   destination, intraswitch links through any connected switches,
-   interswitch links through any connected switches.  Any valid
-   possibility (one that does not cause violations) should have a
-   chance of being tried.  We may want to weight those with lower
-   scores (direct over intraswitch over interswitch) so they show up
-   more often.  In a basic sense there is a potential path from src to
-   dst for every link in the src node.  In practice we probably want
-   to consider identical link as a whole.  I.e. a node with two
-   identical links to one switch and two to the other should really
-   only have two potential paths, not four.  With interswitch links I
-   would suggest only looking at a single path for each switch the src
-   node is directly connected to and still use the switch MST to find
-   routes.  For an even more versatile model that could take advantage
-   of non-tree switch topologies, we would want to choose a route
-   through the switch fabric semi randomly.
-
-   Example: Let's have A and B be pnodes, and S1, S2, and S3 be
-   switches connected in a complete graph.  A is connected to B, S1,
-   S2, and S3.  B is connected to A, S2, and S3.  Our virtual topology
-   is N1 and N2 connected to each other.  N2 is mapped to B when we
-   map N1 to A.  We look at the link between them.  Possible paths
-   are:
-	   direct link A to B
-	   intraswitch link A to S2 to B
-	   intraswitch link A to S3 to B
-	   interswitch link A to S1 to S2 to B
-	   interswitch link A to S1 to S3 to B
-  for best results we want each of these five possibilities to be have
-  a chance of being used.  For an initial cut, we would try only one
-  of the two interswitch paths, whichever shows up in the MST.
-
-  Actually implementing this change would involve some serious work on
-  the add_node and remove_node code and to the various find*path
-  routines.
-
-
-2. vclass improvements
+This is the current TODO list for assign (not in order by priority):
+
+1.   vclass improvements - from calfeld
   
   Two immediate improvements to vclass come to mind.  The first is,
   when choosing the type for the first assignment in a vclass use some
@@ -72,18 +25,96 @@ Things to do to assign.
   allow for other choices.
 
 
-3. port to a third part SA kit.
+2.   clean up assign.cc and score.cc
+
+   Many monolithic functions, like anneal(), need to be split up, because
+   they're just too big to comprehend.
+
+   The code is in bad need of commenting.
+
+   All the compile-time options have made a mess of things, so many that are
+   obviously good things should just be on. Many that are compile-time should
+   also become command-line options.
+
+   A lot of the 'classes' are just used like structs. They really should have
+   proper constructors, etc.
+
+3.   add the 'one interface per LAN' restriction
+
+   For jails/vlinks, we need to be able ensure that only one interface on a
+   node is in a given LAN - this is because you cannot put more than one 
+   interface in the same subnet. Shouldn't be too hard.
+
+4.   clean up top/ptop parsers, change output format
+
+   The parsers are currently very sensitive to syntax and ordering errors. The
+   output is also difficult to parse, and is error-prone due to its lack of
+   type information. At the very least, the top/ptop parsers should be
+   re-written to be more robust. It may also make sense to go to a different
+   format, one that uses key=value pairs. Or, even, something like XML, for
+   which there are already standard graph representations and parsers.
+
+5.   add delay node support
+
+   Merge back in Chris's delay node support.
+
+6.   fix PER_VNODE_TT and vclasses
+
+   PER_VNODE_TT is definitely a good thing, but it currently breaks vclasses, so
+   we can't use it in production. This might be tricky to fix, but is definitely
+   worth it. This will help to give better error messages when a vnode has too
+   many vlinks to fit into any of the pnodes.
+
+7.   fix PER_VNODE_TT and emulated vlinks
+   
+   PER_VNODE_TT assume that each vlink is going to consume one plink - need to 
+   relax this for emulated links.
+
+8.   prune pclasses when using PER_VNODE_TT
+   
+   Right now, we use all pclasses, even those which we cannot possibly use, in
+   our estimation of how hard the problem is (vnodes*pclasses). With
+   PER_VNODE_TT, we can do mark-and-sweep 'garbage collection' of pnodes that
+   it's not possible to map to. Should improve performace.
+
+9.   add features/desires to PER_VNODE_TT restrictions
+
+   PER_VNODE_TT currently only looks at the node type and number of links - it
+   could also easily look at features/desires with a weight of 1.0, too
+
+10.  add some sort of global allocation strategy
+
+   The idea here is to include other, already mapped, experiments in the top and
+   ptop files, and give assign the option to unmap existing experiments to fit
+   a new one in. The idea is that we'll somehow communicate the idle time and 
+   priority of experiments to assign, so that it can try to do the 'least
+   damage' in decided who to kick out - and, of course, not kick out anyone if
+   not necessary.
 
-   My initial impression is that this would be very tough.  Looking in
-   to it more deeply might be fruitful though.
+   There are two possible ways to do this. The first (and probably easiest) is
+   to use features. Give already-mapped nodes a feature with a weight
+   corresponding to how much we'd like to keep them swapped in. Then, modify
+   assign to only penalize for the feature once - because, as soon as you've
+   deprived an experiment of one node, you might as well swap the whole thing
+   out.
 
-4. rewrite assign.cc
+   The second (and possibly more correct) way is to use pclasses - this requires
+   the specification of pclasses in the ptop file, but the 'only penalize once'
+   tactic falls out naturally, since that's how we already do pclasses.
 
-   There's a lot of garbage floating around in that file.  Almost all
-   the original code is either unused or has been rewritten. 
+11.  put link mappings into stored solutions
 
-5. robust parser or top and ptop
+   The current behavior of re-doing link assignment on a revert is becoming more
+   and more questionable, since the greedy algorithm it currently uses can
+   result in worse scores than the original, and possibly even violations in the
+   reported solution. The solution is to keep the link mappings. But, this 
+   tosses out our 'deterministic' link mapping. Need to decide which of these
+   things is more important.
 
-   The parsing code is extremely intolerant of input errors (it often
-   crashes).
+12.  make rejected transitions work more correctly
 
+   Currently, rejected transitions can result in something not identical to the
+   original configuration. This is because we re-do link mappings (see #11), and
+   don't keep track of any nodes we might have foribly unmapped to try to open
+   up a mapping for an unassignable vnode. Doesn't seem to hurt anything, so is
+   low priority