This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender.It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header.It is computationally efficient for both routers and hosts.

In traditional operating systems, modifying the network protocol code is a tedious and error-prone task, largely because the networking stack resides in the kernel. For this reason, among others, many have proposed moving the networking stack to user-level. Unfortunately, implementations of this design have never entered widespread use due to the impractical requirements they place on the user: either the kernel or applications must be modified; or code cannot be moved seamlessly between the user-level and kernel stacks. In this paper, we present Alpine, a user-level networking infrastructure free from these drawbacks. Alpine supports a FreeBSD networking stack on top of a Unix operating system. It is freely available as source code. In this paper, we discuss the challenges we faced in virtualizing the FreeBSD networking stack without compromising on kernel, networking stack, and application compatibility. We then show how Alpine is effective at easing the burden of debugging and testing protocol modifications or new network protocols. In our experience, Alpine can reduce the overhead of modifying a protocol from hours to minutes.

We present an improved Explicit Congestion Notification (ECN) mechanism that enables a router to signal congestion to the sender without trusting the receiver or other network devices along the signaling path. Without our mechanism, ECN-based transports can be manipulated to undermine congestion control. Web clients seeking faster downloads, for example, can trivially conceal congestion signals from Web servers. A misbehaving connection would exceed its fair bandwidth share at the expense of competing traffic by as much as an order of magnitude in our simulations. Our improved mechanism is robust because it does not depend on correct implementation at locations other than the sender and marking router and it is practical because it admits an efficient implementation that is backwards-compatible with prior ECN and TCP/IP mechanisms.

We consider an architecture for a serverless distributed file system that does not assume mutual trust among the client computers. The system provides security, availability, and reliability by distributing multiple encrypted replicas of each file among the client machines. To assess the feasibility of deploying this system on an existing desktop infrastructure, we measure and analyze a large set of client machines in a commercial environment. In particular, we measure and report results on disk usage and content; file activity; and machine uptimes, lifetimes, and loads. We conclude that the measured desktop infrastructure would passably support our proposed system, providing availability on the order of one unfilled file request per user per thousand days.

The Domain Name System (DNS) is a vital part of today's Internet, playing a role in vast numbers of web transfers each day. As the number of users and the number of names in the Internet grows exponentially, the DNS's ability to deliver name translations quickly becomes more and more integral to the performance of the web. This is a study of DNS latency. How long does the DNS take to return trans- lations? When it does take a long time, what went wrong? Do applications put DNS lookups in the critical performance path, or is DNS latency unimportant to apparent application responsiveness? We have taken traces of all network traffic in and out of a large research community. We analyzed the DNS activity and its relationship to other traffic and found that DNS does its job remarkably well most of the time: latencies are generally quite low. In rare cases of high latency, we found that at least half the time, one or more remote servers were down or unreachable. Finally, we found that while the information received in many DNS transactions was used right away, the delay between lookup and first use was often very large.