Priority List
  1. Determination of validity of existing data
    1. Peer revue of code
      1. I've forgotten most of what I did, so I can plausibly be considered one peer; another would be nice.
      2. At the very least, flag questionable points in the code and nag Stefan about them.
    2. Segmentation of results?
      1. The sampling graph shows distinct sampling strata, especially for the much maligned loss data.
        1. This might be due to how I'm extracting loss data; see peer revue
      2. We might want to use only those that have high sampling rates; the upper stratum.
    3. Statistical tests on the data?  I read about those somewhere...
      1. Time to call 411
    4. See graphs; Stefan's point about questioning the validity of the data via examination of graphs seems valid.  Specifically,
      1. The sampling graphs {latency, drops}
        1. My thought is that the xmas-tree demonstrated in the loss graph, and to some extent the latency graph is the source of the tree in the correlation and general loss graphs.
        2. Why is it so stratified?  There was probably a point in the study where I entered a number of new points; thus, new paths came to be measured in addition to the old.
        3. It's unclear to me right now why that would cause the probability distribution stratification, however.
  2. Graphs, more of them.
    1. Evil Nap
      1. Graph the number of paths with better alternates that pass through known congestion points.  Corbató can give us a list of NAPs to test against.
      2. Search for common links/hops/AS's
        1. for each hop, number of bad paths containing that hop
        2. do again, but subtract hops that appear in good paths (idea is to only consider hops that only appear in bad paths)
        3. for each bad path, number of hops in common with other bad paths
          1. do again, but use number of hops only held in common with other bad paths (i.e.. don't appear in good paths)
        4. Do this at the AS granularity (we can use the code from AS-Traceroute  to transform our traceroute measurements into AS-path measurements)
      3. Multi-time scale analysis... is routing inefficiency the same across different time scales?  Very easy to test (10 minutes, 1 hour, 8 hours, 24 hours, two days, one week, one month)
      4. Correlation between drop rates and path length? (we'd expect so)
      5. Correlation between drop rates and RTT? (we'd expect so)
      6. More?
    2. General [1]
      1. Relative difference in latency between best path wrt hop count and best path wrt latency
      2. Absolute difference in latency between best path wrt hop count and best path wrt latency
      3. Relative difference in loss rate between best path wrt hop count and best path wrt loss rate
      4. Absolute difference in loss rate between best path wrt hop count and best path wrt loss rate
      5. Then do the same thing for best paths wrt AS-path length.
      6. Search for bad hops
        1. look for a big latency jump in traceroute
        2. look for a big increase in drop rate in traceroute
        3. top x worst hops that add up to difference between path and best better path (idea is that these hops are contributing the added "badness")
          1. for each bad hop, plot number of paths containing it
    3. General - 2
      1. Median equivalents of the current graphs?
        1. I have the data on hand.
        2. Empirically, the median curve is not that much different, but if it provides us with a stronger case, then perhaps a good idea.
  3. Translation of our two-way loss data into one-way loss data
    1. ( 1 - P( you get a response from the end host | your initial UDP got through ) ) into one-way loss data
    2. ( 1 - P( your initial UDP got through ) or 1 - P( your response packet, known to be sent, was received by you ) ).
  4. Dammit John, why aren't you running SPF yet?
    1. I'm lazy
    2. Triangles are easier to reason about right now.
  5. Ouruboros / The Second Coding of John
    1. Pulling out my original code set/ideas for pseudo-instantaneous measurements, and integrating it into the existing framework.
      1. If we do instantaneous, it would seem as though we'd have to do a simultaneous average cost study, to have comparable results.
      2. Integration/coordination is required, to avoid overloading the slave servers.
        1. And yet we have to segregate the result sets, to retain non correlation claims about the concurrent cost average data set.
      3. What is the time window we will declare as instantaneous?
        1. Explication of the Ngon size determines window size, along with the number of concurrently running traceroutes we'd allow on that server, server hit rate distribution, etc.
        2. Should we contact a few key points, and ask to be able to put heavier load on them?
          1. MIT, UTexas, etc..
          2. Or would this necessarily unbalance the study? (probably).
      4. What are the selection criteria for a given Ngon?
        1. Purely random selection?
        2. Dynamic analysis of the time average data, providing promising paths at runtime
        3. Analysis of the existing data set for "seed" Ngons.
    2. More nodes [2]
    3. PASTA, PESTO
      1. Pareto Encapsulation of Statistical Testing Operations?
    4. Fix the server bug, or rewrite the bloody thing; a bulky server is unnecessary.
    5. What are the stability characteristics of the better indirect paths?
      1. "Predictability of alternate routes"
  6. Technical Report
    1. Goals
      1. MSA?
    2. "One idea is to create a tool that uses the measurements to select/advertise routes.  We should have a straw proposal for how this would work (i.e. what we can influence using exist precedence and path prepend) and at least a back of the envelope idea of whether it would help (i.e., is this just an automatic load balancing tool or can we really improve stuff with so few degrees of freedom... here at UW we just get to select between verio and MCI)"[1]