Summer of Code 2006

Internet2 Summer of Code 2006: Project Ideas

Get paid $4500 by Google to write open-source code this summer! The deadline for submitting an application is May 8, 2006. The following are ideas for student projects (other projects are possible, depending on individual interest) for Google's Summer of Code. Internet2 is proud to be a mentoring organization for the initiative.

To ask a question or to clarify anything, contact Stanislav Shalunov. If you see nothing on the list below that is a good match for what you want to do, but if you think that Internet2 could mentor you, get in touch, too.

To apply:

1. Select a project;
2. Read the general program FAQ (non-Internet2-specific);
3. Read advice on writing a good application (this approach---high effort and high probability---is, of course, just one possible strategy);
4. Write your application (in plain text), which needs to include:
   • Your name and email address;
   • Project name (if using a project idea as given below) or project description;
   • How much time do you plan to put in the project? (In terms of both weeks and hours per week?) Do you have any other commitments this summer? Any periods of time when you won't be working on the Summer of Code? (In general, it's best if Summer of Code will be your main activity this summer.)
   • Your plan with a schedule: describe in as much detail as you can what you are going to do, with date estimates attached to milestones (make sure you leave some time for writing a project report at the end of summer);
   • Code sample. This is very important. The easiest way to judge a programmer is to look at his code. Put some of yours online and include a pointer.
   • Your biography/resume/CV (in plain text). Being brief and informal is fine (in fact, preferred).
5. Submit your application directly to Google, selecting Internet2 as your mentoring organization.
6. Checking this page every now and then before the deadline for any new information would probably help. Remember: you can always revise your proposal and resubmit, so keep a copy and keep improving it.

Important: Google allows you to resubmit your application. Get it in early to start a dialog so you have time to fix it if anything is amiss. It's perfectly fine, as far as we are concerned, to mark your application as provisional and submit a final version later.

Mini-FAQ

Q: Is project X taken?
A: This is a competitive proposal process. What matters is the quality of your proposal, not the number of other people who want to do the same thing. To repeat: just write a good proposal and put it in. If two projects interest you, do so for two projects.

Q: My university is not an Internet2 member (usually because I am not in the U.S.). Can I still apply?
A: Definitely. Google sets the rules of who is eligible, and there's nothing about Internet2 membership in the rules. You won't, in any way, be at a disadvantage. Last year, about half of the participants were outside of the U.S.

Q: I don't have access to Internet2. Can I still apply?
A: Definitely. If you need access, we'll give you accounts.

Q: Do I need to check with you before I file the application with Google?
A: Feel free to check, but it is not required. If you have no questions, there is little to discuss at this stage. Unfortunately, we can't help you with writing of the proposal---that part you'll need to do yourself. List of things you could include in the proposal is above. If you do have any questions, don't be shy. You can write a better application if you're clear about the project.

Q: I can't think of anything for item X on the list of things to include in the proposal. What do I do?
A: Think again. Still nothing? Omit it and go on. Make the proposal as detailed as you can, but don't obsess about items or checklists. We need to know what you want to do and why you think you can do it.

Q: I am not familiar with VFER (or thrulay or NDT or chrolog). Can I still apply?
A: Of course. All you need to be able to do is read and change the source code.

Q: I am a high-school student. Can I apply?
A: Sorry, but high-school students are not eligible. Maybe next year.

VFER: performance improvements

VFER is an experimental bulk transfer protocol that was started as a Summer of Code 2005 project (FB-FR-CCP). The protocol implements the Internet2 bulk transport protocol API and has some interesting reliability semantics. The current implementation is written in C and uses POSIX threads.

Perform a thorough performance analysis of the current implementation's congestion control and overall architecture. This will require a number of network traffic techniques such as transfer speed tests in different network environments, jitter evaluation, bandwidth utilization plots and more. Internet2's thrulay tool will be used extensively.

Besides protocol behavior on the wire, and evaluation of key internal timing components is necessary. These include RTT estimation, thread synchronization/contention, and more.

Once the bottlenecks are identified, work to resolve them. Example solutions might include:

• Rearchitecting the threading model to make the protocol single-threaded or a single thread per socket
• Changing the protocol specs and packet formats to make transfers more efficient
• Developing a congestion control model that does a better job at integrating delay information and loss information.

VFER: public key authentication

VFER includes tools for file transfer (vfer and vferd). Currently, the authentication is not secure.

Add public key authentication to VFER's protocol handshake. Start by using an external SSH process to handle the authentication over a separate TCP connection. Having SSH credentials and a VFER installation on the target machine should be sufficient to transfer files (in particular, starting vferd should be handled). Perhaps eventually integrate authentication into the protocol code itself and perform authentication over the VFER protocol.

Chrolog: enhancements

Chrolog is a library that allows applications to fetch timestamps orders of magnitude faster than if they went to the system clock (with, e.g., gettimeofday()). Chrolog is derived from two project from the previous Summer of Code: tsc-xluo and fasttime.

To obtain the code for chrolog:

cvs -d :pserver:anoncvs@anoncvs.internet2.edu:/home/cvs co chrolog

The following needs to be done about chrolog:

• Minor cleanup and making of a release.
• Set up web pages on SourceForge.
• Process improvements (e.g., nightly builds and tests).
• Consider adding/not adding frequency-lock loop (FLL); is it needed? Worth it?
• Integration with OWAMP: make OWAMP use chrolog for its timestamps.
• Windows builds (cross-compilation with MinGW is probably easiest).
• See if conversion between ticks and time can be further optimized.
• Provide conversion routines into and out of NTP time format.
• Expose chrolog error budget to the API.
• Allow optional NTP tie-in to improve error estimate. Decide how to talk to NTP: UDP port 123 on localhost (firewalls? restrictive ntp.conf?) or ntp_gettime (nano- vs microseconds?).
• Bonus points: On motherboards that measure temperature, make the frequency estimate a table that maps CPU temperature to rate.

Thrulay enhancements

The program thrulay is used to measure the capacity, delay, and other performance metrics of a network by sending a bulk TCP or UDP stream over it. It is written in C and could use various asserted improvements.

• For the API mode: a change so port allocation and test start can be separated
• Integration of thrulay into BWCTL (using thrulay API)
• Microsoft Windows version of client (or both?); probably cross-compiled
• consider how and whether to support multicast
• log CPU use by the daemon along with each test log record
• make `-i0' disable intermediate reports
• an option to show the version of thrulay and thrulayd
• a better select() loop with non-blocking write() in client
• do benchmarks for the best default block size

VFER: path MTU discovery

AMI OWAMP data: analysis on the web

Abilene OWAMP data (website currently inoperational, being fixed) displays OWAMP statistics for the Abilene network in a simple way. The same software (AMI) is used at a few other networks. The analysis could be made more interesting and data could be represented better. A useful start: the plots are mostly flat; find a way to compress the flat plots in the human-readable output and only show what's interesting (differs from flat).

Middlebox detection based on NDT

NDT already does some simple middlebox detection (looking at address mangling and MSS changes). This could be expanded significantly into, ideally, a signature-based system to detect various middleboxes: NATs (including, perhaps, NAT type characterization), firewalls, packet shapers, etc.

Event notification service for the IETF

Summary: Put together an event notification service for the IETF where people can subscribe through a web interface for personalized notifications, and provide notifications through any of the following mechanisms: RSS, Atom, Mail, and Web-pages (individually customized). This work will be done in collaboration with the IETF Tools team.

Background: Work in the IETF is carried out in more than 100 different working groups, with around 2000 active document at any given time. For any single participant, only a small subset of this work is of immediate interest, but when anything happens that is of interest, he would like to know as early and clearly as possible. The subset of interest to any one participant is also generally different from that of all other participants, so individually customized notifications would be optimal.

A browsable view of the process is available through document overview pages for individual working groups, but this needs to be complemented with a notification service for events such as draft updates, new drafts, last call announcements, published RFCs, new working groups, etc.

Some constraints: Individual events will be provided in a single format, to be agreed on. The notification service should store events by time and classification, and offer a web interface by which individual subscription to a subset of events is possible. The interface should dynamically build the offered selection criteria based on the field types already seen in incoming events. Events should be transformed from the canonical format to RSS, Atom, Mail, and HTML format. There is a strong preference for the system to be coded in Python.

VFER: multimedia tool

VFER includes facilities for very flexible reliability policies, which make it more suitable than TCP for multimedia streaming and interactive applications. (At the same time, you get congestion control, which is not normally present with UDP-based streaming tools.)

Develop an application using VFER specifically for its functional reliability semantics. The application must demonstrate the benefits of using a functionally reliable protocol. This topic might be difficult to carry out as the current implementation is in beta stages.

The best approach would probably be to start from an existing multimedia streaming or interactive application and then to integrate it with VFER. Prior familiarity with such an application would help.