The Projects

The Institute operates by supporting projects that maintain and improve the Internet Infrastructure. This page summarizes major Institute projects and prospective projects.

All Institute projects follow open-source and open-access practices.

Continuing missions

These are projects for which we don't yet have operational planning or project owners. We will do more of them as the Institute scales up.

  • Support the standardization process by funding work on open-source reference implementations of RFCs and other standards. Speed up deployment of needed protocols such as DNSsec and IPv6.
  • Emergency response to service collapses and compromises. What happens on discovery of a security or DoS vulnerability in a core service? So far, responses have been effective, but ad-hoc. So far, we've been lucky.
  • Continuing attention to the roads, bridges, and chokepoints. Someone needs to be auditing for architectural and implementation vulnerabilities over the whole Internet so they can be fixed before they become acute problems.
  • Bridge funding and services to under-resourced infrastructure projects, and help in finding them sustained funding from slower-moving organizations.
  • In theory, the Internet is a self-healing network that can survive the loss of even major nodes. In practice, we don't know a lot about how to recover if an earthquake or a bomb were to take out a major exchange point. We need disaster planning, and no one is doing it.


The performance of the Internet is seriously compromised by poor queuing and buffering strategies in TCP/IP stacks and network routers today. The symptoms of this problem mimic network undercapacity, and include both extreme latency spikes and wild utilization swings that lead to poor VOIP, gaming, and interactivity when competing with others using the same network.

The bufferbloat project , over the past 3 years, has made significant inroads on the problem, with new algorithms entering wider deployment and a standardization effort now taking place within the IETF. Much remains to be done. There need to be more comprehensive simulations and tests developed, large scale studies conducted, and while the now-developed solutions exist for cable, fiber, and DSL, wireless and wifi technologies need some detailed rework and rethinking in order to make them fast and efficient once again. And the developers need to be able to afford endless meetings to push the standardization process forward so that the algorithms are available by default, for all, on 2.4 billion machines or more.

The severity of this problem and the difficulty of getting mitigation efforts properly funded to completion was a major impetus to the foundation of ICEI.


Does anyone really know what time it is?

Synchronization of computer time to Universal Coordinated Time via NTP over the Internet is an obscure but vital service that many other Internet services rely on. While accuracy for this service is often quoted as having an upper bound of 10 milliseconds, in reality almost nothing is known about how time service degrades under heavy network load and in the presence of network pathologies like bufferbloat.

Recent advances in the engineering of inexpensive time sources make it feasible to disperse 1ms-accuracy clocks across many Internet nodes so that maximum clock skew can actually be measured. The deployment and coordination problem is significant, however, and needs both volunteer efforts and serious funding.

This is a prospective project. It has two principal investigators and a realized hardware design for an inexpensive high-precision clock. Deployment awaits both the development of a data-collection software suite and support funds for buying and shipping hardware.


It is difficult to tune what you can't measure. Attempts to improve Internet performance and diagnose problems are severely hampered by a paucity of end-to-end measurements of actual Internet performance.

As a followon to Project Kronos, the Institute aims to build a real-time health-monitoring network for the Internet. This would at the very least enable more rapid and effective response to outages and misrouting problems. It will be valuable for global performance tuning, and for identifying undercapacity issues by measurement rather than guess.


The quality of the firmware loads in residential and small-business Internet routers is often extremely poor. There are serious security and consumer-privacy issues arising from the closed-source nature of much of this software. Major ISPs aren't very happy with the situation either, as it incurs significant engineering costs and involves them with kinds of software problems they are not specialized for and don't handle well.

The open-source community has volunteer projects that address the technical end of this problem effectively; a notable one is OpenWrt. These projects are, however, under-resourced and don't have institutional structures that equip them to talk directly to ISPs and other firms and institutions with incentives to cooperate in large-scale deployments of their software.

ICEI aims to act as a market-maker that can help these software projects cooperate with potential large users - solving procedural problems, directing funds where they can do the most good, and heading off destructive culture clashes. Noticeable improvements in the typical end-user's Internet experience could follow.


How do you know you're getting the Internet service you paid for? Are you really getting the bandwidth you were promised? Is your Internet provider covertly blocking your access to websites it disapproves of, or throttling particular transfer types? ISPs can't necessarily be trusted to answer these questions.

ICEI intends to fund and then help deploy software that will enable users to objectively measure the quality of their service and disclose blocking or traffic-shaping policies that might affect it.