FrogNet — Living Network · Field demonstration

We starved the link until it should have died. The call didn't.

An HD video call, coast to coast across the public internet — then choked to dial-up-era bandwidth, on purpose.

We took the bandwidth away a step at a time and watched for the moment it broke. The picture stepped down. The audio never flinched. Nothing reconnected, because nothing ever dropped — and the instant we gave the link back, it stood right up.

We put a laptop in New York and a laptop in Seattle and opened a live HD call. The path between them was not a straight wire — it ran through three nodes in Seattle, an encrypted tunnel across the public internet, and three nodes in New York. A chain of cheap machines. No server in the middle doing the heavy lifting. To FrogNet, the whole thing was one private network.

Then we did the thing you are never supposed to do to a live video call. We started taking the bandwidth away — on purpose, a step at a time — and watched for the moment it broke.

Down past broadband. Past DSL. Down into the dial-up era: about three hundred kilobits a second for each direction of video. A normal HD call is dead long before that.

FIG. 01
The setup — the actual path the call took.
INTERNET TUNNEL ↓ the link we starved SEA LAPTOP SEA 3 SEA 5 NY 1 NY 2 NY LAPTOP SEATTLE — local segment NEW YORK — local segment One private 10.x address plane spans every hop — wired LAN and the internet tunnel alike.
The call crossed three Seattle nodes, an encrypted tunnel across the public internet, and three New York nodes. No server coordinated it — the nodes passed the call hand to hand, and to FrogNet the whole chain was one private network. The tunnel in the middle is the link we throttled.

What the link actually did

As we tightened the link, the picture stepped down one rung at a time. 720p, then a little less, then less again — four rungs in all — and it kept a real picture the whole way down. Not the same rung in both directions: New York to Seattle held at 320 grayscale, the deliberate video floor, while the camera at the slow end shut down when its own leg reached the rung below. The picture never left the link that could still carry one.

The audio did not move. Not a stutter, not a dropout, none of those underwater moments where a voice smears and you lose the word. It held flat for the entire test.

And the call never reconnected — because it never disconnected. No “Reconnecting…”, no spinner, no drop back to a lobby. The session rode the bad link all the way to the floor and stayed up.

FIG. 02
The Starve Test — capacity pulled to the floor, then handed back.
THE STARVE TEST
LIVE TELEMETRY · BOTH DIRECTIONS
PICTURE HELD · 320 GRAYSCALE · ≈300 Kbps / LEG
LINK capacity VIDEO quality AUDIO voice 720p · L7 NY→SEA  L5 · 320 gray SEA→NY  L4 · camera off ≈300 Kbps per leg · dial-up era · audio bidirectional throughout 0 DROPOUTS — HELD THROUGHOUT LINK RESTORED → INSTANT 720p · NO RECONNECT FULL STARVE DEEPEST RUNG RECOVER
NY→SEA  L7 720p … L5 · 320 grayscale · picture held  |  SEA→NY  L7 720p … L4 · camera off · voice held  |  audio bidirectional · 0 dropouts TUNNEL · STARVED ON PURPOSE
Video and link capacity step down together to the deepest rung reached, ≈300 Kbps per leg; the audio line never breaks. The two directions did not land on the same rung: the picture held at 320 grayscale one way, while the camera at the slow end shut down the other. At RECOVER the link is restored and the picture returns to full 720p with no reconnect.
We took away the thing every other call is built on. The call shrugged.

Then we gave it back

We jumped the link back up. The picture snapped to full 720p in both directions — instantly. No renegotiation, no dialing back in. It stood right back up, as if nothing had happened.

Why this is supposed to be impossible

A 720p call on a conventional stack wants somewhere between one-and-a-half and two-and-a-half megabits a second. Give it three hundred kilobits and HD simply is not on the menu — the encoder cannot make a watchable picture, and the session machinery starts timing out underneath it.

FIG. 03
What 720p normally costs — versus where the call held.
0 0.5 1.0 1.5 2.0 2.5 Mbps CONVENTIONAL 720p CALL HD not available below ~1.5 Mbps typical 720p range ↑ ~1.5 Mbps floor THE FROGNET CALL ≈0.3 Mbps / stream — held a real 720p picture
720p HD typically needs ~1.5–2.5 Mbps on conventional stacks (standard encoding guidance). The demonstrated call ran down to ≈300 Kbps per leg, each direction — inside the band where HD “isn't doable.”

I want to be precise. Plenty of modern stacks degrade a stream; they will shed resolution and frame rate when they must. What they do not do is keep the whole call alive while the network underneath comes apart and then heals. The stream bends — the session snaps.

The FrogNet breakthrough that changes this

So how did ours survive? Not with a clever patch bolted onto the same old stack. FrogNet is a clean-sheet rebuild of how machines talk to each other — engineered, from the bearer up, to bring networking into the modern era.

The old model assumes two things: a reliable pipe, and a server in the middle keeping everyone in sync. FrogNet assumes neither. It is a full stack, and every layer was rethought to need less, trust less, and survive more.

FIG. 04
The full stack — rebuilt layer by layer, bearer to app.
5
Your apps
Live A/V calls, dashboards, sensors, even games — all riding one substrate.
4
Semantic compression
Structure-aware codecs put roughly a tenth as much on the wire.
3
UnREST
Peers exchange memory, not messages — sending only what actually changed.
2
The fabric
A private 10.x address plane that forms itself. No admin. No central server.
1
Any bearer
Wired, Wi-Fi, an internet tunnel, long-range radio — treated all alike.
Designed from the bearer up to bring networking into the modern era. Every layer rides on the one beneath it — strip the bottom and the layers above do less with what is left, instead of falling over.

That whole stack is what carried the call you just watched — and it is why the call behaved the way it did when the floor dropped out.

The part that actually matters

The reason our call survived is not a cleverer codec. It is that there was nothing in the middle holding the call together to begin with.

FIG. 05
A thread through a middle that breaks — versus no middle at all.
A CONVENTIONAL CALL YOU SERVER SESSION THEM one point that must hold — lose it, lose the call A FROGNET CALL YOU THEM no center · each side keeps its own picture, re-derives

No server to lose. No session to renegotiate. No connection state stranded on a link that keeps flapping. A conventional call is a thread strung between two ends through something in the middle; pull on it and it breaks. FrogNet does not string the thread. Each side keeps its own picture of what is there and reconciles it with the other — so when the link goes bad there is no handoff to fumble and no center to go find. It just re-derives.

Graceful degradation is not a feature we added. It is what is left once you remove the parts that break.

You cannot get this by bolting adaptation onto a conventional stack. The gracefulness comes from what is missing.

Who this is for

If your network is a hostile place — field operations, disaster response, remote industrial sites, anywhere the link is thin, shared, and unreliable — this is the behavior you actually need. Not “flawless on the conference-room Wi-Fi.” Working while the link is failing, and recovering the instant it can.

This is not a render or a roadmap. It ran end to end, on hardware you could buy today.

FrogNet. Your own network, on equipment you already own.

(Source available on request.)
— John Fawcett

Get the full picture.

The technical overview walks the whole stack — the fabric, UnREST, the codecs, and the media plane that carried this call — at altitude, in plain terms.

(Source available on request.)

↓  Download the technical overview
FrogNet Living Network · figures from live field telemetry · NY ↔ SEA, coast to coast across the public internet

What you just read

The ladder is the claim, not the floor

The bitrate at any rung is a property of that bearer on that day. What is architectural is the order: the picture sheds resolution, then colour, then itself, and the voice is the last thing to go — and it climbs back with no redial because nothing ever dropped.

The media stack has the clearest measuring stick in the system, and its largest open piece is host-side transcoding: accept from each transmitter at native rate, encode per receiver, so one starved participant stops setting the level for everyone. If you have fought adaptive streaming for a living, that one is yours.

The media seam →