Quarterly Report on Research Activities
2Q 2004 (April - June)
~ Special Traces
Florida-I: we have five contiguous hours from the new Florida monitor, during a busy working day as a new special trace file. Anonymization, copying of the Florida-I data set from Gainesville to SDSC, and post-processing took place. Since then, the machine has been turned over for daily trace (8x90) captures. ftp://pma.nlanr.net/traces/long/uflg/1/
Abilene-III: We collected a first 4 hour data set at the OC192MON sitting on the Indianapolis - Chicago Abilene link, filling up all of the 2x141GB data array. Anonymization and post-processing were completed; the data is accessible on the new PMA system at SDSC for FTP/HTTP retrieval. The analysis of the OC192c Abilene backbone data is rich with discoveries. http://198.202.123.33/Special/ipls3/ (new PMA server).
A few samples (and observations):
http://198.202.123.33/Special/ipls3/20040601-214000-0.html
http://198.202.123.33/Special/ipls3/20040601-224000-1.html
- The first observation is, indeed, backbone utilization can easily reach one-third of the link data rate.
- The second is the relatively frequent "box shaped" (or Manhattan skyline, if you wish) pattern of some application or host grabbing about 1 Gigabit/sec and transferring data for 5-15 seconds. This is highly unusual for any (legacy) networks; so far the only other place I have seen this occurring is on HPWREN and the pattern observed via the SDA monitor, where the traffic exits SDSC. It is indicative of the fact that high performance networks appear to indeed make room for a new class of applications (rapid bulk data transfer). We need to discount that some of the activity observed is test traffic, but that is beside the point, the opportunity is right here and the measurements document success.
- The third is that those bandwidth spikes barely have an impact on packet rates, apparently the throughput is achieved with large packets.
- Fourth, there are a number of occasions where ICMP traffic can reach 30-50% of all packets being transmitted. For instance in the following (a portion of the graphs omits the remaining ICMP display due to a bug in grace).
- http://198.202.123.33/Special/ipls3/20040601-210000-0.html
- http://198.202.123.33/Special/ipls3/20040601-211000-0.html
- The fifth is, if you really want to study these phenomena, passive monitoring is pretty much your only way of approaching it. All the known alternatives (SNMP/MRTG and NetFlow) probably deliver way too crude results.
~ New (revived, and developing) strategically important passive measurements and deployments
Excellent progress was made this period with both new deployments and troubleshooting and reviving passive monitors already in place. This was due in large part to PMA Project Lead Jörg Micheel's traveling to the sites and working with the local technicians. A tremendous amount of preparations were made in advance by the PMA team with gear prepared and shipped in time for his arrival at the various locales. He made two such trips this quarter. The installations went well and have been successful.
As can be seen in the month-apart daily log summaries (table, last page), at the end of the quarter we had a total of 18 passive monitors in place, 16 of which were collecting data. These include the new IPLS instrumentation trio of monitors; all new deployments (upgrades and replacements) have CDMA time support.
We are taking several measures to increase site participation in the PMA project. For example, we have emailed Kostas Pentikousis at SUNY Stony Brook, who is enthusiastic, but needs more information before proceeding. Similarly, approached Marwan Sleiman from UCONN, but have not had a response as yet. Successfully approached Bill Cleveland (ex Bell Labs) at Purdue who looked into an opportunity at his university for another monitor and Greg Cole (NCSA) regarding putting a pair of OC3MONs at Northwestern, for GLORIAD. Have also received an excellent response from Bill Owens (NYSERNet). More information below.
We have also been looking for ways to place some further PMAMONs using existing equipment, primarily OC48MONs, which we have spare. Research has shown that OC48c links are quickly fading from the network map. Instead, there are more and more 10 Gigabit links, in particular many OC192c PoS. The links that we have found are GigaPOP access links, such as MAX, NOX, SOX, and APAN/TransPAC. We have approached Linda Winkler, John Hicks, Matt Zekauskas and some (so far anonymous) contacts at NOX and SOX to see if they might be happy hosting a system. From Chris Robb and John Hicks I have learned that the OC48c from LA is going to disappear, while the Chicago OC48c will be replaced by OC192c (if TransPACs application under INRC succeeds) or will cease to exist in about 2-3 month. In the current situation it is very difficult to plan any measurement activity, all we have is a commitment from John Hicks to get us involved once the future is clearer and predictable.
Indianapolis Abilene backbone OC192 (x2)/OC48MON instrumentation, on the links to Kansas City, Chicago (both OC192c PoS), and Atlanta (OC48c PoS), each with CDMA time receiver support. We have agreed on the following agenda with Internet2:
- Collect a substantial data set on the three backbone links.
- Convert monitors to 8x90 secs/day collection for a few weeks in a row.
- Work with Stanislav Shalunov at Ann Arbor on "TCP happiness" - per-session performance specific to I2, probably with a dedicated real time application (request by Matt Z).
- Attempt to configure a full instrumentation of the IPLS router node. This was specifically supported by Rick as an activity they would like to be carried out. There is an issue that some links belong to connectors and some checks need to be carried out that legally things are ok. Good news developed over the quarter with respect to a potential router clamp instrumentation as an upgrade to the present IPLS backbone taps. It appears that we will have the necessary moral, technical, and possibly also financial, support to move closer to a full instrumentation. More work needs to be done.
We are excited about the excellent support we have received from the team at Indy. As a side note, the link to Atlanta is going to be upgraded at some stage and we may require a third OC192MON. Another request came in regarding support of Abilene's IS-IS measurements.
After a four hour special trace (Abilene-III) was taken, all three monitors in the instrumentation were turned into 8x90 seconds data collectors - like the rest of the PMA infrastructure daily trace collectors. They are keyed I2A, I2C and I2K for the three links to Atlanta (OC48c), Chicago, and Kansas City.
Ann Arbor OC3MON at Internet2 facilities
PSC, Pittsburgh GigaPOP OC48MON. Turns out this link is operating at 1550nm wavelength, which is very unusual, and we had to convince ourselves that both splitters and DAG4.2 cards would support it. We are enormously thankful to Kathy Benninger at PSC for her tireless support over the last few months! An effort that truly has payed off, this system is collecting very interesting data.
ANL. Linda Winkler came back to us with a (justified) complaint by ANL NetOps about potential security hazards with this system. We did a scan and rework of all the services on the box and also configured /etc/hosts.allow appropriately. The machine is now collecting data.
Chicago at Northwestern Univ., pair of OC3MONs for GLORIAD instrumentation to monitor the links towards Russia and China.
OARnet OC48MON, put on their link to the IND GigaPOP.
NCG. Boulder NCAR GIGEMON, there is a replacement monitor at the nai-p-ncg site waiting to be installed. Scot Colburn is the site technician at NCAR. Scot is very helpful and will attend to it as soon as possible.
A new 2U system was installed at the AMPATH facility (http://www.ampath.net/), which is at the Nap of the Americas (NOTA) telehouse building downtown Miami. We are tapping into the link in between the GSR and the Lucent CBX500. More information at http://www.ampath.net/techmap/NOTA-Rack_frame.htm. Ernesto Rubi has promised to add the VPI/VCI values to the chart, for users of the trace data.
We are touched by the support we have received from the AMPATH team at FIU. Both Ernesto Rubi and Eric Johnson went the extra mile to help NLANR with time and equipment and also to make Jörg's stay worthwhile and productive. Eric noted how useful AMP has been for him to troubleshoot and respond to reported network changes and misconfigurations, leading to outages and degradation in quality-of-service reflected in trouble tickets.
The OC12MON at Gainesville, FL is now actually monitoring all the legacy and Internet2 traffic to/from UFL. Unlike the previous OC3MON there is no GigaPOP service to other institutions, therefore within the PMA infrastructure, the system was renamed as UFL. It turned out that UFL uses another proprietary encapsulation, Frame-over-SONET, for which there was extensive research to find the correct documentation. It appears as if it is compliant with RFC 1490 Routed IP via NLPID encapsulation, and the DLCI value (channel ID) is equivalent to the one used in Frame Relay. The two values in use 16 and 512 are for the legacy and I2 services provided at the Atlanta GigaPOP by Qwest and Abilene, respectively.
http://net-services.ufl.edu/network_information/
http://net-services.ufl.edu/network_information/graphs/graphs.html
Matt Grover explained that UFL is in the process of getting engaged with FLR (Florida Light Rail), which will tap into the National Light Rail consortium at Gainesville. UFL will at this point again become the GigaPOP for Florida universities, providing the on ramp for all network services to and from the state. This fibre is in all likelihood going to deploy multiple 10GigE lambdas for a variety of purposes. Plans are for mid year to enable such service, and the OC12c we are presently monitoring is likely to go out-of-service.
Purdue GIGEMON access link instrumentation, at the GigE link which sees all of the Internet2 traffic towards the Indy GigaPOP, as well as the legacy traffic towards Switch-and-Data, which connects in a complicated way via Indy to Chicago on an OC3c link. We are working with Scott Ballew to troubleshoot this installation. We have carried out testing and the monitor is still suffering from loss of sync at one of the two ports.
SDA. We used the previous SDA monitor to ship to Purdue; therefore we needed to deploy a new box at SDSC, which is again collecting data (after a patch was added for the 2.4.13 software release from Endace).
NYSERNet. Received a long reply from long time AMP collaborator Bill Owens, detailing possible instrumentation ideas. At present, the most likely opportunity is to monitor the link from NYSERnet to Abilene at NYC on GigE-LX/LH. We have also discussed moving the dormant BUF monitor at the University of Buffalo towards their OC3c link at the same location. Bill also offered some opportunity for 10GigE monitoring, which we should consider later down the track. He also shared details about the MAN LAN (Manhattan Landing) which is a Layer 2 Exchange for NY and overseas partners, which we could monitor at the VLAN level at a SPAN port. There is also a new HOPI activity that we should learn more about. We are very close in the dialog with Bill Owens at NYSERnet on getting an OC12MON (back) into Buffalo as well as a GIGMON monitoring the NYSERnet link to Abilene. We are working through technical details with Bill and have prepared an OC12 passive monitor and have a Gigabit monitor in the works to add to the NYSERNet monitoring collection.
ODU. This is now an upgrade from a previous FORE-based OC3MON to a DAG3.2 system (still at OC3c ATM, but with precision time stamping). Troubleshooting revealed a netmask issue, which has been settled. Currently awaiting site staff availability.
APN. APAN OC3 monitor at Argonne National Lab, off line. We worked with Linda Winkler to understand the destiny of our OC3MON at StarTAP (which by now is almost a legend as one of the longest running in the infrastructure) and have been told that StarTAP was finally shut down at the end of May 2004.
~ Continuing development of new metrics and real-time analysis for PMA
Plans were made to resume real-time work in the immediate future. A longish thread of communication with Klaus Mochalski, Klaus Degner in Leipzig regarding identifying application traffic (partly as a follow up on some dialogs which occurred in the aftermath of publishing early pictures on the OC192MON data at Indy). We are on the same page that we want to get running code implemented very quickly, and there is a chance we can deploy new code on relatively short notice.
We were approached by Pere Barlet from UPC Barcelona to continue the collaboration on real-time work which we started during his visit to Hamilton in January and February. He has sent an email detailing his plans.
~ Upgrades, troubleshooting, and maintenance on the PMA infrastructure
We are working on enabling IPMI remote server management (remote reboot capabilities) with the SuperMicro server machines, using the SDA system, as a prototype for upcoming PMAMON systems.
The strange patterns in the anonymization procedure occurred again while processing the new OC192MON special trace, 90 minutes into the trace we were faced with a memory allocation crash coming from within the gdbm library. Issues for the anonymization procedure are the huge trace files (and the number of IP addresses to be handled) We oscillated between debugging and finding a workaround, or going for a complete reimplementation of this part of the anonymization code, for speedup and reliability. After researching alternative database systems to replace gdbm, and developing a new DBM-based version, a test run against the previous gdbm revealed some inconsistencies, which were found to be further bugs in the gdbm solution (assigning a fake IP address more than once). We are happy with our new DBM-based version (Berkeley DBM, now a mature, industrial strength, solution ).
We continued building the new PMA server and this quarter, we launched the next generation pma.nlanr.net, which is a 2TB dual AMD Opteron machine. Not unexpectedly, we have run into some hardware problems (persistent crashes), which we are about to corner and hopefully will be in a position to make it a stable platform soon. 64bit servers are still a bit of a challenge, but if you are willing to make the extra effort, you will be rewarded with performance; the new pma.nlanr.net is ultrafast. For example, the new machine skimmed through the 66 Gigabytes of compressed trace data for Abilene-III (OC192mon Special Trace) merely in one evening, something which for the Auckland-8 data set had taken close to a week.
Worked on the new pma.nlanr.net server to enable various services. We also ported the dagtools to the new server, in order to use the high performance system to process the newly collected special trace files, and to fully migrate all services to the new PMA server.
When the three monitors from the Abilene instrumentation (2 OC192MONs, 1 OC48MON), I2A, I2C and I2K, were turned into 8x90 daily trace collectors the resulting files exploded the daily trace collection (double-triple, see last page, Web log table). As a result, with the shortage of disk space on the old PMA system, the automatic scripts reduced the number of days kept online to just two (yesterday's and today's data). The need to move to the new machine is urgent.
We continued to work with CAIDA to improve the time distribution to NLANR and CAIDA equipment in the SDSC machine room. Working on details in connecting the NetOps GPS receiver to the NLANR and CAIDA TDS-24 time distribution units. These units have been using an EndRun Technologies Praecis CDMA time receiver. However the time tagging accuracy using a GPS receiver PPS signal is said to be at least an order of magnitude better. After some trouble shooting and corrections we have the GPS receiver adapter circuit working. However additional trouble shooting revealed the GPS PPS input to the NLANR TDS unit is inoperable. But, the CAIDA TDS unit GPS PPS input is functional. (The CAIDA unit is an Endace production unit while the NLANR unit currently installed there is an engineering prototype from Endace.) As of now we have the CAIDA TDS unit driven by the GPS receiver and the NLANR TDS driver by the EndRun Tech. CDMA receiver to continue providing time signals to the OC192 monitors and the IPv6 AMP monitoring in amp-sdsc. A number of options exist.
Because of a network issue with the unit at Purdue. We began researching serial over LAN options with the identical GigE monitor here at SDSC.
We are learning more about DWDM and about the underlying architecture of the National LambdaRail and the I2 HOPI project, thanks to some pointers provided by Bill Owens from NYSERNet. Have also had some further conversations with Matt Zekauskas on the same subject. We have continued investigation on viable options for DWDM filters to be in a position to monitor such networks in the future.
Investigating how we will switch to HSI for archiving to HPSS with the new FreeBSD AMD64 system, possibly we will have to get the sources and compile our own binaries.
~ Reimplementation of AMP and development of a new testing architecture
Copyright/license issues were resolved and appropriate paperwork was signed during a meeting with Bill Decker, the UCSD legal analyst for technology copyright. Beta version 0.02 of the new AMPlet package was released. http://watt.nlanr.net/Software/AMP/
An AMP machine (at the NZ National Library) went live this period, using the new AMPlet code. It is the first actual deployment of the new code and seems to be working well so far. The machine has been added into the international mesh. (Changes to the version of the central code that runs on erg (the NZ amp data server) were made so that it will display the graphs from the new code).
Additional work on the AMPlet code was performed; after some additional fixes are completed, there will be a new release.
- Extended the AMPlet remote command processing facility so that it now returns the command status (command exists and is executable, command does not exist, too few resources) and the standard output of the command to the caller. This required creating a new thread to read from the SSL connection and write the status and standard output to a pipe from which the caller can read. This is much needed by the iperf and bandwidth estimations tools in order to run reliably.
- Further changes were made to the code that returns standard output from remote commands. This allowed completion of the pathrate, pathload and Iperf test code.
- Changes were made so that it can more easily be packaged as a Debian package. Perry Lorier performed the actual packaging, after which the CRCnet folks deployed it on CRCnet (which is also running the latest IPMP kernel on all their routers).
- Additional work was done to make the package compile on Debian Sarge and FreeBSD 5.2.1. Ivan Koga, from Brazil gave us access to his machines to do the debugging, and he will be using a pre-release of the new version there. There were just a few small issues (e.g., the prototype for exit has moved).
- More code documentation was written, extended the error messages when a self test fails, and tidied up after the integration of the throughput test code.
Work is underway on the central code (for the two data collectors). Most of the code has been modularized and separate jitter and random packet size graphs were added, with the related extension of the AMP PHP extension.
~ IP Measurement Protocol (IPMP)
To build support from operators for the protocol, a paper was written on how IPMP would be used to debug path faults (reordering, loss, jitter, capacity) and how the techniques differ from those that are currently in use. The paper titled, "User Level Path Diagnosis with IPMP," discusses how using IPMP would allow operators to understand where performance faults occur. It compares the IPMP methods to tulip methods that use existing protocol features. This paper was submitted to and accepted by the SIGCOMM Workshop - "Network Troubleshooting: Research, Theory and Operations Practice Meet Malfunctioning Reality."
IPMP flow counters for FreeBSD and Linux kernels were developed, debugged, and implemented (in time for distribution on crc.net). This involved learning two different ways of locking data structures, setting timers, and allocating VM pages for allocating flow structures. The idea of the flow counters is to pin-point loss events after they occur. An example:
mjl12@ttk:~$ sudo ./ipmp_ping-flow/ipmp_ping -4s 1400 -c 3 -w 0 pir ipmp_ping pir
mph.crc.net.nz (10.1.255.253)...
* 0 10.1.250.253 Jun 12 10:20:40 2004 353245000 0
1 10.1.250.1 Jun 12 10:20:40 2004 359707000 0
2 10.1.240.1 Jun 12 10:20:40 2004 594518000 0
* 3 10.1.255.253 Jun 12 10:20:40 2004 366737000 0
4 10.1.255.254 Jun 12 10:20:40 2004 600602000 0
5 10.1.240.254 Jun 12 10:20:40 2004 370441000 0
* 6 10.1.250.253 Jun 12 10:20:40 2004 379304000 0
* 0 10.1.250.253 Jun 12 10:20:40 2004 354432000 2
1 10.1.250.1 Jun 12 10:20:40 2004 363426000 2
2 10.1.240.1 Jun 12 10:20:40 2004 598506000 2
* 3 10.1.255.253 Jun 12 10:20:40 2004 370459000 1
4 10.1.255.254 Jun 12 10:20:40 2004 604988000 1
5 10.1.240.254 Jun 12 10:20:40 2004 374441000 1
* 6 10.1.250.253 Jun 12 10:20:40 2004 391958000 1
Explanation of example: We have sent 3 packets here, but only two came back. We know that the middle packet made it to 10.1.240.1, but not to 10.1.255.253 due to the flow counter indicating that 3 packets from the same flow were seen at one point but only 2 packets at the next. The flow counter is the last column in the above printout, and we count from 0.
In the process of implementing the flow counters, a bug in FreeBSD was found and reported, and has been confirmed. http://docs.freebsd.org/cgi/mid.cgi?20040609115052.D24917
Development of an IPMP transmit function for the GigE DAG card was discussed. Work will be done by a student, funded by Endace.
~ AMP PathVis: a 'divide and conquer' tool
This quarter, a demonstration version of AMP PathVis was completed. Real data was tried with the tool, producing good results. This is a prototype tool to aid in troubleshooting performance issues between a pair of end hosts. The core of the approach is a traceroute-based resource locator. The concept is based on the familiar visual analogy of a suburban rail network: the central line represents the path under test, and branch lines are selected by the tool because they show potential diagnostic routes (i.e., the AMP monitor closest to each hop along the path). This approach automates one of the most difficult tasks (selecting appropriate monitors from a large pool of candidates), thus supporting human interpretation of performance measures in a simple, but powerful, way. http://mna.nlanr.net/PubsResources/Pathvis.pdf and http://amp.nlanr.net/~xing/projects/ampgraph/
~ OptiPuter project
The plan is to deploy software only AMP code on several nodes and do application-to-application measurements. Using grid type machines will be a whole new arena for us, so there will be a bit of a learning curve. We hope that this can actually be done, will not know until we try. The AMPlet code was compiled on one of the OptiPuter nodes. There were a couple of problems related to the termcap library and a change in the way error messages are reported which will need to be rolled back into the main code distribution. The code will not compile on the other node; apparently the openssl install on that node is broken.
~ IPv6 and IPv6 Scamper
A new file format which is flexible and allows Scamper to record MTU data, source routing data, IPv6 and IPv4 data, as well as list data, was designed and implemented for recording Scamper traces. Rough specifications for the MTU data to be recorded have been developed; they are not sufficiently detailed, nor do they match Scamper's behavior, yet. We are working on devising something more generic and extensible.
Kenjiro Cho (WIDE) supplied a patch to Scamper that fixed the compile issues on NetBSD and changed the logic slightly for detecting loops. He also reported a few issues with the operation of the PMTU code; some of which have now been have been corrected.
The Linux equivalent of the BSD routing socket was examined (with input from Perry Loirer [WAND]).
A Scamper-pmtu run on a 900 entry address run to dual-stack nodes was received from Kenjiro Cho. The Scamper run found one v4 path with a PMTU less than 1500. The MTU was limited by the end-link which appeared to be a PPPOE+ADSL connection with the optimal MTU of 1454 set. We implemented Scamper PMTU support on Linux by obtaining the outgoing MTU from netlink. Perry Loirier (WAND) pointed us at netlink, for which we are very grateful. Of note, it was pleasant to see that PMTU works for v4 addresses, having not yet conducted our own testing on v4 addresses.
We ran Scamper in PMTU mode on a large address list from sorcerer which worked fine. A router that returns ICMP6 Fragmentation Needed messages for 68 byte packets, with a reported next-hop MTU field of 0 was found. Closer inspection revealed that it was generating two ICMP6 Fragmentation Needed messages for one probe packet, both saying the MTU of the next hop wasm0. The first had Scamper's UDP header as sent in it, while the second had the source and destination ports zeroed out.
Previously Bill Owens (NYSERNet) had offered the use of a Linux machine with a Broadcom GigE card directly plugged into a NYSERnet router that can route packets >1500 bytes. We pursued this this quarter. The router can route 4470 byte packets, less than the 9180 byte packets the card can do, but still good enough to locate Ethernet links whose MTU constrain the PMTU. For most links, these were seen only at the last few hops to each AMP monitor, which was to be expected.
We are also working with Bill Owens to find MTU bottleneck locations on I2, probing with Scamper from two hosts. The first host is capable of sending 4470 byte packets and the second is capable of sending 9000 byte packets. So far, the targets have been AMP monitors in the HPC mesh - hosts that we know exist. Bill has also probed PlanetLab hosts, but has not found a PMTU >1500 to those either. Bill wants to extend this to cover all of I2, and has supplied us with a BGP table to pull out ASes and address ranges to form an address list. The idea is to tag MTU bottleneck locations at core/regional/campus levels. He will do the tagging. He would like to see jumbo capable AMP monitors that could be used to highlight connectivity problems. For example, some routers are not sending ICMP fragmentation required messages, which slows down connection establishment markedly. We have been in touch with Grover Browning of I2, to help form an address list to cover Abilene. We currently have a small script to extract AS#s from the output of 'show ip bgp' on a Cisco router and produce an address list based on the advertised prefixes.
Bill and Kenjiro Cho have supplied us with useful bug reports when Scamper does something bizarre, and also forwarded their experiences with the code. Thanks to the information that Scamper outputs in debug mode, we are taking care of these bugs promptly. One is a fairly simple case of ignoring cloned routes in Linux that cause a machine to remember PMTUs for paths that we have already discovered, which cause Scamper to probe with the PMTU for the path, rather than the outgoing interface's MTU. The other is a bit more challenging to figure out. It involves ignoring responses that have an RTT that is not considered sane. We are triggering assertions in code, and will need to debug the root cause.
Interesting visualizations of link comparisons from early in the period (NYSERNet's IPv6):
http://amp.nlanr.net/active/cgi-bin/v6_linkcomparison.cgi?from=amp-nysernet&to=amp-missouri&date=104.4.22
http://amp.nlanr.net/active/cgi-bin/v6_linkcomparison.cgi?from=amp-nysernet&to=amp-missouri&date=104.4.23
Investigation began on how to do reverse path tracerouting with Scamper for IPv6 networks. The basic idea is to source route ttl limited probes via the end host back to the source of the traceroute, which will give us the reverse path.
In addition: The 'ring' tool was made to work under Linux. And work was done on the Scamper file API, almost there. Also, we are looking for a 9180 byte path that extends to I2, in order to do a survey.
We exchanged emails with some AMP IPv6 site administrators about a troublesome router that has been returning ICMP responses that do not make sense. The router is obviously a v6 in v4 tunnel. Instead of returning a fragmentation required message with the MTU of the path, it returns Destination Unreachable, No Route.
~ New (and developing) strategically important measurements and deployments
New AMP monitors in various stages of preparation and installation:
- Beijing, China, CNIC site - *p/s, being installed, router issues
- Purdue University in Lafayette, Indiana - *p/s, installed, collecting data
- University of Cambridge, England, amp-ucam - request received, *p/s, installed, collecting data (international mesh)
- Internet2 - 6 Internet2 Observatory Project monitors:
- amp-i2in (Indianapolis I2 POP) - *p/s, installed, collecting data
-
amp-i2ch (Chicago I2 POP) - *p/s, installed, and collecting data
-
amp-i2su (Internet2, Sunnyvale) - *p/s, installed, collecting data
-
Denver, CO - *p/s, awaiting installation and initialization
-
District of Columbia (D.C.) - *p/s, awaiting installation and initialization
-
New York City (NYC)- *p/s, awaiting installation and initialization
*p/s = prepared, shipped
An AMP machine (at the NZ National Library) went live this period, using the new AMPlet code. It is the first actual deployment of the new code and is working well so far.
We received a second query for an AMP machine from China. We suggested that the two Chinese sites coordinate amongst themselves, with our support.
AARnet (Australia) is upgrading the Australian backbone to 10GE. The two 10GE links from Sydney to the US are configured the same way as the previous two links to the US. The one NLANR AMP in Sydney may be able to measure both new high-speed links to the US.
amp-kiwi was moved into the full international mesh, after we came to a special arrangement with the University of Waikato regarding paying for measurement traffic. This means we no longer pay by the byte for that traffic as long as we do not cause the University's link to fill.
Per Brian Court, they are still planning to place AMP monitors on CENIC. He expects to follow up soon.
~ Upgrades, troubleshooting, and maintenance on the AMP infrastructure
A total of 30 remote sites in the AMP infrastructure received attention during this period: most were resolved during the quarter and the monitors are again collecting data. Only two were still being investigated, or pending site action, at the end of the period. (Outages are considered "open" until the monitor is again collecting data.)
Following evaluation of our performance tests of both FreeBSD and Debian Linux on the new AMP and VOLT servers, Debian Linux was chosen. SDSC NetOps issued two additional IP addresses for the new servers. They are to be configured with two IP addresses each such that failure of either machine will cause the remaining machine to take over serving in a more seamless manner.
The new AMP monitors are in one RU chassis that are only fourteen inches deep. We began to use these with the Cambridge site. Research on available 10 Gigabit Network Interface Cards from various manufactures continued. We are looking at the Intel PRO/10GBE LR (long range, single mode) Server Adapter; distribution seems to be a problem at this time.
Archiving of AMP and VOLT finishes leaving the disk fill from 77 to 80 percent over the eight data disks. A plan to use the 36 GigaByte disks from the de-commissioned PMA server was implemented. The idea was to keep the /disk0 through /disk7 the same size on AMP and VOLT to keep the directory layout identical between the two. The change was made on the AMP data collector; at the next archiving, the data disk fill proceeded as expected and was in the low eighty percent level. However, /disk0 and /disk1 were in the low fifty percent level since those were replaced with 36 GigaByte disks. We will do the same on VOLT with the other spare 36 Gig drives.
In reaction to a severe break-in experienced at SDSC, the ftp to HPSS was turned off. This was discovered upon starting the archive process on AMP. After much coordination with the HPSS people, a temporary work-around was applied. It was a TCP-wrapper type of access solution such that the legacy ftp is allowed from the AMP and VOLT servers. However this is temporary, the HPSS group plan to terminate the use of ftp and pftp and require use of a new interface (HSI HPSS). The security exploit at SDSC was through an SSH vulnerability. There was some fear that NLANR infrastructure monitors may have been compromised. NLANR sites were examined, one by one, looking for possible changes that might indicate a compromise. To date, nothing has been found to indicate that any of the NLANR sites were compromised. Another security event occurred at SDSC. This affected NLANR infrastructure operability in the short term (email primarily), however, the HPSS path experienced changes which disabled the AMP data archiving process for a time.
We are working on implementing the HSI HPSS interface as soon as possible. Access issues from AMP and VOLT are resolved. HSI command set was reviewed for use in the AMP/VOLT script. Coleen Shannon of CAIDA sent a helpful archiving script. Don Fredrick of the HPSS group is working to create access to the HSI HPSS interface. Discussions about this implementation lead us to contact Mike Gleicher, the IBM contractor that created the HSI HPSS interface. Mike confirmed that no Perl HSI module exists similar to the Perl FTP module; he made a number of suggestions. Larry Diegel of SDSC is developing a recommendation on the best method to assure data archived by the HSI interface is secure before it is deleted from the AMP/VOLT server.
We experienced some anomalies with the system manager software on photon. It appears to fail to upload files when all the parameters are correct, specifically processes update_systems, build_XXX.list.pl and build_hosts.pl. The list and hosts building processes apparently fail to recognize and incorporate entries. This is likely to be the root cause of missing sites and data in the AMP Web interfaces data pages. At least three relatively new AMP sites are failing to make it to the Web interfaces data page despite the fact that those sites are collecting and transferring network data.
We experienced a disk failure on the AMP server early in the quarter, recovery was complicated by the failure of a second disk. Two months later, the first disk failed again. Full recovery was completed each time. To keep the Web server up and working well while we fixed things, AMP's IP addresses were aliased onto volt.
Warren Mathews needed additional space on the calorie.nlanr.net machine for the AMP Web Services database. Databases were moved around on calorie to make some immediate space for him. Many concepts for the long-term storage of this data were investigated. Initially, we thought that the addition of a three hundred GB disk would provide the answer. Testing determined that the legacy system would not support the larger IDE Drives. The next solution appeared to be a 288 GB disk array from the old surplus PMA server put into service as a RAID 0. Turns out there were some issues with the kernel on calorie we will have to deal with in the future. Matthew Luckie provided critical assistance in this. He pointed out that the ccd could be installed by modules. After this, the installation was simple. Warren's database was copied into the concatenated disk array.
We have made some definitive steps towards getting HPWREN passive monitoring data published and analyzed. Time was spent researching options on how we can transfer the data from HPWREN onto PMA without causing too much CPU and administrative overhead. We went in circles a few times, including rebuilding SSH and SSHD to include the cipher NONE, eventually we settled on putting in a private network only consisting of a twisted pair drop cable between the two machines as a private Gigabit pipe and RSH to automatically transfer the data on a daily basis every night.
Matt Zekauskas, Rick Summerhill, and John Hicks,Internet2~
PMA: Working with them on the IPLS/Abilene instrumentation. Matt came back to us with a list of proposed research ideas as a follow up of our meeting in Indianapolis. We replied with a staged plan for the collaboration and provided a pointer for early access to the most recent OC192c backbone data captured on the link from Indianapolis to Chicago (IPLS-CHIN). Conversations with John about future TransPac plans.
Pere Barlet, UPC Barcelona~
PMA: Pere will be continuing his collaboration with us, building on his real-time work performed during his visit to Hamilton, NZ, in January and February. He has introduced us to a colleague of his working on active measurements. It looks like there could be an opportunity to develop a bandwidth estimation module for AMP.
Ernesto Rubi and Eric Johnson, Florida International University (AMPATH)~
PMA: In discussion with Ernesto Rubi and Eric Johnson, we determined the needs and expectations that AMPATH has towards NLANR in our joint project and it appears as if real-time analysis broken down on a per-VC basis would be interesting and useful. AMPATH already uses MRTG and it would be a matter of complementing those graphs with more detailed information (see http://www.net.fiu.edu/mrtg/ampathgsr.html).
Harvey Newman, CalTECH ~
Spoke with one his colleagues at FIU who is exploring the integration of AMP and PMA data into MonaLISA for Grid monitoring.
University of Florida~
AMP: Our collaborators at UFL have briefed us on their active monitoring project--they have already deployed around 30 1U systems with GigE interface around the campus and are also facing some 20-30 other units around Florida. Communications with V. Alex Brennen who is a new hire going to be responsible for this project. We briefed him on some of the AMP goals and architecture and urged him to be in touch with Tony, as there is a good chance for some excellent collaboration, specifically because of the plans to look into extending AMP into the campus and the status of the AMP software beta package.
Arne Oslebo and Olav Kvittem, UNINETT Norway~
PMA: Discussed the possibility of receiving a couple of Gigabit traces from their location.
Markus Peuhkuri, Helsinki University of Technology~
PMA: Discussed the opportunity of getting a couple of OC48c traces from the Finnish research network.
Constantinos Dovrolis, GATECH~
PMA: We explored the opportunity of placing any type of monitor, possibly a GIGEMON, at their network access. Constantinos is also keen to get his hands on our latest Gigabit and 10Gigabit traces and we will be sharing analysis results.
Paul Schopis, OARnet~
PMA: We have a positive response regarding placing an OC48MON at their feed to Abilene, which turns out to be Indianapolis, and we could arrange that along with the planned instrumentation of the IPLS backbone node; to be put on their link to the IND GigaPOP.
Margaret Murray, CAIDA~
AMP & PMA: Brief meeting with her regarding TeraGrid monitoring. Discussions with her about possible joint work on measuring high performance systems; possible NLANR participation in TeraGrid measurements.
OptiPuter~
AMP: The plan is to deploy software-only AMP code on several nodes and do application-to-application measurements. Tony applied for an OptiPuter account and begin testing.
Amy Andrews, DOD~
AMP & PMA: Meeting with her about NLANR measurement activities. She requested a copy of the international collaborations white paper.
Phil Dykstra, WareOnEarth~
AMP: Email conversations with him in regard to working with him on testing S2io 10GigE NICs. He is happy with that, and perhaps adding the NLANR voice to his request might help him get the cards loaned from S2io.
HPWREN~
PMA: We are spending considerably more time on network analysis for HPWREN, which will hopefully soon involve more of NLANR/Jörg, as Jörg has expressed interest in the passive data we are collecting for his/NLANR purposes. Jim had put a machine together that is powerful enough to do 24/7 traces plus analysis. Before the last machine crash we had an initial automated setup working that collects a 24 hour trace, then starts a new one, analyzes the old trace, and emails the results. Currently it displays the top N HPWREN addresses for sources and destinations.
Ian Pratt, Cambridge~
AMP & PMA: Worked with him regarding PAM2004.
Klaus Mochalski and Klaus Degner, University of Leipzig~
PMA: Discussions and email exchanges with Mochalski regarding his planned visit to SDSC in July and August this year, and also with regard to Degner's visit October-January 2005.
Chris Bruja, CISCO~
AMP: We wrote and submitted an application to CISCO for the development of a 10GigE AMP, including cost estimates and ideas for equipment, (2x Intel 10GigE nic, 2x S2io 10GigE nic, 2xPCI-x PCs).
John Towns~
AMP & PMA: Coordinated the NLANR review presentations with him.
Peter Arzberger, and Teri Simas, PRAGMA~
AMP & PMA: Worked with him regarding PRAGMA6 meeting planning and NLANR slides. Exchanged emails with him about the AMP with the CUDI group in Mexico City. Spoke with her about PRAGMA6 meeting preparations, including emails with her on software questions for Greg Cole in preparation for the meeting.
Andrew Moore, Cambridge~
AMP: Discussion with him about their new AMP box and what appear to be major network problems getting to it.
Bill Cleveland, Purdue (formerly Bell Labs)~
AMP & PMA: Communications with him about a project for instrumentation at Purdue with PMA monitors; also discussed a possible AMP deployment with him. He has offered to host an AMP machine, and is looking into an opportunity at the University for another monitor. Both an AMP monitor and a PMA monitor were deployed at Purdue the quarter.
Warren Matthews, SLAC~
AMP: He is creating an AMP Web Services implementation, modeled after AMI. Added him to the throughput test list so he can test the Web services interface to that. He determined a need for additional space to the calorie.nlanr.net machine for the Web Services database. We made some immediate space for him, and later put the old surplus PMA server into service as a RAID 0, and Warren's database was copied into the concatenated disk array.
Kathy Benninger, PSC~
PMA: Positive response from her to meet at Pittsburgh to make the OC48MON operational. Joerg visited PSC on his "monitor tour" and with follow-up afterward successfully brought the monitor online. It is now collecting data.
Eric Harder, NCSC~
PMA: We pulled Colorado State data for January 26-28, 2004 from the HPSS for him.
Hao Jiang, Georgia Tech~
PMA: We had an inquiry from Hao, one of our trace data users and a student/colleague of Constantinos Dovrolis.
George Clapp, Telcordia~
AMP & PMA: Spoke with him about using traces for router and switch performance simulation. We directed him to Jörg with respect to PMA traces.
Greg Cole, Gloriad~
AMP: Conference call with him about NLANR and the Gloriad proposal. Other communications with him concerning future GLORIAD measurements. Greg will work with groups in Russia and China to create a list of addresses for one-way AMP measurements.
Yenyung, George Washington University~
PMA: He approached us to provide data from MRA between end of January and mid February; we got those traces off the HPSS for him. His research is also on looking at the spread of a particular worm.
Paola Grosso, SLAC~
AMP: Gave him access to the throughput tests. He is using them via the web services query request interface that Warren Matthews has done.
Chris Costa, and Brian Court, CENIC~
AMP: Granted him access to run AMP throughput tests. He wishes to use AMP to conduct ad hoc tests on CENIC backbone legs. Chris indicated that CENIC is planning to request AMP monitors at the CENIC backbone nodes. Chris is working with Brian Court to follow through with the AMP requests. Brian expects to follow up with that very soon.
Sevcan Bilir, University of Texas Dallas~
AMP: We had a query from Sevcan about our IP to AS translator (IPAS). She is a PhD student. In answering her question, a small bug in the sample code (not related to her question) was discovered and corrected.
Kevin Walsh, SDSC Net Ops~
AMP and PMA: Conversation with him about his measurement activities and the July Joint Techs meeting.
Glenn Larratt, Rice University~
AMP: Some talk with him about duplex match problems with their machine.
Vinton Cerf, MCI~
AMP & PMA: We enjoyed a visit from Vinton, and it was fascinating to hear of his experiences in earlier network development as well as about the work he is currently doing with MCI.
Mark Allman~
AMP: Suggested Tony and Matthew write a paper on how IPMP would be used to debug path faults.
Endace~
AMP: Some discussions with Endace that ended with them offering to fund a student to create IPMP transmit code for the GigE DAG card.
David Malone~
AMP: Exchanged emails with him regarding 6to4 tunnel discovery. Sent him some data on what was done with AMP to discover the location of each AMP monitor's closest 6to4 anycast tunnel. Also sent him an address list to help with his work. David was referred to us by Pekka Savola based on some earlier work we did with Scamper. David also offered to host a Scamper monitor.
Bill Owens, NYSERNet~
AMP &PMA: Email to him about something seen on Internet2's IPv6; however, NYSERNet was largely not routing to a bunch of the other AMP monitors. Followed up on his offer to use of a Linux machine with a Broadcom GigE card directly plugged into a NYSERnet router that can route packets >1500 bytes. Also working with him to find MTU bottleneck locations on I2, probing with Scamper from two hosts. Bill has also probed PlanetLab hosts, but has not found a PMTU >1500 to those either. He wants to extend this to cover all of I2, and has supplied us with a BGP table to pull out ASes and address ranges to form an address list. He will do the tagging. He would like to see jumbo capable AMP monitors that could be used to highlight connectivity problems. Bill also provides bug reports for Scamper. Upon inquiring about NYSERNet hosting a PMA monitor, received a long, very helpful reply, detailing possible instrumentation ideas. Thanks to some pointers provided by Bill, we are learning about DWDM and the underlying architecture of the National LambdaRail and the I2 HOPI project.
Kenjiro Cho, WIDE~
AMP: He supplied a patch to Scamper that fixed up some compile issues on NetBSD and changed the logic slightly for detecting loops. He also reported a few issues with the operation of the PMTU code, which spurred us into action on dealing with some of them. Received a Scamper-pmtu run on a 900 entry address run from him to dual-stack nodes. Kenjiro also provides useful bug reports when Scamper does something bizarre.
Grover Browning~
AMP: In touch with him to help form an address list to cover Abilene, for Scamper IPv6.
Bill Decker, UCSD~
AMP: Worked with him on legal/copyright issues regarding the release of the new AMPlet package.
Ivan Koga, Brazil~
AMP: Granted access to his machines to do AMPlet code debugging, and he will be using a pre-release of the new software.
Colleen Shannon, CAIDA~
AMP: Provided a helpful archiving script to assist in the HSI HPSS interface implementation.
Don Fredrick, and Larry Diegel, SDSC~
AMP & PMA: Don is working with us to create access to the HSI HPSS interface (for archiving our data). We worked with Larry on the HPSS HSI interface. He is developing a recommendation on the best method to assure data archived by the HSI interface is secure before it is deleted from the AMP/VOLT server.
Mike Gleicher, IBM~
AMP: He is the contractor that created the HSI HPSS interface. In response to a question from Tony, Mike confirmed that no Perl HSI module exists similar to the Perl FTP module. Mike made a number of suggestions for us to follow up on (in order to verify security of data before deletion from the servers).
Kostas Pentikousis, SUNY Stony Brook, and Marwan Sleiman, UCONN~
PMA: In an effort to increase site participation in the PMA project, we have emailed Kostas. He is enthusiastic, but needs more information before proceeding. Similarly, we approached Marwan, but have not had a response as yet.
Jason Hurd, Endace North America~
PMA: Worked with him to find a solution for some extra gear we needed in Indianapolis.
Wanming Luo, CNIC~
AMP: He is our contact in Beijing for the NLANR AMP monitor. He would like AMP to be IPv6 compatible and measure Gloriad.
Putchong Uthayopas, High Performance Computing and Networking Center, Thailand~
AMP: He will purchase one PC to host the AMP software. If we are interested, he will put in a proposal for funding to purchase eleven to twelve more PCs to host NLANR AMP code for universities on the Uninet network in Thailand.
Larry Ang, Singapore~
AMP: He will host an NLANR AMP monitor.
There was an inquiry from a Canadian University regarding Auckland-4 data.
~ Papers, Presentations, and Conference/Meeting Participation
McGregor, A., M. Hall, P. Lorier, and J. Brunskill. Flow Clustering Using Machine Learning Techniques. Proceedings PAM2004 Passive & Active Measurement Workshop, LNCS, Antibes Juan-les-Pins, France, pp. 205-215, Apr. 2004.
Mochalski, K. and J. Micheel. A Real-Time Packet Burst Metric. Proceedings TERENA Networking Conference, Rhodes, Greece, June 2004.
Matthew Luckie is an author of two papers (primary/first author on one and a coauthor on another) accepted by the SIGCOMM Network Troubleshooting Workshop (NetTs), which accepted only 13 papers total (from 36 submissions).
- Matthew Luckie and Tony McGregor. User Level Path Diagnosis with IPMP. - has been accepted for publication/presentation by the SIGCOMM Network Troubleshooting Workshop (NetTs).
- Kenjiro Cho, Matthew Luckie, and Brad Huffaker. Identifying IPv6 Network Problems in the DualStack World. - has been accepted for publication/presentation by the SIGCOMM Network Troubleshooting Workshop (NetTs).
PAM2004, Juan-les-Pins, Antibes, France, April 19-20, 2004 ~ Tony attended and presented his paper. Ronn and Jörg also attended.
Joint Engineering Team (JET) Meeting, Arlington, VA, April 2004 ~ Ronn, Tony, and Jörg attended the measurement workshop discussion session via teleconference, a main topic was discussion regarding requirements on measurements.
CAIDA-WIDE workshop at ISI ~ Matthew attended and presented. He spoke on IPv6 DNS misconfigurations seen in the data obtained from a DNS walk, and Scamper developments (path-MTU, alternative path discovery, measurement of those alternative paths, reverse-path traceroute).
PRAGMA meeting, Beijing, China ~ Ronn attended and while there met with many of the top networking people from the region, discussing possible collaborations and deployments.
The possibility of having a real-time software demonstration for SC2004 was discussed.
~ Documentation, Publications, Networked Data and Web Work
The PRAGMA Web site posted a link to our International Successes white paper written by Ronn Ritke and Mike Gannis. Article title: NLANR/MNA Builds an International Infrastructure for Network Research. http://www.pragma-grid.net/news_items.htm
The current issue of the NATimes was distributed at PAM2004, along with the OC192/10GigE - International one-page handouts. These were also distributed in the SDSC reception area.
Several handouts were created to highlight some of our premier activities. These were put together as a package for the NSF Review and will be distributed singly and as a package elsewhere as circumstances dictate. Topics included: PMA Special Traces, AMP PathVis, AMP daily graphs, Data Users - the list of all the papers citing us (that we have uncovered so far) with quotes on the usefulness of our data (taken directly from the text of the papers), Published Papers referencing our work, Comments from AMP data users (systems folks) and our 10GigE/OC192 efforts.
We began plans to develop a "story pitch" briefing sheet to be used by media relations people highlighting our activities (in particular, international cooperative efforts and GLORIAD participation) in media such as Federal Computer Week.
Excellent progress was made on the overhaul of the Web pages. The long planned redesigned new NLANR/MNA home page was taken live. It has been extensively redeveloped - style, backend, form, and function. The new home page's primary attributes are the "Latest Pings" section, which is intended to be regularly updated with our latest activities, and the Highlights section which contain quick links to our major efforts. The format of the Latest Pings is such that it can be quickly scanned to see the contents. http://mna.nlanr.net/
An introduction to our research efforts and overviews of each of our two primary projects (PMA and AMP) current status and efforts was written and linked off of the new home page. http://mna.nlanr.net/infrastructure.html
The AMP data interface backend is being revamped. PHP code was written to store user preferences in a PostgreSQL data base. The list of preferences, and how to display them is also stored in the database. The user can retrieve them via an inter-session cookie or with a username/password login.
A PHP extension with the basic functionality for RTT data was written. It is modelled around the way databases are interfaced to PHP and returns a PHP resource that can then be used repeatedly to get the next data item as a PHP 'object'. It starts at an arbitrary time and continues across multiple files if required. The time zone translation code is being implemented, to enable users to get the data in whatever time zone they want. We were unable to find code that converted from one time zone to another that would be suitable for our needs, therefore we are writing code that will parse the time zone data files.
Code was added to the PHP extension for AMP to make it compatible with both the old and new versions of the files (from the old amp code base and the new AMPlet package). Coding continued on the first data page for the new central code. The ability to display a RTT graph in any time zone from the old data is now possible. The time zone preference is remembered from session to session either by a cookie or through a user login, backed by postgresql database. Integrating the new and old data formats into the library was a bit tricky because the two are recoded in different time zones--the new data is recorded in UTC-- therefore, knowing the time zone is necessary to work out the file name. Currently there is a single daily graph which can display mean, median, max, min stddev, and jitter. It has user selectable bin sizes and (optional) ymax value. It still needs to be polished.
Significant progress was made on the PMA Web logs project. The first phase (FTP download user statistics) of the Weblogs for PMA's download activity was completed. Graphs chart the number of users, total volume of traffic, and number of files for the months from October 2001 through April 2004. There are individual Web pages for each month and three summary pages, one for each parameter with all the monthly graphs. There are also yearly overviews of the three parameters for 2002 and 2003. http://pma.nlanr.net/Stats
The m4/Makefile system for making changes to the Web page templates and navbar was further developed with the creation of the template set for MNA pages (that is, those that are not strictly PMA or AMP). Several of the primary MNA Web pages were converted to the system, and thus had their look, form, and function updated as well. Many AMP and PMA pages were converted to m4.
Multiple index pages were developed for the Special Traces. The three pages differ in their method of indexing the special traces available: alphabetical, chronological, and grouped for easy comparison. http://pma.nlanr.net/Special/
We began investigating creating a database/query system for use with the Citings and Collaborations Web pages. This will enable the creation of AMP or PMA only versions of these pages, as well as make the information easier to handle and build upon. We had originally thought we would use an m4/Makefile system similar to he Web page template system which we created earlier in the year. This solution is not sufficient for the complexity of the data involved.
A Web page banner was designed and created to denote "historic" Web pages. The banner includes both our NLANR/MNA and NSF's logos. It is to be used on pages which the community may still want to see for historical info or background, but have not been modified or updated, so may have broken links and old info.
The matrix of HTML file was improved to make browsing easier for the end user, as can be seen on this Abilene-III Web page: http://198.202.123.33/Special/ipls3/.
The published papers Web page has been updated. http://mna.nlanr.net/Papers
The AMPlet package was added to the tools index page. http://mna.nlanr.net/tools.html
Matthew Luckie continues to take the lead on the AMP IPMP and AMP IPv6 efforts. He wrote an application to pull out sets of alternative paths between the same pairs of IPv6 addresses. Then, he wrote another application for measuring delay differences between sets of IPv6 addresses using the IPv6 routing header. If we route a packet through addresses [A, B, C, D, E, A] and [A, B, F, G, E, A] we can infer which is the better path (in terms of delay) by comparing the two RTT times. As the only difference in the path is between B and E, we can report which path exhibits better delay characteristics.
Matthew is an author of two papers (primary/first author on one and a coauthor on another) accepted this quarter by the SIGCOMM Network Troubleshooting Workshop (NetTs), which accepted only 13 papers total (from 36 submissions).
He continued work on Scamper, including using Linux Netlink to get the outgoing interface's MTU value as an initial packet probing size. Also, Matthew implemented flow counters in IPMP path records.
Lana Kennedy has continued working with Maureen on a number of projects. In addition to assisting with reports, she has also helped out with Web pages. She created a highlights list to be used for the MNA home page, updated the Meet the Team page, and added new papers to the Pubs list. Lana contributed to the AMP Web pages, creating a temporary home page using some of Maureen's boilerplate language, and also editing the AMP Web Services language. On PMA, Lana created more 100-pixel navbar images that tie in with the Special Traces. She also helped with the NLANR review handouts, taking the folders to be cut and scored, adding special pockets to them, and also doing some light editing on one of the handouts. She was very pleased to see much of the work she had done over the past year reflected in the handouts.
The big focus for next quarter will be on Citings and Collaborations. Lana has already updated the Citings information to reflect the latest conference proceedings, and is looking into a way to creating new Citings graphs. She and Maureen are now working on a database system to automatically generate Citings pages, Collaborations pages, and also to create a repository for the Latest Pings. Lana is learning to use the m4 macro system, with the focus on creating these pages.
Chris Gross' main project this quarter was to create a logging system for our PMA user statistics (trace downloads). It includes FTP and HTTP downloads, and incorporates three metrics: amount downloaded in gigabytes, number of users, and the number of files downloaded. The results of the logging are published to the Web on a monthly and annual basis.
~ Staffing Activities
The hiring process for the new staff member, the AMP Software Engineer, was completed. The last of the coding skills tests were administered, the test results and code were evaluated along with the resumes and three final applicants were chosen for interview. Interviews were held, references were conducted, and all information was evaluated and a decision was made.
Arrangements were made to host Klaus Mochalski as a visiting scholar again this summer. And to host Klaus Degner in the Fall (October-January 2005).
- 30 -
2004 July 21 NLANR/MNA home page
|