In October of '86, the Internet had the first of what became a series of 'congestion collapses'. During this period, the data throughput from LBL to UC Berkeley (sites separated by 400 yards and three IMP hops) dropped from 32 Kbps to 40 bps. Mike Karels1 and I were fascinated by this sudden factor-of-thousand drop in bandwidth and embarked on an investigation of why things had gotten so bad. We wondered, in particular, if the 4.3BSD (Berkeley UNIX) TCP was mis-behaving or if it could be tuned to work better under abysmal network conditions. The answer to both of these questions was “yes”.Since that time, we have put seven new algorithms into the 4BSD TCP: round-trip-time variance estimationexponential retransmit timer backoffslow-startmore aggressive receiver ack policydynamic window sizing on congestionKarn's clamped retransmit backofffast retransmit Our measurements and the reports of beta testers suggest that the final product is fairly good at dealing with congested conditions on the Internet.This paper is a brief description of (i) - (v) and the rationale behind them. (vi) is an algorithm recently developed by Phil Karn of Bell Communications Research, described in [KP87]. (viii) is described in a soon-to-be-published RFC.Algorithms (i) - (v) spring from one observation: The flow on a TCP connection (or ISO TP-4 or Xerox NS SPP connection) should obey a 'conservation of packets' principle. And, if this principle were obeyed, congestion collapse would become the exception rather than the rule. Thus congestion control involves finding places that violate conservation and fixing them.By 'conservation of packets' I mean that for a connection 'in equilibrium', i.e., running stably with a full window of data in transit, the packet flow is what a physicist would call 'conservative': A new packet isn't put into the network until an old packet leaves. The physics of flow predicts that systems with this property should be robust in the face of congestion. Observation of the Internet suggests that it was not particularly robust. Why the discrepancy?There are only three ways for packet conservation to fail: The connection doesn't get to equilibrium, orA sender injects a new packet before an old packet has exited, orThe equilibrium can't be reached because of resource limits along the path. In the following sections, we treat each of these in turn.

/pdf/congestion-avoidance-and-control-5b0pxljiwg.pdf

Congestion avoidance and control

Despite the apparent randomness of the Internet, we discover some surprisingly simple power-laws of the Internet topology. These power-laws hold for three snapshots of the Internet, between November 1997 and December 1998, despite a 45% growth of its size during that period. We show that our power-laws fit the real data very well resulting in correlation coefficients of 96% or higher.Our observations provide a novel perspective of the structure of the Internet. The power-laws describe concisely skewed distributions of graph properties such as the node outdegree. In addition, these power-laws can be used to estimate important parameters such as the average neighborhood size, and facilitate the design and the performance analysis of protocols. Furthermore, we can use them to generate and select realistic topologies for simulation purposes.

/pdf/on-power-law-relationships-of-the-internet-topology-19fp34v7ee.pdf

On power-law relationships of the Internet topology

The Internet has led to the creation of a digital society, where (almost) everything is connected and is accessible from anywhere. However, despite their widespread adoption, traditional IP networks are complex and very hard to manage. It is both difficult to configure the network according to predefined policies, and to reconfigure it to respond to faults, load, and changes. To make matters even more difficult, current networks are also vertically integrated: the control and data planes are bundled together. Software-defined networking (SDN) is an emerging paradigm that promises to change this state of affairs, by breaking vertical integration, separating the network's control logic from the underlying routers and switches, promoting (logical) centralization of network control, and introducing the ability to program the network. The separation of concerns, introduced between the definition of network policies, their implementation in switching hardware, and the forwarding of traffic, is key to the desired flexibility: by breaking the network control problem into tractable pieces, SDN makes it easier to create and introduce new abstractions in networking, simplifying network management and facilitating network evolution. In this paper, we present a comprehensive survey on SDN. We start by introducing the motivation for SDN, explain its main concepts and how it differs from traditional networking, its roots, and the standardization activities regarding this novel paradigm. Next, we present the key building blocks of an SDN infrastructure using a bottom-up, layered approach. We provide an in-depth analysis of the hardware infrastructure, southbound and northbound application programming interfaces (APIs), network virtualization layers, network operating systems (SDN controllers), network programming languages, and network applications. We also look at cross-layer problems such as debugging and troubleshooting. In an effort to anticipate the future evolution of this new paradigm, we discuss the main ongoing research efforts and challenges of SDN. In particular, we address the design of switches and control platforms—with a focus on aspects such as resiliency, scalability, performance, security, and dependability—as well as new opportunities for carrier transport networks and cloud providers. Last but not least, we analyze the position of SDN as a key enabler of a software-defined environment.

https://publications.uni.lu/bitstream/10993/20596/1/survey_on_SDN.pdf

Software-Defined Networking: A Comprehensive Survey

This paper describes a new replication algorithm that is able to tolerate Byzantine faults. We believe that Byzantinefault-tolerant algorithms will be increasingly important in the future because malicious attacks and software errors are increasingly common and can cause faulty nodes to exhibit arbitrary behavior. Whereas previous algorithms assumed a synchronous system or were too slow to be used in practice, the algorithm described in this paper is practical: it works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude. We implemented a Byzantine-fault-tolerant NFS service using our algorithm and measured its performance. The results show that our service is only 3% slower than a standard unreplicated NFS.

/pdf/practical-byzantine-fault-tolerance-58gb0de0hd.pdf

Practical Byzantine fault tolerance

This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation.

Integrated Services in the Internet Architecture: an Overview

Checksum and cyclic redundancy check (CRC) algorithms have historically been studied under the assumption that the data fed to the algorithms was uniformly distributed This paper examines the behavior of checksums and CRCs over real data from various UNIX file systems We show that, when given real data in small to modest pieces (eg, 48 bytes), all the checksum algorithms have skewed distributions These results have implications for CRCs and checksums when applied to real data They also can cause a spectacular failure rate for both the TCP and ones-complement Fletcher (1983) checksums when trying to detect certain types of packet splices When measured over several large file systems, the 16 bit TCP checksum performed about as well as a 10-bit CRC We show that for fragmentation-and-reassembly error models, the checksum contribution of each fragment are, in effect, colored by the fragment's offset in the splice This coloring explains the performance of Fletcher's sum on nonuniform data, and shows that placing checksum fields in a packet trailer is theoretically no worse than a header checksum field In practice, the TCP trailer sums outperform even Fletcher header sums

Performance of checksums and CRC's over real data

Checksum and CRC algorithms have historically been studied under the assumption that the data fed to the algorithms was entirely random. This paper examines the behavior of checksums and CRCs over real data from various UNIX® file systems. We show that, when given real data in small to modest pieces (e.g., 48 bytes), all the checksum algorithms have skewed distributions. In one dramatic case, 0.01% of the check values appeared nearly 19% of the time. These results have implications for CRCs and checksums when applied to real data. They also cause a spectacular failure rate for the both TCP and Fletcher's checksums when trying to detect certain types of packet splices.

/pdf/performance-of-checksums-and-crcs-over-real-data-58oky8ve5t.pdf

Performance of checksums and CRCs over real data

Experts have long recognized that theoretically it was possible to perform traffic analysis on encrypted packet streams by analyzing the timing of packet arrivals (or transmissions). We report on experiments to realize this possiblity using basic signal processing techniques taken from acoustics to perform traffic analysis on encrypted transmissions over wireless networks. While the work discussed here is preliminary, we are able to demonstrate two very interesting results. First, we can extract timing information, such as round-trip times of TCP connections, from traces of aggregated data traffic. Second, we can determine how data is routed through a network using coherence analysis. These results show that signal processing techniques may prove to be valuable network analysis tools in the future.

Using signal processing to analyze wireless data traffic

The most important consideration is how the collection of measurements may affect a person's well-being.

https://dl.acm.org/doi/pdf/10.1145/2896816

Ethical considerations in network measurement papers

We consider the concept of opportunistic spectrum access (OSA) -- whereby radios identify unused portions of licensed spectrum, and utilize that spectrum without adverse impact on the primary licensees. OSA allows both dramatically higher spectrum utilization and near-zero deployment time, with an obvious and significant impact on both civilian and military communications. We discuss two broad classes of challenges to OSA: spectrum agility, which involves wideband sensing, opportunity identification, coordination and use; and policy agility, which enables regulatory policies to be applied dynamically using machine understandable policies. Focusing on spectrum agility, we present an architecture based on an OSA adaptation layer. We describe protocols for OSA, including a hole information protocol, idle channel selection and use, and an access protocol for the coordination channel. We present a simulation study, discuss insights, and show that even a simple protocol for opportunistic spectrum allocation can provide an order-of-magnitude performance improvement in throughput over a legacy system.

Craig Partridge

Papers

Performance of checksums and CRC's over real data

Performance of checksums and CRCs over real data

Using signal processing to analyze wireless data traffic

Ethical considerations in network measurement papers

Opportunistic spectrum access: challenges, architecture, protocols