On synchronicity (and the desirability of not having it, sometimes)

Recently a colleague at work pointed me towards this blog post on synchronization in nature and physics. It is a charming and light-hearted reminder of the frequent alignment of systems — both natural and otherwise. It describes how events that look to be entirely discrete and unconnected can organize into a sequence, a set, or even an almost completely lock-stepped rhythm.

In the natural world, there are many examples, such as the synchronized release of wildlife eggs on the Great Barrier Reef triggered by the tide, moon, and climate. Or the flowering of the cherry blossom across Japan, or the jacaranda blooms in the southern hemisphere.

But outside of the ‘natural world’ in the domain of physics, there are also forms of synchronicity. For example, the tendency of planetary systems to fall into stable orbits with predictable cycle times, or the alignment of mutually suspended pendulums. As the blog post observes, seemingly ‘weak’ couplings can be sufficient triggers to bring otherwise chaotic systems into strong alignment.

How does this relate to the Internet?

The connection to the Internet is twofold. One is a more whimsical relationship borne of the mind of Alan Turing. The other is an incident in Internet history — back in 1985 and relating to the Berkeley Standard Distribution (BSD) UNIX system implementation of TCP/IP.

Alan Turing and synchronicity

In the early 1950s during troubled times, Turing found himself cut off from his core work in computing and cryptography due to losing his security clearance. His mind had turned to other subjects and he had become fascinated by the emerging science of morphogenesis  — how patterns emerge in chemical, and ultimately biological, systems. The paper (PDF) he wrote in 1952 laid the foundations for a new field of understanding in development and biological systems.

When different states of matter react, the boundary between states can generate evolving patterns that change over time. These patterns can become complex, self-sustaining, and shift into new arrangements. His ideas now form the basis of models that describe how organs, such as the brain, develop from simple and local interactions.

While there may not be a direct connection between morphogenesis and the Internet, broad analogies can be made. Just as morphogenesis involves the interplay of various components to generate complex forms, the current Internet can be seen as a complex system that has emerged from the interactions of numerous interconnected devices, protocols, and data.

Van Jacobsen’s story is more deeply related to how the Internet works, or in this case, how it nearly stopped working.

Van Jacobsen and the synchronized protocols

Van Jacobsen is a computer scientist who spent much of his career working on the Internet Protocol suite in the BSD version of UNIX. His work has spanned applications (shared whiteboards, text editors, multicast audio, and video) as well as lower-layer protocol design. Jacobsen’s work in TCP/IP, particularly buffer exhaustion and its effect on congestion control, is relevant to this topic.

In this wired article, Jacobsen disclaims being the guy who rescued the Internet from meltdown, but what he did do is recognize a basic emergent behaviour in the routing framework of the 80s — the Internet Message Processor (IMP) nodes that formed the backbone of the Internet of the time.

These nodes were coded to implement TCP/IP packet forwarding. In this model, a TCP ‘session’ is meant to have an idea of ‘packets in flight’, which are the packets of TCP data (encoded in IP) that are yet to be acknowledged.

There’s a ‘window’ of unacknowledged data. If this window is exceeded, sending must stop. That window isn’t set at a fixed point. It’s called a ‘sliding window’ and the size of the gap in the open window can be set to bigger or smaller. This is how TCP adapts itself to the available bandwidth — if there’s apparently lots of bandwidth, the window opens wider and more packets ‘in flight’ can be unacknowledged. If there is less, or some got lost, the window closes to some degree and must open again once data is seen to succeed in getting through. Each TCP session is independent with its own window and its own idea of what bandwidth is needed, and whether it has an open window or a closed window.

But IMP was coded too simply for all of this. If there was a problem on the shared path out from the IMP to the wider Internet, all TCP sessions behind that IMP wound up sitting behind the same red light, waiting to open their window. And because they all shared the same model of how to open up at that time, they self-synchronized in an attempt to consume all the available bandwidth. As a result, the IMP re-synchronized all the TCP sessions behind it into one pulsed behaviour.

Van Jacobsen and Mike Karels of the UC Berkeley Computer Systems Research Group worked through a series of algorithm changes to the basic TCP window protocol, to come up with a stunningly simple change, adding one variable and (it is said) three lines of code, which converted the model into one that was more graceful in how it approached opening up the window.

But this isn’t the only time Van Jacobsen has worked on synchronized events in the Internet. In 1994, along with Sally Floyd in a paper titled ‘The Synchronization of Periodic Routing Messages‘ they noted the manifold ways that Internet Protocols can self-organize into synchronized states, and proposed the introduction of small but useful amounts of randomness in timing, to ensure these synchronized states de-cohered.

Sometimes, what you want is less synchronicity

Exposing the protocol stack to a random delay, derived from a small number of random states in the BSD UNIX kernel, combined with that simple change to TCP window packet loss, is credited with enabling the 1980s Internet to grow into the worldwide behemoth it is today. Additionally, it allowed the post-1995 Internet to avoid the synchronicity that emerges in a system without direction.

Van Jacobsen might disagree, but by recognizing a self-organizing principle in how otherwise unconnected things coalesce into a single-phased pulse of activity, he applied much the same mathematical approaches to problem-solving that Turing might have, given the same problem.

With thanks to Siena Perry for the pointer to the original article.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.