This paper addresses the problem of churn---the continuous process of node arrival and departure---in distributed hash tables (DHTs). We argue that DHTs should perform lookups quickly and consistently under churn rates at least as high as those observed in deployed P2P systems such as Kazaa. We then show through experiments on an emulated network that current DHT implementations cannot handle such churn rates. Next, we identify and explore three factors affecting DHT performance under churn: reactive versus periodic failure recovery, message timeout calculation, and proximity neighbor selection. We work in the context of a mature DHT implementation called Bamboo, using the ModelNet network emulator, which models in-network queuing, cross-traffic, and packet loss. These factors are typically missing in earlier simulationbased DHT studies, and we show that careful attention to them in Bamboo's design allows it to function effectively at churn rates at or higher than that observed in P2P file-sharing applications, while using lower maintenance bandwidth than other DHT implementations.

Defending against DoS attacks is extremely difficult; effective solutions probably require significant changes to the Internet architecture. We present a series of architectural changes aimed at preventing most flooding DoS attacks, and making the remaining attacks easier to defend against. The goal is to stimulate a debate on tradeoffs between the flexibility needed for future Internet evolution and the need to be robust to attack.

Epidemic, or probabilistic, multicast protocols have emerged as a viable mechanism to circumvent the scalability problems of reliable multicast protocols. However, most existing epidemic approaches use connectionless transport protocols to exchange messages and rely on the intrinsic robustness of the epidemic dissemination to mask network omissions. Unfortunately, such an approach is not networkfriendly, since the epidemic protocol makes no effort to reduce the load imposed on the network when the system is congested.

Internet applications currently have a choice between stream and datagram transport abstractions. Datagrams efficiently support small transactions and streams are suited for longrunning conversations, but neither abstraction adequately supports applications like HTTP that exhibit a mixture of transaction sizes, or applications like FTP and SIP that use multiple transport instances. Structured Stream Transport (SST) enhances the traditional stream abstraction with a hierarchical hereditary structure, allowing applications to create lightweight child streams from any existing stream. Unlike TCP streams, these lightweight streams incur neither 3-way handshaking delays on startup nor TIME-WAIT periods on close. Each stream offers independent data transfer and flow control, allowing different transactions to proceed in parallel without head-of-line blocking, but all streams share one congestion control context. SST supports both reliable and best-effort delivery in a way that semantically unifies datagrams with streams and solves the classic “large datagram ” problem, where a datagram’s loss probability increases exponentially with fragment count. Finally, an application can prioritize its streams relative to each other and adjust priorities dynamically through out-of-band signaling. A user-space prototype shows that SST is TCP-friendly to within 2%, and performs comparably to a user-space TCP and to within 10 % of kernel TCP on a WiFi network.

Absfract- We performed end-to-end measurements of UDPm flows across an Internet backbone network. Using this data, we characterized the packet reordering processes seen in the network. Our results demonstrate the high prevalence of packet reordering relative to packet loss, and show a strong correlation between packet rate and reordering on the network we studied. We conclude that, given the increased parallelism in modern networks and the demands of high performance applications, new application and protocol designs should treat packet reordering on an equal footing to packet loss, and must be robust and resilient to both in order to achieve high performance. I.

We study limitations of an equation-based congestion control protocol, called TFRC (TCP Friendly Rate Control). It examines how the three main factors that determine TFRC throughput, namely, the TCP friendly equation, loss event rate estimation and delay estimation, can influence the longterm throughput imbalance between TFRC and TCP. Especially, we show that different sending rates of competing flows cause these flows to experience different loss event rates. There are several fundamental reasons why TFRC and TCP flows have different average sending rates, from the first place. Earlier work shows that the convexity of the TCP friendly equation used in TFRC causes the sending rate difference. We report two additional reasons in this paper: (1) the convexity of 1/x where x is a loss event period and (2) different RTO (retransmission timeout period) estimations of TCP and TFRC. These factors can be the reasons for TCP and TFRC to experience initially different sending rates. But we find that the loss event rate difference due to the differing sending rates greatly amplifies the initial throughput difference; in some extreme cases, TFRC uses around 20 times more, or sometimes 10 times less, bandwidth than TCP.

Current Internet transports conflate transport semantics with endpoint addressing and flow regulation, creating roadblocks to Internet evolution that we propose to address with a new layering model. Factoring endpoint addressing (port numbers) into a separate Endpoint Layer permits incremental rollout of new or improved transports at OS or application level, enables transport-oblivious firewall/NAT traversal, improves transport negotiation efficiency, and simplifies endpoint address space administration. Factoring congestion control into a separate Flow Layer cleanly enables in-path performance optimizations such as on satellite or wireless links, permits incremental rollout of new congestion control schemes within administrative domains, frees congestion control evolution from the yoke of “TCP-friendliness, ” and facilitates multihoming and multipath communication. Though this architecture is ambitious, existing protocols can act as starting points for the new layers— UDP or UDP-Lite for the Endpoint Layer, and Congestion Manager or DCCP for the Flow Layer—providing both immediate deployability and a sound basis for long-term evolution. 1.

DHash is a new system that harnesses the storage and network resources of computers distributed across the Internet by providing a wide-area storage service, DHash. DHash frees applications from re-implementing mechanisms common to any system that stores data on a collection of machines: it maintains a mapping of objects to servers, replicates data for durability, and balances load across participating servers. Applications access data stored in DHash through a familiar hash-table interface: put stores data in the system under a key; get retrieves the data. DHash has proven useful to a number of application builders and has been used to build a content-distribution system [34], a Usenet replacement [118], and new Internet naming architectures [133, 132]. These applications demand low-latency, high-throughput access

During the last decade, two big efforts on Internet quality of service were made. The first, IntServ, promises precise per-flow service provisioning but never really made it as a commercial end-user product, which was mainly accredited to its lack of scalability. Its successor, DiffServ, is more scalable at the cost of coarser service granularity --- which may be the reason why it is not yet commercially available to end users either. This leaves us with the question: is there a fundamental trade-off between QoS and scalability? A trade-off that, in the long run, could prevent deployment of QoS for end users altogether? Scalability and Quality of Service: A Trade-off? my colleague and me grows linearly with the number of questions we have to answer. Since RSVP typically sets up per-flow state, it is said to not scale well.

This paper argues a new relevance for an old idea: decomposing transport protocols into a set of resuable building blocks that can be recomposed in different ways depending on application requirements. We conjecture that point-to-point applications may well be adequately served by the existing suite of monolithic protocol implementations, but widely-distributed peer-to-peer systems such as overlays are not: the design space of transport protocols between nodes in a large, highly coordinated system is much larger. We provide several examples of existing systems that have implemented a diverse range of transport protocols, and show how a building-block approach covers these systems well, enabling simple specification of hybrids and variants of the protocols. In particular, we show how all of our examples can be implemented in the networking stack of P2, a multipurpose system for building overlay networks from declarative specifications. 1