The latency continuum and the birth of the fog

Picture an autonomous car with three very different jobs. First, it must detect an obstacle and brake, and that answer has to arrive within milliseconds. Second, it wants a good route, which means combining traffic reports from many cars in the same region. Third, its driving model must improve over time, and that means training on months of history from the whole fleet. No single computer suits all three. The obstacle check belongs right next to the sensors. Route optimization belongs somewhere that sees the whole region. Training belongs where there is enormous storage and compute. The three places sit at small, medium and large distance from the car.

The lecture turns that intuition into a definition. The Edge-to-cloud (E2C) continuum is a continuum of latencies between a client and a server. The Edge layer, the Fog layer and the Cloud layer are not separate worlds. They are regions of one range, ordered by how long a request takes to reach them and come back. Moving away from the client adds latency, and in exchange it adds capacity: more processors, more storage, a wider view of the data.

The floor that distance sets

Glass has a refractive index of about 1.4 to 1.6 (typically around 1.5), so light in fiber moves at roughly 200,000 km/s. Applied to the continuum, that floor reads:

To try your own distances and media, use the latency calculator in Lecture 01 part 07, which also explains why real round trips cost several times this bound.

A multiplayer game hosted in a distant cloud region lags: every shot travels thousands of kilometres and back. The obvious fix is to move the cloud next to the players. The lecture's answer is a flat no, and the reason is worth understanding, because it shapes everything that follows.

A cloud data center is a very complex system, it is very expensive, and it is centralized on purpose. Building one is, in the words of the Berkeley "Above the Clouds" report, a hundred-million-dollar undertaking. The payoff of that size is Economies of scale: a very large data center buys network bandwidth, storage and administration at a fraction of the unit cost a medium one pays. Satyanarayanan puts it the same way: centralization exploits economies of scale to lower the marginal cost of system administration and operations. Split one giant site into a thousand neighborhood sites and you throw that advantage away.

So the cloud stays where it is, and something smaller goes out instead. The lecture calls it a mini cloud, or Mini data center, and the key move is that you can place several of them at different points on the latency continuum. Each one is close enough to cut latency for nearby clients, while the big data center keeps its economics.

The pattern in production: Netflix Open Connect

A Content delivery network (CDN) is the clearest working example. Netflix started its Open Connect program in 2011. It places its own caching appliances (Open Connect Appliances, OCAs) at internet exchange points and, free of charge, inside the networks of qualifying ISPs; it now works with more than a thousand ISP partners. The ISP provides power, space and connectivity. Because Netflix can predict what its members will watch, it pre-fills each appliance during off-peak "fill windows", so at peak time the popular titles are already a few hops from the viewer.

In a smart city, small computers sit in cabinets at road junctions. Each one reads the cameras and sensors at its junction, notices a queue building or a pedestrian waiting, and changes the signal timing in real time, with no round trip to a distant cloud. Bonomi and colleagues at Cisco used almost the same example when they introduced the idea in 2012: a smart traffic light node that reads local sensors detecting pedestrians and bikers.

The layer of such mini data centers gets a name: the fog. A Mini data center is a scaled-down version of a big data center that bridges the gap between the edge and the cloud, and it offers all three classic services: compute, storage and networking. Bonomi defined fog computing as "a highly virtualized platform that provides compute, storage, and networking services between end devices and traditional Cloud Computing Data Centers." The name is a joke with a point: the fog is a cloud close to the ground.

Bonomi listed what makes the fog distinct from the cloud above it:

• Low latency and location awareness: a node knows where it is and serves who is near.
• Wide-spread geographic distribution and a very large number of nodes.
• Support for mobility, wireless access and real-time streaming.
• Heterogeneity: nodes come in many shapes and from many vendors.

The fog is also hierarchical. Nodes form tiers, and in Bonomi's words, "the higher the tier, the wider the geographical coverage, and the longer the time scale." The lowest tier runs control loops in milliseconds to sub-seconds; higher tiers work over seconds to minutes and even days, and the cloud keeps data for months and years. NIST SP 500-325 later made the building blocks concrete: fog nodes can be physical (gateways, switches, routers, servers) or virtual (virtualized switches, virtual machines, cloudlets). It also names mist computing, a lightweight and optional form of fog at the very edge. In 2018 IEEE adopted the OpenFog Reference Architecture as standard IEEE 1934-2018, a sign that the idea had moved from paper to practice.

Consider a fleet of autonomous delivery drones. When one drone's battery runs low it must return to base. That decision uses nothing but the drone's own state, and it must work even if every radio link is down, so it runs on the drone's own compute with no networking at all. When several drones fly in the same area, they must agree on flight paths to avoid collisions. Now the data spans several parties in one region, so the drones talk to a fog ground station, and networking is essential. Finally, the cloud combines data from every drone in the fleet to improve routes over time. That function's scope is global.

The lecture asks a sharp question: do we really need the networking service at every point on the latency continuum? The drone example answers it. Whether a function needs networking depends on its scope, meaning how many parties and how much area its data spans, not on whether the layer is called edge, fog or cloud. Walking from the cloud toward the device (the numbered points 1, 2 and 3 on the slides), more functions can run locally and depend less on remote communication, because the functions that live there have narrower scope.

Here the device itself plays the edge role, the NIST usage flagged in concept 1.

Research supports the same rule. Satyanarayanan shows that analyzing raw video on a nearby cloudlet means only the "(much smaller) extracted information and metadata must be transmitted to the cloud", and the cloudlet can enforce privacy policies before anything leaves. Bonomi's lowest fog tier runs machine-to-machine control loops in milliseconds and filters data before passing it up. In both cases, local functions stay local, and only results with wider scope travel.

Take the drone tasks one last time and map them onto networks. Local work runs on the edge, on the device or inside its local area network. Collision coordination runs in the fog, across a wide area network run by an operator. Fleet-wide learning runs in the cloud, reached over the public Internet. That mapping is the lecture's summary picture, and it is the one to memorize.

The edge lives on the LAN and offers compute and storage. The fog lives on the WAN and offers compute, storage and networking. The cloud lives on the Internet and is the full data center, offering every service at global scale. Each has a priority: edge prioritizes autonomy, fog prioritizes coordination, and cloud prioritizes global connectivity. Read together with the scope rule, this is the whole Edge-to-cloud (E2C) continuum in one table.

Where does an edge layer meet the fog? Through an Edge gateway, a device that does local processing for the edge devices behind it and connects them upward to fog nodes. The edge box omits networking because the functions placed there have device-local scope, as slides 7 and 8 argued; the gateway's uplink gives the edge connectivity, but the edge offers no networking service to others.