nam TODO list

# nam: TODO list

The person who recommends the todo work does not necessarily do them by him/herself.

- introduction
  ( Here's the format ) a boldface set of keywords about what part of ns is relevant, text describing what's going on, then a signature and date. ([johnh] Thu Jun 17 18:04:37 PDT 1999)

- Multi-threading in auto layout
- Autolayout on regions of a graph
  Now we have unified editview and normal views, users should be able to specify a particular region, and do auto layout only in that region. This would be useful in large graphs. The first step would be to add flags to nodes and to instruct auto layout to only work on marked nodes.

- Tree layout
  If one knows that a topology is a tree, she/he should be able to specify the root of the tree, and nam will starting layout from that point, and put all nodes at equal distance to the root on concentric circles. The first step would be to spread all nodes at equal distance to the root evenly on their circle. We can later optimize the algorithm to find a nice fanout angle for every node based on the size of its subtree. ([haoboy] Wed Jan 26 16:33:44 PST 2000)

- Wireless Visualization of data flowing between wireless nodes . Showing the signal has been transmitted from some sender and received by the receiver ([johnh] before Mon Oct 4 23:57:07 PDT 1999)

- Topology The topology isn't scaled very well when nam starts up (nodes, links, or annotations may go off the visible screen, requiring you to horizontally scroll to see it all) ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- Queue Queue occupancy indicator, when exceeding bounding box, scribbles on screen , sometimes hangs X sever . ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- Labeling links A more flexible way to label links (like: label above, below, or next to object, different colors and fonts for the labels) ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- TCP When turning off tcp_cong, the segments probably should not disappear, but instead revert back to the color of regular segments. tcp_cong segments still are regular tcp segments, just that happen to be marked. it probably should work this way for ecn-echo acks also ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- TCP Display grid lines in the seq# vs. time plot will be nice ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- TCP Showing axis labels in the session view window would be nice ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- Link Being able to control the displayed link and width of a link would be nice sometimes ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- TCP It would be nice if one could highlight two points on the seq# vs time graph and have a little box tell you x and y axis deltas between them. That is, you could highlight, say, a packet and its ack and it would tell you how many seconds they are apart. Or, you could highlight two forward segments and it would tell you how many sequence numbers and secs there are between them. would be nice sometimes ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- chrome Is there a way to hit a key which will forward the animation time slider to the point a new src/dest pair is seen in the trace? ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- TCP packet It would be really cool if one could arrange to have the next packet after a dropped packet turn a different color. In this way, one can illustrate the amount of time needed for a tcp to "learn" that a packet has been dropped. It helps to illustrate that the tcp need wait not only the min RTT, but also the amount of time to drain the queue where this (packet after the dropped one) is queued. ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- goodput A measure of goodput over the time range would be nice. it would be especially cool if when you zoom in to a region you get goodput measures averaged over that particular region you zoomed in on. ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- RED queue It would be very cool if, for RED queues, one could have a sort of little thermometer indicating the average queue size, the ewma gain constant, whether it was marking or dropping, and maxprob in addition to little marks on it indicating maxth and minth ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- Queue Some sort of box that would compute a fairness index (say, from Jain p.36) at a queue might be useful in illustrating the behavior of say FQ or DRR ([kfall] before Mon Oct 4 23:57:07 PDT 1999)

- Asymmetric links: Nam supports symmetric links and simplex links only, it does not support asymmetric link, i.e., two simplex links attached to the same two nodes but with different bandwidth and/or delay. This is a design fault inherent in manual layout and auto-layout and correcting it probably requires changing these two parts. [haoboy]. Wed Aug 25 09:32:58 PDT 1999.

- Labeling links: Currently the only way to label a link is to use link color. It would be good to allow add dynamic textual labels to links, in the same way as they are added to nodes. This would only require two (quite straightforward) modifications: (1) add an extra field in the link trace line to indicate the label, and (2) display the label in Edge::draw(). [haoboy]. Mon Aug 9 14:58:04 PDT 1999.

- annotations Should be able to label packets with arbitrary strings. ([johnh] and [hyunahpa] Thu Jun 24 13:08:12 PDT 1999)

- dynamics I'd like to be able to create/remove nodes (not necessarily wireless) on the fly (so that I could pipe surveyor output directly to nam and create new nodes as surveyor discovers them). ([yuri] before Thu Jun 17 18:04:37 PDT 1999)

- chrome Would be nice to be able to add arrows to the links (as an option) to see if this link is unidirection/bi-directional. I suppose this should be very easy to do. ([yuri] before Thu Jun 17 18:04:37 PDT 1999)
  All links in nam is bi-directional. So this is not an option, I think. -haoboy.

- customization, interactivity Now when I click on a link or node a window appears which holds BW/delay information for the link and a node number for the node. It would be great if a user had more control over the contents of this window. For example, when I click on a link I'd like to see IP addresses of the endpoints (for a router typically has several ifaces); and when I click at a node, I'd like to see some information about the node, e.g. it's distance from current surveyors). ([yuri] before Thu Jun 17 18:04:37 PDT 1999)

- chrome Finally, changing/removing node labels (inside node circles) could be useful. ([yuri] before Thu Jun 17 18:04:37 PDT 1999)

  Can't this be done already with text node labels (the ones beneath the nodes?). --johnh

  The visual effect of this can be quite ugly though. Imagine a 200 node graph with a 12-digit IP address in each of the node. The right way to do this is perhaps to allow users to toggle showing the current textual labels either UNDER a node, or INSIDE a node's pane when clicked. -haoboy

- parsing, cruft Another thing with is sort of related is the parsing code. Currently there's a lot of hand-written code in trace.cc switch big switch statements and lots of atoi stuff and rudimentory error checking (did I get > 2 fields?)

  It might be lot easier to maintin/add to this code if there was some kind of table-driven parser something like getopt for argc/argv, or like widget parsing in X11. ([johnh] Thu Jun 17 18:04:37 PDT 1999)

- annotations An artifact, not a bug: I just realised that nam does not show multiple simultaneously occurring annotations in its annotations window. This appears counter-intuitive. As an example, see http://www.isi.edu/~kannan/out-cmcast.nam.

  The annotations show only node 0 joining group 65520. In reality, all nodes in the topology join this group at the same time, at startup. Seeing only one line made me believe there was a strange bug in my code, when it turns out to be an artifact of nam. It would be nice if this were fixed in some way, and otherwise documented someplace.

  (One suggestion is that for subsequent simultaneous annotations, an single annotation line be added as "0 others". A popup menu on that line could show other annotations when requested, but that is getting more featureful than I need for my requirements. :-) ([kannan], before Thu Jun 17 18:04:37 PDT 1999)