This paper describes a technique for tracing anonymous packet flooding attacks in the Internet back towards their source. This work is motivated by the increased frequency and sophistication of denial-of-service attacks and by the difficulty in tracing packets with incorrect, or “spoofed”, source addresses. In this paper we describe a general purpose traceback mechanism based on probabilistic packet marking in the network. Our approach allows a victim to identify the network path(s) traversed by attack traffic without requiring interactive operational support from Internet Service Providers (ISPs). Moreover, this traceback can be performed “post-mortem ” – after an attack has completed. We present an implementation of this technology that is incrementally deployable, (mostly) backwards compatible and can be efficiently implemented using conventional technology. 1.

Abstract not found

As a reliable, end-to-end transport protocol, the Transmission Control Protocol (TCP) uses positive acknowledgements and retransmission to guarantee delivery. TCP implementations are expected to measure and adapt to changing round-trip delay so that their retransmission behavior balances user throughput and network efficiency. However, TCP suffers from a problem we call retransmission ambiguzty: when an acknowledgement arrives for a datagram that has been retransmitted, there is no indication of which transmission is being acknowledged. As a result, an implementation maybe unable to determine if the round-trip time it measures is for an original transmission or a retransmission of a datagram. Many existing TCP implementa-tions do not handle this problem correctly. Furthermore, the problem of retransmission ambigu-ity is also a characteristic of other major transport protocols, including 0S1 TP4 and DECnet NSP This paper reviews the various approaches to retransmission and presents a novel and effective approach to the retransmission ambiguity problem. Categories and Subject Descriptors: C 20 [Computer Communications Networks]: General—open System Interconnection reference model (0S1); C.2. 1 [Computer Communications Networks]: Network Architecture and Design—packet networks, store and forward net-works; D.4.4 [Operating Systems]: Communications Management — message sending, network communication

We describe tcpanaly, a tool for automatically analyzing a TCP implementation's behavior by inspecting packet traces of the TCP's activity. Doing so requires surmounting a number of hurdles, including detecting packet filter measurement errors, coping with ambiguities due to the distance between the measurement point and the TCP, and accommodating a surprisingly large range of behavior among different TCP implementations. We discuss why our efforts to develop a fully general tool failed, and detail a number of significant differences among 8 major TCP implementations, some of which, if ubiquitous, would devastate Internet performance. The most problematic TCPs were all independently written, suggesting that correct TCP implementation is fraught with difficulty. Consequently, it behooves the Internet community to develop testing programs and reference implementations. 1 Introduction There can be a world of difference between the behavior we expect of a transport protocol, and what we g...

AbstractÐWe study the quality of service �QoS) of failure detectors. By QoS, we mean a specification that quantifies 1) how fast the failure detector detects actual failures and 2) how well it avoids false detections. We first propose a set of QoS metrics to specify failure detectors for systems with probabilistic behaviors, i.e., for systems where message delays and message losses follow some probability distributions. We then give a new failure detector algorithm and analyze its QoS in terms of the proposed metrics. We show that, among a large class of failure detectors, the new algorithm is optimal with respect to some of these QoS metrics. Given a set of failure detector QoS requirements, we show how to compute the parameters of our algorithm so that it satisfies these requirements and we show how this can be done even if the probabilistic behavior of the system is not known. We then present some simulation results that show that the new failure detector algorithm provides a better QoS than an algorithm that is commonly used in practice. Finally, we suggest some ways to make our failure detector adaptive to changes in the probabilistic behavior of the network. Index TermsÐFailure detectors, quality of service, fault tolerance, distributed algorithm, probabilistic analysis. 1

This paper is a draft that will appear in IEEE/ACM Transactions on Networking. Final editing is still expected. Please replace it with the final version when published.

Current TCP protocols have lower throughput performance in satellite networks mainly due to the effects of long propagation delays and high link error rates. In this paper, a new congestion control scheme called TCP-Peach is introduced for satellite networks. TCP-Peach is composed of two new algorithms, namely Sudden Start and Rapid Recovery, as well as the two traditional TCP algorithms, Congestion Avoidance and Fast Retransmit. The new algorithms are based on the novel concept of using dummy segments to probe the availability of network resources without carrying any new information to the sender. Dummy segments are treated as low-priority segments and accordingly they do not effect the delivery of actual data traffic. Simulation experiments show that TCP-Peach outperforms other TCP schemes for satellite networks in terms of goodput. It also provides a fair share of network resources.

Abstract not found

This paper presents a practical solution to a problem facing high-fan-in, high-bandwidth synchronized TCP workloads in datacenter Ethernets—the TCP incast problem. In these networks, receivers can experience a drastic reduction in application throughput when simultaneously requesting data from many servers using TCP. Inbound data overfills small switch buffers, leading to TCP timeouts lasting hundreds of milliseconds. For many datacenter workloads that have a barrier synchronization requirement (e.g., filesystem reads and parallel data-intensive queries), throughput is reduced by up to 90%. For latency-sensitive applications, TCP timeouts in the datacenter impose delays of hundreds of milliseconds in networks with round-trip-times in microseconds. Our practical solution uses high-resolution timers to enable microsecond-granularity TCP timeouts. We demonstrate that this technique is effective in avoiding TCP incast collapse in simulation and in real-world experiments. We show that eliminating the minimum retransmission timeout bound is safe for all environments, including the wide-area.

It would be ideal if a host implementation of the Internet protocol suite could be entirely self-configuring. This would allow the whole suite to be implemented in ROM or cast into silicon, it would simplify diskless workstations, and it would be an immense boon to harried LAN administrators as well as system vendors. We have not reached this ideal; in fact, we are not even close. —RFC 1122 1 IP hosts and network infrastructure have historically been difficult to configure—requiring network services and relying on highly trained network administrators—but emerging networking protocols promise to enable hosts to establish IP networks without prior configuration or network services. Even very simple devices with few computing