FP6Reintegration grant2007–2009

FILD · Providing real-time feedback on Internet packet loss and delay

FP6 — Marie Curie Actions (Human Resources and Mobility)

Duration
2007-05-01 → 2009-04-30
EU contribution
€80,000
Participants
1
Scheme
IRG

Lines connect the coordinator with its partners.

Results in brief

Final Activity Report Summary - FILD (Providing Real-time Feedback on Internet Packet Loss and Delay)

The goal of the project was to enable edge-systems to evaluate the performance of their Internet service providers (ISPs). To this end, our first task was to design AudIt, a protocol by which ISPs send feedback on the traffic they forward to the corresponding source domains; as a result, source domains receive information regarding the loss and delay incurred by their traffic. More specifically, each source domain learns the number of lost packets and the average delay incurred by each flow. To evaluate AudIt, we developed two preliminary prototypes: one to be run by ISPs (it collects per-flow statistics and sends them to the corresponding source domains) and another one to be run by source domains (it receives and combines the feedback sent by ISPs to compute the loss and delay incurred by each flow along its path). The first prorotype was implemented as a Click module, while the second one as a C++ network application. Our main results were to show that AudIt prevents lies (i.e., forces participating ISPs to tell the truth about their performance) and can be deployed with reasonable (processing, memory, and bandwidth) resources. During the second period of the project, we continued along three directions: (1) We improved AudIt: As originally designed, AudIt had one disadvantage: it required that each ISP maintain per-flow state. Under normal circumstances, an ISP should have the resources to maintain and process such state. However, under extraordinary circumstances (e.g., denial-of-service attacks that generate an unusual rate of new flows), maintaining per-flow state may be too expensive. Hence, we designed an improved version of AudIt, which allows each participating ISP to arbitrarily reduce the amount of state it maintains at the cost of also reducing the quality of the feedback it provides. Our main result was to show that (like the original AudIt) our improved version prevents ISPs from lying about their performance, yet (unlike the original AudIt) it allows each ISP to choose its own trade-off between the resources it uses and the quality of the feedback it provides. (2) We investigated deployment options: The main criticism we received from the academic community for AudIt is that it requires adding (modest) functionality to ISP network equipment, in particular, border routers. Unfortunately, the data-plane of modern high-speed routers is typically built in hardware, making it very hard to add any functionality to it, however modest. This motivated us to develop Routebricks, a router that achieves comparable performance with hardware routers, yet is built entirely in software, hence, is fully programmable. If ISPs used such software routers, then deploying AudIt (or any new protocol) would be significantly easier. Routebricks is essentially a cluster of commodity servers running Linux and Click. We implemented a prototype that achieves aggregate throughput 35Gbps. Routebricks was developed in collaboration with Intel Research, Berkeley. Intel has showed a lot of interest in our work, as that would enable it to enter the market of high-speed routers. (3) We started to explore an alternative approach: According to AudIt, ISPs voluntarily report their performance to end-systems. The alternative approach is to enable end-systems to collaboratively infer ISP performance by performing end-to-end measurements. This approach is called 'network tomography' and has already been thoroughly studied by other researchers, but at a theoretical level (to our knowledge, there exists no real tomography-based system that measures Internet performance). Our contribution was to study tomography from a practical point of view. First, we proved the limits of what tomography can do in real networks, i.e., up to how many failures it can detect. Second, we started to develop Netscope, an actual tomography-based tool that runs on PlanetLab nodes and infers the loss rates of Internet links. Netscope is developed in collaboration with Swisscom, the biggest ISP in Switzerland, which has expressed interest in using it to monitor the status of its neighbouring networks, in order to be able to choose good routes for its customers.

Data: CORDIS, © European Union

Project objective

Today's Internet provides no a priori guarantees about when or if packets will be delivered; this best-effort design has been key to Internet simplicity and scalability. Unfortunately, the Internet also provides no feedback on the fate of transmitted packets. As a result, when a network failure causes packets to get lost or delayed, the sender of the packets has no way of knowing where the failure occurred. This makes it hard for the sender to adapt to the failure (e.g. send its traffic via an alternative path) or hold any administrative entity accountable for it. End-hosts try to address this problem by using probing tools like trace routes. These tools, however, are unreliable, cannot be used to hold ISPs accountable, and are frequently blocked by ISPs for policy or security reasons.This project proposes a solution, in which ISPs are motivated to willingly provide feedback on the loss and delay incurred by traffic within their network. Feedback is collected by monitoring boxes located on inter-ISP links and provided to interested parties. Our proposal attempts to reconcile the academic and industry perspectives on the Internet by developing a solution that is not only technically feasible, but also consistent with the current ISP business model: we enable ISPs to choose the level of feedback they provide, without revealing their internal structure.The proposed mechanism reveals to senders which ISPs are accountable for losing or delaying their packets; as a result, senders are able to evaluate the performance of their ISPs and route their traffic around failure points. Unlike traditional quality-of-service solutions, we do not provide senders with a priori guarantees; we only provide them with a posteriori feedback, which senders can then use to adapt to failures. In essence, we try to improve the end-to-end performance of Internet communications in the face of failures, without compromising the best-effort nature of the Internet architecture.

Original text from CORDIS.

Participants

  • ECOLE POLYTECHNIQUE FEDERALE DE LAUSANNE · LAUSANNECoordinatorSwitzerland

Links

Data: CORDIS, © European Union