Skip to content
TrackPodcasts
historyMar 17, 202622:25

The mechanics of delay tolerant networking

pplpod

About this episode

Delay-Tolerant Networking: The Internet That Works When the Internet Doesn't

Episode Summary

The internet you use every day is built on a comforting illusion: a continuous, unbroken path from sender to receiver, confirmed by a rapid-fire handshake before a single byte flows. But in deep space, disaster zones, or remote wilderness — anywhere that continuous path doesn't exist — standard routing protocols like AODV and DSR simply refuse to function, dropping your data and throwing an error. Delay-tolerant networking, or DTN, was born from the collision of two research tracks: 1970s mobile ad-hoc networking experiments that evolved into 1990s wireless MANETs, and a DARPA-funded Interplanetary Internet project where Vint Cerf himself — co-architect of the terrestrial internet — realized his own invention was useless across the 20-minute light-speed delays to Mars. In 2002, researcher Kevin Fall bridged these worlds by recognizing that a hurricane zone on Earth presents the same fundamental communication problem as deep space, coining the term "delay-tolerant networking" and adapting interplanetary protocols for terrestrial use.

The core mechanic is called store-and-forward: instead of demanding an end-to-end path, each node stores data locally and waits — hours, days, or weeks — until it encounters another node closer to the destination, then hands the data off like a relay runner. Routing strategies range from brute-force epidemic routing, where every node blindly copies and spreads data like a digital virus relying on statistical probability, to intelligent algorithms where resource-constrained nodes evaluate trajectory and battery life before choosing whom to forward to. The data itself travels as self-contained "bundles" under the Bundle Protocol (now at version 7, with RFC 9713 published in January 2025), carrying destination, security credentials, lifespan, and priority class — bulk, normal, or expedited — so the receiving application can process it without ever contacting the sender. Bundles are addressed not by fixed IP addresses but by Endpoint Identifiers that follow the application regardless of physical location. Security in a network where real-time handshakes are impossible relies on ingenious solutions like cryptographic gossiping protocols, where nodes exchange tamper-proof logs of their interactions and collectively identify black hole attackers through decentralized mathematical reputation.

Topics Covered

  • Why standard internet routing fails: the end-to-end handshake illusion and its catastrophic breakdown in extreme environments
  • Origins from 1970s mobile ad-hoc networks, Vint Cerf's Interplanetary Internet project, and Kevin Fall's 2002 terrestrial bridge
  • Store-and-forward mechanics: epidemic routing vs. intelligent forwarding, and the Bundle Protocol's self-contained survival kits
  • Security without handshakes: flutter attacks, black hole attacks, and the cryptographic gossiping reputation system
  • Space implementations: NASA's ION, the ISS, deep-space testing at 20 million miles, and astronaut-controlled rovers from orbit
  • Terrestrial applications: ZebraNet wildlife tracking, military tactical networks, vehicular relays, and motorcycle data couriers

Source credit: Research for this episode included Wikipedia articles accessed 3/17/2026. Wikipedia text is licensed under CC BY-SA 4.0; content here is summarized/adapted in original wording for commentary and educational use.

Get every episode summarized

Each time pplpod publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.

Email me new episodes

Free for 3 shows. No card needed.

Transcript ready

505 searchable segments. Every word is indexed and playable.

The mechanics of delay tolerant networking

pplpod

0:00
22:25

Full transcript

pplpodThe mechanics of delay tolerant networking. Machine-transcribed; use the interactive transcript above to jump the player to any line.

You're listening to a podcast right now, driving, working out, walking the dog. If you're into podcasts, chances are you have something to say too. With RSS.com, starting your own is free and easy. Upload an episode, and we distribute it to Apple podcasts, Spotify, Amazon Music, and hundreds more. Track your listeners, see where they're from, and start earning from ads like this. Even with just 10 listeners a month. If you've been thinking about starting a podcast, this is your sign. Start free at RSS.com. You know that feeling when you're trying to load a web page on your phone and you step into an elevator or just hit a dead zone. Oh, yeah, the spinning wheel of doom. Exactly. The spinning wheel of doom, you just stare at it completely paralyzed until your phone manages to, I don't know, scrape together a signal again. We are so incredibly used to the internet just being this instant, always on utility. Right. But what happens when you need to send a really crucial piece of data and that dead zone

isn't just a concrete tunnel on your commute, but like millions of miles of freezing deep space. Or disaster zone on Earth. Yeah. Where the entire physical infrastructure, the cell towers, the fiber optics, it's all been completely wiped off the map. Yeah. That's exactly our mission for today's deep dive. We are going to uncover how communication actually functions when the traditional internet completely breaks down. It's a fascinating topic. It really is. We're going to explore the mechanics of something called delay tolerant networking. Or DTN for short. Today's source is a really comprehensive Wikipedia article on delay tolerant networking, which goes deep into its history, its technical architecture, and some genuinely mind blowing real world implementations. Yeah. It forces us to completely shatter our fundamental assumptions about how communication is supposed to work. How so? Well, standard internet routing relies on a very comforting, very strict illusion. It's the expectation of a continuous, unbroken path from the sender all the way to the receiver.

Like a physical wire or a clean radio signal. Exactly. But in extreme environments, whether that's the bottom of the ocean or the surface of Mars, that continuous path simply does not exist. So why exactly does the normal internet fail so spectacularly when things get a little rough out there? To understand the failure, we really have to look at the mechanical rules that govern standard routing. Right. The protocols. Yeah. Traditional routing protocols. You might see them referred to in the source by technical names like AODV or DSR. And these protocols are, well, they're essentially an uncompromising perfectionist. Perfectionists. Yeah. Because before they forward a single bite of your actual email or web page, they demand to establish a complete end-to-end route. Oh, I see. So they won't even try unless the whole path is clear. Right. They want to shake hands with every single router along the path. The sender says, are you there? And the receiver has to immediately say, yes, I'm here. Only after that entire road is mapped out and confirmed open, does the actual data start flowing?

Okay. Let's unpack this. The routing is essentially like a highway system. If you're driving from New York to LA and there's a single bridge out somewhere in Colorado, standard routing says traffic stops entirely. Yep. You can't even start your road trip. But delay-tolerant networking, it flips that script completely. It seems much more like a relay race where a runner might have to, I don't know, camp out for three days in a tent waiting for the next runner to finally show up. That is a brilliant way to visualize it. And the origins of this relay race concept, they actually go back significantly further than the modern smartphone era. Really? How far back? All the way to the 1970s. As computers first started shrinking, researchers began tinkering with ad hoc routing for mobile computers. So even back then, they were thinking about mobility. Exactly. They were asking, you know, how do devices talk to each other if they're constantly moving around? If you fast forward to the 1990s, the explosion of wireless protocols really supercharged this research.

And that became known as mobile ad hoc networks, right? Or menettes? Yes, menettes. But those were still largely focused on earthbound mobility. Right. Because at the exact same time, we had DARPA funding NASA and the MITRE Corporation to build something that sounds, frankly, straight out of a sci-fi novel. The interplanetary internet. The IPN, which is the coolest name. It is. And that project brought in internet pioneer Vint Cerf. Oh, wow. The guy who basically helped invent the internet. Exactly. He famously helped design the original fundamental architecture of the terrestrial internet. But when he and his team looked at deep space communication, they realized their own invention was totally useless. Because of the distances involved? Yeah. In space, you are dealing with brutal physics dictated realities. I mean, if you want to talk to Mars, light speed delay means a simple, hello, can take up to 20 minutes just to get there. And another 20 minutes to get the response back. Exactly. So a standard internet handshake would just time out and fail instantly. Plus, you have a meant packet corruption from solar radiation out there.

So they needed a system that expected massive delays and broken links as the default state rather than an exception? Right. They built it specifically for spacecraft. But how did it get back down to earth? Because obviously, we use this here now. That happened around 2002, a researcher named Kevin Fall realized something crucial about what the space teams were building. He took these interplanetary ideas and adapted them for terrestrial networks. And he's the one who officially coined the term delay tolerant networking or DTN. Yes. He recognized that space isn't the only place where the internet breaks. Because if you're in a hurricane zone, you essentially have the exact same communication problem as a Mars rover. If we connect this to the bigger picture, disruption is literally everywhere. It happens because of the physical limits of wireless radio range. Sure. Like being too far from a router. Right. Or it happens when you have a sparse network of mobile nodes like rescue workers in a forest that rarely cross paths. It happens because of strict energy constraints on battery-powered sensors or malicious jamming

attacks or just overwhelming environmental noise. So the bridge out scenario is an incredibly common earth problem too. Very common. So we know the why. Traditional networks need a perfectly paved highway and in extreme environments, that highway is constantly crumbling. That brings us to the how. The mechanics of it. Yeah. How does DTN mechanically solve this problem without a continuous path? If the bridge is out, how does the data keep moving? The secret sauce is an approach called store and forward. Store and forward. Yeah. Instead of demanding an end-to-end path right this second, data is moved incrementally. Okay. Give me an example. Let's say you have a network of drones. Drone A receives a message intended for base camp, but base camp is currently out of range. So a normal network would just drop it? Exactly. A bravet and throw an error. But instead, drone A stores the data securely in its own local hard drive. It simply holds onto it, flying around, until it eventually encounters drone B, which happens to be moving closer to the final destination.

Oh, I see. It shifts the entire burden of success from the global network path down to the individual devices. They basically act as independent careers. Exactly like careers. But wait, if drone A meets drone B, how does it decide whether to actually hand over the data? Like, are there different strategies for how this relay races run? They're absolutely are. And the strategy you choose depends heavily on the physical resources of your network. What kind of resources? Well, storage space and bandwidth. If you are operating an environment where those are practically unlimited, you might use a strategy called epidemic routing. Epidemic routing. That sounds like a digital virus. How does that work in practice? It essentially functions exactly like one. In epidemic routing, the network deliberately infects itself with the data. Infects itself. Yeah. So when drone A meets drone B, it doesn't ask if drone B is even going the right way. It just blindly copies the message and hands it over. And then they both fly off and do the same thing to the next drone they meet. Exactly. Every single time any node encounters another node, it duplicates and passes the message.

The network creates hundreds or thousands of copies. Just relying on the sheer statistical probability that at least one of those copies will eventually bump into the final destination. That's the idea. Hold on. I have to push back on that. That sounds incredibly inefficient. If every single device is constantly duplicating and transmitting every piece of data it encounters, wouldn't they just instantly run out of storage? They absolutely would. Or worse, wouldn't their batteries die in like an hour from constantly blasting radio signals? You've hit on the exact flaw of epidemic routing. It is a brute force method. It works beautifully if you have plugged in high capacity machines. But not for tiny devices. Right. Absolutely right. If you're dealing with constrained resources like tiny solar-powered environmental sensors in a rainforest epidemic routing, we'll kill the network in an afternoon. So what do they do instead? In those cases, you cannot afford to flood the system. You have to use a much more discriminant, intelligent algorithm.

Making smarter choices about who gets the data. Exactly. The nodes evaluate their trajectory, their battery life, and their historical encounters, to choose exactly when and to whom they forward the data. They only pass the baton if they are mathematically confident the next runner is a better candidate. So to coordinate all of these complex relay handoffs across totally different types of networks, they needed a universal language. And that brings us to the bundle protocol. Yes, the core of DTN. The foundational rules were originally defined in documents called RFC4838 and 5050 back in 2007, which created an overlay network. But what does a bundle actually look like? Because standard internet data is chopped up into thousands of tiny fragile packets, right? And that fragility is exactly what they had to fix. On the normal internet, if one tiny packet out of a thousand drops, the receiver just pings the sender and says, hey, recent packet 402. And that happens in milliseconds. Exactly. But in a delay tolerant network, a round trip request for a dropped packet could take 12 hours.

The connection might be totally gone by that. So asking for a recent is basically impossible. Right. The protocol groups data into a large, continuous block. This bundle contains so much semantic information, the destination, the security credentials, the lifespan of the data, that the receiving application can process it entirely on its own. Wait, so instead of sending a letter one paragraph at a time and hoping the postman doesn't drop a page, a bundle is like sending an entirely self-contained survival kit. A perfectly organized, independent survival kit. It has everything the receiver needs to make sense of the data without ever needing to ask the sender for clarification. Exactly. And because standard IP addresses, like the ones your home router uses, rely on a fixed physical location, DTN just discards them completely. So how do they know where to go? These bundles are routed using endpoint identifiers or EIDs. It's a naming architecture that identifies the application or the service itself no matter where it physically moves. Oh, that's smart. And what's brilliantly clever about this survival kit is how it prioritizes itself.

The applications generating the data dictate the urgency using specific service classes. Like what? The main ones are bulk, normal or expedited. That makes total sense. If I'm a rover on Mars and I'm sending my routine daily soil analysis log, I can mark that bundle as bulk. The relay satellites can let it sit and storage for a week if they need to. Yep, no rush. But if I'm sending an alert that my primary solar panels are failing and I'm losing power, that bundle gets stamped expedited. And the network immediately knows to push that expedited bundle to the front of the line, ensuring critical data survives when resources are incredibly sparse. That's a lifesaver. Literally. And I should note, this isn't some forgotten 2007 experiment. The internet engineering task force, the group that maintains the backbone of the internet, is constantly evolving this. But they're still updating it. Oh, heavily. They recently transitioned the core specifications into bundle protocol version seven. They published major updates in 2022. And incredibly recently, just in January 2025, they published a new specification.

Wow. 2025. Yeah. RFC 9713 to refine how nodes discover each other is a very active living architecture. Okay. But as I'm picturing these self-contained survival kits, flooding around out there, hopping from drone to satellite to rover, I keep hitting a massive wall when it comes security. Ah, yes. Security is tough. It's not a relay node holding onto a bundle for three days. And I have absolutely no way to communicate back to the original center to verify passwords or credentials. What stops a malicious actor from just infiltrating the network and ruining everything? It is arguably one of the most difficult, complex challenges in all of DTN. If you think about standard internet security, it's completely reliant on continuous bidirectional communication. Right. Like, when you log into a website. Exactly. When you log into your bank, your browser and the bank server talk back and forth multiple times in milliseconds to agree on a secret cryptographic code. But in a fragmented network, that rapid fire handshake is physically impossible. Right.

And without that real time digital ID check, the network is incredibly vulnerable to bad actors acting as middlemen. If I'm handing my precious data to a random node I just met, it opens the door for some nasty attacks. Very nasty. I know from the source there are two major ones, the flutter and the black hole. A flutter makes sense. It's a robe node that just generates thousands of fake bundles to choke the network storage capacity. It just overwhelms the system. Right. But the black hole attack, that's much more insidious, isn't it? It's devastating. In a black hole attack, a malicious node joins the network and acts like a perfect citizen. It cheerfully accepts bundles of life saving data from other nodes. But it doesn't pass them on. Exactly. Instead of storing and forwarding them, it quietly deletes them. It acts as a data sink. Oh, wow. Does the original center doesn't expect a delivery receipt for days or weeks? The black hole can silently destroy massive amounts of information before anyone realizes there's a problem. That is terrifying. How do you fight that? I know researchers looked into adapting public key infrastructure, which is basically that

digital ID check we use for banking, but making it work without a central server is tough. It is incredibly difficult to decentralize that trust. I was looking at some of the unique solutions the DTN community came up with, like a identity-based encryption. But there's another method that relies on temper evident tables combined with a gossiping protocol. Yes, gossiping. Wait, gossiping. That sounds like a middle school rumor mill, not a high tech cryptography solution. How on earth does gossiping protect a network from a black hole attack? Well, this raises an important question. How do you build trust when no one can see the whole picture? And there is no central police force to monitor behavior. You talk to your neighbors. In a fragmented network, the nodes have to rely on sharing localized, tamper-proof rumors or reports about their interactions. When two nodes briefly cross paths, they don't just exchange bundles of data. What else do they exchange? They exchange cryptographic logs of their recent activities. That is the gossip.

Ah, let me see if I get this. It's literally like a digital high school. No day crosses paths with node B and passes a note that says, hey, I gave three critical bundles to node C yesterday. And according to the network gossip I've collected, node C never passed them on to anyone. You've got it perfectly. And because these gossip logs are cryptographically signed, node C can't alter them to cover its tracks. They're verifiable rumors. Exactly. As nodes move around and encounter each other, these rumors spread exponentially. Eventually, the collective mathematics of the network cross the threshold. And everyone realizes node C is the bad guy. Right. Enough nodes have swapped gossip about node C dropping data that the network collectively agrees node C is a black hole. From that moment on, every node simply refuses to hand data to node C. They just shun it. Yep, they route around it entirely. It is a reputation system built entirely on decentralized mathematical rumors. That is brilliant. It weaponizes the very nature of the relay race to spread the security updates.

Okay, so we've built the network. We've bundled the data into survival kits and we've secured it with digital gossip. We have a working DCN. Here's where it gets really interesting. Let's talk about where this is actually operating around us and above us right now. Because this is not just a theoretical lab experiment anymore. Not at all. There are multiple highly robust implementations of the bundle protocol operating right now. Let's look at space first. Okay, let's go to space. NASA maintains the interplanetary overlay network or IONN. It is a software implementation written in the C programming language. And it is specifically engineered to survive the incredibly strict safety rules of space flight computers. Safety rules like what? Well, for example, it uses zero dynamic memory allocation, which is a programming technique to guarantee the software never causes a memory leak that could crash the computer. Because you definitely do not want your flight computer freezing and asking for a reboot when it's halfway to Jupiter. Exactly. And IT guy up there to turn it off and on again, then you have another implementation

called D-T-N-M-E, which is currently operating right now on the International Space Station. Oh, they use it on the ISS. Yeah, supporting both older and newer versions of the bundle protocol. And NASA isn't stopping there. They've developed a newer library called BP-Lib-C, which is slated to fly on the upcoming pace mission. The pace mission. It's an incredibly advanced satellite designed to study Earth's oceans and atmosphere. And what's wild is how long they've been successfully testing this in orbit. Back in 2008, a project called Saratoga successfully tested the bundle protocol on a UK Earth observation satellite. Yeah, that was a huge milestone. That same year, NASA's Jet Propulsion Lab ran the Dynet experiment, sending bundles to the deep impact spacecraft over 20 million miles away. It's just staggering distance. The milestone from the source that absolutely blows my mind is from 2015. NASA and the European Space Agency used the experimental interplanetary internet to allow

an astronaut on the ISS to remote control a rover driving around down on Earth. That is wild. They were literally teleoperating a robot from space using delay-tolerant bundles to ensure the commands didn't get lost in transit. It's a stunning technical achievement. Controlling robots from orbit captures the imagination, but we also have to look at how this impacts us terrestrial. Right. Back down on Earth. What stands out to you when we compare those multi-million dollar deep space missions with the Earth-bound applications of DTN? Honestly. It's the sheer contrast in scale and environment. You go from the sterile high-tech environment of the International Space Station to, well, the Zebrnet project. Yes. Zebrnet is one of the most fascinating examples of terrestrial DTN. It uses energy-efficient, store-and-forward computing to track the movements and behaviors of wildlife. Because wild animals in Africa don't exactly stick to areas with reliable 5G coverage. Right. Exactly. So, researchers outfit the animals with specialized sensor callers. Let me guess.

Epidemic routing in the wild. Quite literally. Let's track a single zebra out in the Kenyan Savannah. Zebra 1 has a collar recording its heart rate, GPS location, and grazing habits. Okay. Tracking Zebra 1. Zebra 1 wanders over to a watering hole and bumps into Zebra 2. Their callers detect each other, and instantly they exchange their data bundles. So now Zebra 2 has both data sets. Now Zebra 2 is carrying both its own data and Zebra 1's data. They separate. Days go by. The bundles are passed from Zebra to Zebra across the entire herd. That is so cool. Eventually, any single zebra wanders close enough to a researches-based station or vehicle driving by. The moment that connection is made, the caller offloads the entire herd's data at once. It's just incredible. They turn the herd itself into a localized internet. They're really good. And it goes beyond wildlife. You have DARPA's WONAN project using it for tactical military communications. You have vehicular networks where cars traveling in opposite directions on a highway rapidly pass data bundles to each other to warn about traffic accidents miles ahead.

It's highly adaptable. And critically, you have university initiatives targeting developing remote regions, bringing a synchronous internet access to isolated villages that completely lack traditional telecom infrastructure. All the motorcycle careers. Yes. A motorcycle career drives through a village with a Wi-Fi hard drive, automatically absorbs all the outgoing emails and data requests from the local clinic, and physically drives them to a city with an internet uplink. It's such a brilliant practical application of the protocol. So what does this all mean for us? We started out looking at a technology designed to talk to probes at the edge of the solar system, and we ended up with a tool that can track endangered species and provide a lifeline to the most isolated places on Earth. It's an incredible journey. It really proves that DTN isn't just a niche tool for astronauts. It is the ultimate backup plan. It takes the greatest liability of a broken network, the sheer disconnection, and turns it into a resilient web. By relying on patient, self-contained bundles, the data actually survives.

And as we wrap up this deep dive, I want to leave you with a thought that builds on everything we've explored today. What's that? Well, if humanity eventually fulfills the sci-fi dream and becomes a multi-planetary species, establishing permanent colonies on Mars or mining outposts in the asteroid belt, DTN won't just be a backup plan for scientists. Right. It'll be everyday life. It'll have to become the primary absolute foundation of a true inter-solar internet. Imagine what human culture, streaming media, and global finance will look like when every single piece of data has to be bundled and tolerate light minutes or even light hours of delay. It's hard to even picture. How will our very concept of what the internet is have to evolve when instantaneous connection is literally forbidden by the laws of physics? That is a staggering thought. Are we going to be waking up to receive massive daily bundles of the internet, waiting for the morning data drop from Earth just to see the news or catch up on social media? We might have to. It completely changes what it means to be connected as a species. And it all starts with learning to tolerate the delay.

Thank you for joining us on The Steep Dive. The next time you're stuck waiting for a text to go through in a dead zone, just remember the relay runners holding those bundles in the dark, waiting patiently to pass them on. You're listening to a podcast right now, driving, working out, walking the dog. If you're in a podcast, chances are you have something to say too. With RSS.com, starting your own podcast is free and easy. To upload an episode and we distribute it to Apple podcasts, Spotify, Amazon Music, and more. Track your listeners, see where they're from, and start earning from ads just like this. If you've been thinking about starting a podcast, this is your sign. Start your new podcast for free today at RSS.com.

More episodes

More from pplpod

View all episodes →