Cyborg Resilience Co-lab — Ideas

The 2026 Urban Resilience Exercise: Your 30-Minute Network Survival Guide

2026-07-28T00:00:00+08:00

Three settings, three screenshots, three agreements and you will get through this exercise just fine. This is only mobile data throttling — you can still make calls and send texts!

※ For the actual dates, times and content of the exercise, please follow the announcements of the government authorities ※

Check the time and place of the exercise first — 30 minutes each

Once the exercise starts, browsing on your phone’s 4G／5G, and the hotspot you share to laptops and tablets, will be extremely slow

Phone calls, text messages, disaster warning alerts, 110／119: all normal

※ For the actual dates, times and content of the exercise, please follow the announcements of the government authorities ※

Change 3 settings

All of them are free features built into your phone or computer — a few taps and they are working.

1. Set up offline maps Google Maps → tap the profile picture in the top right → “Offline maps” → “Select your own map” → download the area around your home, the area around your office, and everywhere else you regularly pass through.

2. Set cloud files to be available offline For the slide decks, quotations and contract PDFs you need that afternoon, right-click them on Google Drive／OneDrive／Dropbox or whichever cloud drive you use and choose “Available offline” or “Always keep on this device.” Do it once in the mobile app as well.

3. Save music and videos Download the podcasts / music / videos you want for your commute in advance.

Once you are done, remember to turn off all Wi-Fi + switch on airplane mode, and test that these offline files really work.

Take 3 kinds of screenshots

Just save them to your photo album — you can look at them without a network.

1. Phone numbers Family, school／after-school care, your manager, the clients you need to contact that day. Plenty of people only have someone’s LINE and have no idea what their mobile number is. Remember to copy them onto a slip of paper for your wallet too — that survives a dead phone battery.

2. That day’s schedule Meeting times, places, the other party’s name and phone number.

3. Tickets and addresses For paid high speed rail and Taiwan Railway bookings, screenshot the “booking code (number)” and then collect the paper ticket with the booking holder’s ID; event QR codes, the street addresses you are visiting, and the shelters near your home／office (you can look these up in the air-raid shelter section of the National Police Agency, Ministry of the Interior, or download the 「警政服務」 police services app in advance and save the offline map inside the 「消防防災 e 點通」 fire and disaster prevention app).

Note 1: Both the high speed rail and Taiwan Railway companies explicitly prohibit the use of screenshotted ticket QR codes.

Note 2: For rules on screenshotting event QR codes, please follow the terms of each organization/company.

Make 3 agreements

It doesn’t cost a cent — you just have to say it out loud.

1. To family, elders and friends “Between 2:30 and 3:00 pm on 8/13, LINE messages may not go through — that’s the network throttling drill. If anything comes up I’ll call you directly, and you can text me.” → This one sentence saves the other person a whole afternoon of anxiety~

2. To colleagues “No online meetings during this half hour.” Move the 14:30 video call earlier to 14:00, or later to 15:10; if it absolutely has to happen, switch it to a voice-only call or walk over and talk face to face.

3. To colleagues out in the field and whoever picks up the children Agree on a “check-in time ＋ meeting point,” for example “I’ll call you at 15:00; if you can’t get through, wait for me in the ground-floor lobby.” Whenever you cannot reach each other at the agreed time, head instead for the fixed meeting point you settled on in advance.

14:20 on the day: a 3-minute wrap-up

Approvals, reports and attachments you send from your phone: hit send before 14:25 and don’t cut it fine.
If your company systems, VPN or online banking need push verification from a phone app, log in on your computer beforehand and don’t log out during that half hour (systems that use SMS verification codes are unaffected)
If you need to place an order, transfer money or upload a tender, handle it on a computer on fixed broadband, or simply avoid this half hour
Wallet check: cash ＋ a physical EasyCard／iPASS ＋ a physical credit card. When the connection is very slow, the payment barcode in a mobile payment app may not open.
Check that your laptop is on the office Wi-Fi rather than your own phone hotspot

14:30–15:00: how to spend these 30 minutes

Things you can do

Connect to the fixed-broadband Wi-Fi at the office or at home and you will barely notice a thing
If you need someone, call them; if it isn’t urgent, text them
Schedule it as an “offline work block”: proofread on paper, write documents, tidy your desktop, walk over and finish a conversation with a colleague

Things not to do

Don’t hammer refresh. The more people retry, the slower it feels
Don’t go changing network settings or the APN — it is very easy to forget how to change them back afterwards
Don’t rush to call your telecom’s customer service

After 15:00

If the network doesn’t come back on its own: switch airplane mode on for 10 seconds and then off again, or simply restart the phone.

Then spend two minutes asking yourself one question: which thing just now was the most stuck? Was it not being able to find someone’s phone number, not being able to pay, or not being able to open a file? Write it down — because when the network is damaged by a real typhoon or earthquake, nobody announces the time in advance.

Further reading: Why Run a Mobile-Network Throttling Drill? Is There Any Point?

※ For the actual dates, times and content of the exercise, please follow the announcements of the government authorities ※

Why Run a Mobile-Network Throttling Drill? Is There Any Point?

2026-07-22T00:00:00+08:00

Taiwan ranks among the world’s best for mobile data pricing, connection speed, and connection quality. That is the fruit of years of construction and maintenance by the three major telecom operators and the government, and it is why the public enjoys a mobile network environment that is both stable and inexpensive.

Taiwan is also, however, a country where typhoons and earthquakes are frequent. Beyond damaging water supply and the power grid, natural disasters also reach network and communications equipment such as base stations and cables: the magnitude 7.2 Hualien earthquake of April 3, 2024 affected 172 mobile base stations at its peak (mostly concentrated in the Yilan–Hualien area)[1]; in July 2025, Typhoon Danas put more than 1,300 base stations in and around the Chiayi–Tainan area out of service through power loss or damage[2][3], and some of them were not fully repaired until the end of October that year[4]. A mobile network outage does not just make it hard for residents of a disaster area to reach family and friends; it also obstructs the coordination of relief work.

It is worth noting that damage to base stations mostly produces a “localized outage,” whereas damage to Taiwan’s international subsea cables could produce an “island-wide slowdown”: the core servers of many everyday apps and websites sit overseas, so once international bandwidth drops sharply, services will still stall badly even when the domestic network is working normally. The “Digital Resilience Forum: Subsea Cables and Network Infrastructure in an Age of Geopolitics”, held by Cyborg Resilience Co-lab (CRC) on March 25 this year, ran a simulation and analysis of exactly this kind of partially damaged network scenario[5]; one of its conclusions at the time was that “drills, whether run by government or by civil society, need to include scenarios in which the network is damaged.”

The government has long promoted disaster prevention and relief education and evacuation drills, so that people become familiar with response procedures before a disaster arrives and build the capacity to handle sudden situations. The core of disaster mitigation (and prevention) is to reduce the impact of natural disasters on daily life as far as possible; as everyday life grows more dependent on the internet, “network slowdown or outage” should be brought into drill scenarios too.

Drills of this kind, dealing with networks and communications, are not unprecedented internationally: the “Council for Emergency Communications” (Japanese: 非常通信協議会), formed by Japan’s Ministry of Internal Affairs and Communications together with telecommunications organizations, regularly runs “emergency communications training,” in which disaster information is relayed over backup power and alternative communications circuits when public lines and disaster-prevention radio are down[6]; South Korea’s 2025 “Ulchi exercise” (을지연습) mobilized roughly 4,000 agencies and 580,000 people, with scenarios covering not only communications outages and destruction of network infrastructure but also GPS jamming[7]; and NATO’s Cooperative Cyber Defence Centre of Excellence (CCDCOE) holds Locked Shields, the world’s largest live-fire cyber defense exercise, in Tallinn, Estonia every year, mobilizing 41 nations and more than 4,000 people to practice defending critical infrastructure, including scenarios in which communications infrastructure is destroyed[8].

Finland has gone further still: for nine consecutive years the Digital and Population Data Services Agency (DVV) has run the nationwide “TAISTO” cyber and information security exercise, open free of charge to every public-sector organization, with more than 450 agencies and institutions taking part in recent editions; working with the police and national security agencies, it simulates scenarios such as cyberattacks, systems being hacked, and even AI information security[9].

This year’s Urban Resilience Exercise includes a “mobile network throttling” drill for the first time: starting at 2:30 pm on August 10 (7 central counties and cities) and August 13 (7 northern counties and cities), it simulates the shortage of bandwidth that follows the activation of disaster roaming and tiered traffic limiting, throttling speeds for 30 minutes; voice calls, SMS, Public Warning System cell broadcasts, and emergency numbers such as 110 and 119 are all unaffected, and Wi-Fi running over fixed broadband is unaffected as well[10]. The public can use the occasion to practice alternatives such as offline maps, cash payment, and reaching people by phone number, preparing in advance for the natural disasters that may come.

We are glad to see this item added to this year’s exercise, and we hope future exercises and disaster-prevention education will keep broadening and deepening scenarios related to digital resilience!

With half a month to go before the exercise, CRC will share next week how to prepare for the “mobile network throttling” drill. We’d love for all you brilliant people to leave a comment and share what you, your family, or your friends have already arranged for this one~~

References

Central News Agency, “Strong quake affects 172 base stations across the three major telecom operators; NCC estimates repairs today,” April 3, 2024.
Executive Yuan, “Typhoon Danas response measures and recovery status” (figures as of July 9, 2025; 1,360 base stations damaged).
United Daily News, “Typhoon Danas devastates communications in Chiayi–Tainan; NCC activates disaster roaming to avert digital isolation” (1,293 base stations in southern Taiwan knocked out by power loss or damage).
Central News Agency, “Typhoon Danas devastates base stations; Chunghwa Telecom: restoration scheduled by the end of October,” August 4, 2025.
CRC Cyborg Resilience Co-lab, “Digital Resilience Forum: Subsea Cables and Network Infrastructure in an Age of Geopolitics”, March 25, 2026.
Council for Emergency Communications (非常通信協議会), 非常通信確保のためのガイド・マニュアル.
이치저널, “드론과 GPS가 멈춘다”… 전 국민이 훈련에 들어가는 3박 4일, 2025 을지연습, August 2025.
NATO CCDCOE, “Locked Shields.”
Digi- ja väestötietovirasto (DVV), “TAISTO-harjoitus”; see also the DVV press release.
Central News Agency, “Urban Resilience Exercise: phones throttled, not disconnected, across 14 counties and cities — the affected scope explained in one read,” July 21, 2026.

CRC Digital Resilience Forum: Simulating a Drastic Drop in Taiwan's International Internet Traffic

2026-03-25T00:00:00+08:00

Original slides and materials published at https://paulpengtw.github.io/crc-march-25-decks/.

Topic Outline

At the March 2026 Digital Resilience Forum, Cheng Peng presented a simulation titled “Degradation of Taiwan’s International Internet Traffic.” The scenario: submarine cables severed by an earthquake, causing Taiwan to instantly lose 50% of its international bandwidth (*note 1). The talk then walks through the cascade of failures likely to appear within the first six hours, VoIP calls (LINE voice, Messenger voice) dropping, web pages freezing, apps breaking one after another, accounts logging out, and the maddening experience of full Wi-Fi bars yet nothing loading.

This talk aims to explain the possible causes behind these network failures and what paths might mitigate their impact.

*Note 1: Losing half the submarine cables does not equal losing half the international internet traffic.

0–5 min

Phase 1: Why Did Voice Calls Suddenly Drop?

What You Might Experience

LINE voice call → robotic audio → disconnected ☎️❌
Instagram → blank screen
Google Drive → half-loaded, stuck
Glance at the top-right corner

Wi-Fi signal: full bars 📶

“Is It the Wi-Fi Router or the Internet?”

Full Wi-Fi bars ≠ working internet

📱 → 📡 Wi-Fi: your phone to your home router

This part is perfectly fine ✓

📡 → 🌏 Internet: your router to the rest of the world

This is where the problem lies ✗

The problem isn’t at home, it’s on the ocean floor.

What Is the Internet, Really?

Think of the internet as a system of thousands of post offices.

🏣 Each post office = a network node (ISP, data center)

✉️ Your data = individual letters (packets)

🛣️ Post offices are connected by many routes for relaying letters

Sending a letter from Taipei to Tokyo means it passes through several post offices, relayed from one to the next.

The internet isn’t a single line, it’s many nodes relaying data to each other. Each ISP and data center is like a post office. Your data is like letters, forwarded hop by hop to the destination.

How Does a Post Office Know Where to Send a Letter?

Every post office has a signboard out front 🪧

"Going to Japan? → Hand it to the post office to the south"

"Going to the US? → Hand it to the post office to the east"

"Going to Kaohsiung? → Hand it to the one next door"

This signboard, in networking, is called a routing table.

The way post offices keep each other’s signboards up to date is called BGP (Border Gateway Protocol).

A routing table is each network node’s “directional guide.” BGP is the protocol the global internet uses to synchronize routing information. No need to memorize the jargon, just remember: BGP = the system through which post offices notify each other “how to get there.”

Cables Cut = Routes Cut

The light beams inside the fiber vanish instantly (they’re severed, after all).

The post office nearest to the break is the first to notice: “This route is down!”

It immediately broadcasts to its neighbors: “Attention everyone! The southbound route is broken! Stop sending letters this way!”

The message starts spreading from one post office to the next…

Submarine cables are fiber optic. When severed, the optical signal disappears instantly, not a gradual fade, but an immediate zero. The router (post office) connected to that cable detects the link failure and announces via BGP to its neighbors: this route is no longer valid. That announcement ripples outward across the global internet.

The Chaos of Rerouting

BGP Reconvergence

Thousands of post offices worldwide receive the news, but not simultaneously.

🏣 Post office A has already updated its signboard ✓

🏣 Post office B doesn't know the route is down yet ✗

🏣 Post office C got the message but is still computing new routes ⏳

Your letters end up…

Sent down a route that’s already broken → lost
Bouncing back and forth between two post offices → looping
No post office willing to accept them → returned

This chaotic period: 30 seconds to several minutes

BGP reconvergence is the process by which the entire internet reaches a new consensus. The problem: information propagation has latency, and different nodes update at different speeds. During this transition, routing tables are in an inconsistent state, some routers think the old route still exists, others have already switched. This causes packets to be dropped, looped, or sent into dead ends. Duration depends on network topology complexity and BGP convergence speed.

To You, It Probably Feels Like, Everything Is Down

Packets dropped → web pages may not load

Packets rerouted the long way → latency may jump from 20ms to 2000ms

Packets looping → may never reach the destination

50% of international traffic is technically still there, but until routing reconverges, for the average person it may feel like total gridlock.

50% of capacity remains, but during BGP convergence it’s nearly unusable. It’s like a major highway pileup, the next lane is still open, but because the signs are scrambled, every car is stuck at the interchange. Once BGP converges (all signboards are consistent again), the remaining 50% can actually be utilized, but then congestion becomes the next problem.

LINE Voice May Drop, but Text Might Survive?

💬 Text messages

Tiny packets (maybe just a few KB)

Can squeeze through gaps in the chaos

A few seconds' delay doesn't matter

🎙️ Voice calls

Continuous real-time streams

Dropping a few packets = robotic voice

Latency over 300ms = call drops

What we're not sure about:

LINE's call servers might be in Japan?
Voice calls within Taiwan might have to cross the ocean to connect?

5–30 min

Phase 2: Zombie Internet

Entering Phase 2. BGP has finished reconverging and routing has stabilized. But people will notice: the internet is “alive” yet almost unusable. This phase explains two things: congestion collapse and the Trombone Effect.

What You Might Experience

Web pages half-loaded… stuck
Images half-rendered, the rest just gray
YouTube possibly spinning forever
LINE text barely sending, taking ages to deliver

Signal is full 📶, appears “connected,” but may be too slow to use.

Unlike Phase 1 (complete disconnection during BGP convergence), this is “connected but extremely slow”, which is actually more confusing. People keep refreshing and retrying, which only makes things worse.

Wait, Wasn’t the Route Fixed?

BGP reconvergence complete ✓, all post office signboards are consistent now.

The remaining 50% of international traffic works normally ✓, routes are open, letters can be delivered.

So why is it still this slow?

The routes aren’t broken, they’re just too crowded.

The previous phase’s problem was “scrambled signboards” (BGP convergence). This phase’s problem is “too few lanes, too many cars” (congestion collapse). Two completely different failure mechanisms, but to users they feel about the same.

Imagine a Highway

Taiwan’s international traffic = a 10-lane highway 🛣️

Normally, traffic fills about 7–8 lanes, there’s room to spare, everyone moves smoothly.

Losing 50% of capacity = suddenly only 5 lanes

But traffic volume hasn’t changed, same number of cars, half the road.

Highway analogy for congestion. Normally, submarine cable utilization is around 40–60%, so there’s headroom. After losing half, the remaining capacity is instantly saturated. Traffic doesn’t decrease just because there are fewer lanes.

The Chain Reaction of Gridlock

Why isn't it "half as fast" but rather "barely moving"?

🚗 Too many cars, some can't merge → packets dropped

🔄 Dropped cars say "Let me try again!" → back on the road

🚗🚗🚗 Everyone retrying → even more cars on the road

💥 More cars dropped → more retries → vicious cycle

This is called "congestion collapse"
Congestion Collapse

This is the core mechanism of congestion collapse. TCP retransmits when it detects packet loss. But when all connections retransmit simultaneously, they generate even more traffic, worsen the congestion, cause more packet loss, and trigger more retransmissions. This vicious cycle is congestion collapse.

Understanding It Through Letters

(Continuing the post office analogy)

You sent a letter to the US ✉️

Too much traffic on the route, the letter was lost → you never got a reply.

You think: “Probably got lost, let me send another!”, your computer thinks the same way (TCP retransmission).

Now imagine 23 million people in Taiwan, all with their phones "sending another" at the same time…

🏔️ Letter avalanche

TCP retransmission works great under normal conditions, occasionally drop a packet, just resend it. But under total congestion, everyone resending simultaneously becomes a disaster. It’s like everyone honking and cutting lanes during a traffic jam, it only makes things worse.

50% physical capacity ≠ 50% usable bandwidth. Due to the nonlinear effects of congestion collapse, once link utilization exceeds a certain threshold, effective throughput drops sharply. Some studies show that under severe congestion, effective bandwidth utilization can drop to 15–20%.

What Your Experience Might Look Like

📄 Web pages → text may load, but images spin forever

🎬 Video → possibly 240p pixelated, constantly buffering

📥 Downloads → speeds may drop from 100 Mbps to 2 Mbps

📱 Apps → may open, but every action takes 10+ seconds

Not disconnected, but slow enough to make you cry qq

This is the concrete impact of congestion collapse. “Too slow to use” is worse than “completely offline,” because you keep retrying, keep waiting, wasting huge amounts of time. And you can’t tell if it’s your problem or the entire network.

The Next Problem Is Even Stranger

Some websites have servers physically in Taiwan, theoretically don’t need international routes, and shouldn’t be affected.

But they may also be broken 🤯

Why?

Congestion collapse explains “why international traffic is slow.” But next we need to explain an even more bizarre phenomenon: why services whose servers are in Taiwan, requiring no submarine cables, are also broken. This is where the Trombone Effect comes in.

🏪 The Convenience Store Story

There’s a 7-Eleven on your street corner. You want to buy a bottle of water.

Normally: 🏠 → 🚶 30-second walk → 🏪 Done!

It’s like connecting to a server in Taiwan from Taiwan, data doesn’t need to cross the ocean, it stays on the island.

The convenience store analogy explains the Trombone Effect. Server is in Taiwan, you’re in Taiwan, data transfers directly within the island. As simple as walking to your corner 7-Eleven.

But Some ISPs Say…

"No! You can't just go to the one on your corner!"

Some ISPs dictate this route:

🏠 Your home
→ ✈️ First, fly to Tokyo
→ 🏪 Check out at a Tokyo 7-Eleven
→ ✈️ Fly back to Taiwan
→ 🏠 Get your water

All for a bottle of water available on your street corner 🤦

Your request is forced overseas and back. The server is right next to you, but your ISP’s routing configuration sends the traffic to Japan or Hong Kong before looping it back, absurd indeed.

Why Do Some ISPs Route This Way?

Because Taiwan’s ISPs don’t “shake hands” locally.

🤝 Peering: two providers agree, "your users can directly reach my servers"

🏢 Internet Exchange: a place where everyone comes to shake hands

Problem: some Taiwan ISPs aren't keen on shaking hands with others
or they share very little traffic

Explaining peering and Internet Exchange concepts. “Handshake” as an analogy for peering. TPIX is one of Taiwan’s internet exchange points, in theory, ISPs can directly exchange traffic there without routing overseas. But in practice, many ISPs (especially large ones) refuse to peer at TPIX, believing their network is big enough not to need to “shake hands” with smaller ones, or they show up but only open minimal bandwidth.

You Don’t Notice Under Normal Conditions

The detour through Tokyo only adds 20–30 milliseconds, you wouldn’t notice the difference.

So some ISPs think: “Users won’t notice anyway, why spend money on local peering?”

Until the cables go down: that overseas detour is now jammed

Your bottle of water is stuck in a queue on the Tokyo airport runway

Result: Server Right Next to You, but You Can’t Connect

📍 Server location

Taipei, Neihu

10 km from you

📍 Actual route your data takes

Taipei → Tokyo → Taipei

A 4,000 km detour

International congestion → detour jammed → you can't reach a server 10 km away

This is tromboning 🎺, the “trombone effect”: data loops around like the slide of a trombone.

Two Main Bottlenecks of This Phase

❶ Massive Gridlock

50% capacity ≠ 50% speed
Usable bandwidth may drop to just 15–20%

❷ Massive Detours

Insufficient domestic peering
Domestic traffic forced overseas
Even local servers affected

These two problems combined: “having internet” may not mean “usable internet.”

Summarizing the two core concepts of this phase. Congestion collapse: the nonlinear relationship between physical capacity and actual usable bandwidth. Trombone Effect: routing policies causing traffic that shouldn’t cross the ocean to also suffer. Together, they create “zombie internet”, looks alive, practically unusable.

But It May Get Even Worse…

The services still working, maybe Google Search occasionally returns results, some web pages are still viewable, they’re still alive possibly because of “caching”: copies previously stored in Taiwan that still work temporarily.

But caches have expiration dates…

When they expire, services may break one by one ⏳

Many services still functioning are relying on CDN caches. Caches have TTLs (time-to-live); once expired, they must fetch fresh data from overseas origin servers. But with submarine cable congestion, the fetch fails → cache expires → service goes down. This pattern of “gradual degradation” is explained in detail in the next phase.

30–60 min

Phase 3: It Was Just Working, Why Is It Broken Again?

Entering Phase 3. Congestion has stabilized, ISPs have started traffic management. But people notice a peculiar phenomenon: things that were working start breaking one by one. This phase explains three mechanisms: CDN cache expiry, Auth Token expiry, and DNS cache expiry. The “gradual degradation” caused by these three mechanisms is more dangerous than total disconnection, because it makes it impossible to pinpoint where the problem lies.

What You Experience

Google Drive was working a moment ago, now it’s stuck
News sites show text but all images are gone
LINE may crash and you can’t log back in
Banking app asks you to re-enter your password, then spins forever

Not everything breaks at once, they break one by one, seemingly at random.

This kind of “gradual failure” is the most confusing. Total disconnection actually lets people know “the internet is down” and prompts them to find alternatives. But when things break one at a time, some still working, some not, people keep retrying, wasting time, and growing more anxious. Next we explain why things “break one by one.” The answer: three different “expiration timers” are all counting down simultaneously.

Back to the Convenience Store

Your neighborhood 7-Eleven 🏪, the shelves have “copies” of drinks, bento boxes, and snacks.

Where do these products come from? Overseas warehouses 🚢, the 7-Eleven doesn’t make anything; it stocks goods from warehouses and puts them on shelves for you.

The digital world works the same way. CDN is your neighborhood’s digital convenience store (Content Delivery Network).

CDN = Content Delivery Network. Companies like Cloudflare, Akamai, and CloudFront have “edge nodes” in Taiwan. These nodes are like convenience stores: they copy content from overseas servers and store it locally in Taiwan, so users don’t have to fetch from overseas every time. The web page images, CSS, and JavaScript files you browse often come from CDN nodes in Taiwan.

Expiration Date: TTL

Time To Live

Convenience store bento boxes have expiration dates, once expired, they can’t be sold and must be restocked from the warehouse.

CDN caches have a similar expiration mechanism called TTL (Time To Live: how long this copy remains valid).

TTL might be 5 minutes or 24 hours, every website and every file has different settings.

For the first 30 minutes, most caches haven't expired yet, so things "still work." Now, expiration dates are starting to hit one by one.

TTL is set by the server, telling the CDN “how long this copy can be used.” A news site’s homepage images might have a TTL of just 5 minutes (needs real-time updates). A jQuery library might have a TTL of 1 year (rarely changes). In the first 30 minutes after the cable break, most caches are still within their validity period, so users feel things are “okay.” But as time passes, various caches’ TTLs expire one by one, and problems start appearing.

The Convenience Store Can’t Restock

Bento boxes on the shelf have expired → time to restock from the warehouse.

But the road to the warehouse is jammed 🚛💨

(International traffic congestion = extremely slow international connections)

The restocking truck has departed… but is stuck in traffic and can’t get back. The CDN requests fresh data from the overseas origin server → timeout → failure.

Expired cache + can't restock = empty shelves

When a CDN cache’s TTL expires, the CDN node sends a revalidation request to the overseas “origin server.” Normally this takes just milliseconds. But now international connections are congested, the request either times out or responds extremely slowly. The CDN can’t get new data, so it can’t continue serving content; users see a loading failure.

Why Can Some Things Load but Not Others?

✅ Still viewable

Popular YouTube videos
Commonly used website CSS/JS
News images everyone's viewing

→ Cache recently refreshed, TTL not yet expired

❌ Can't view

Niche pages, old articles
Documents you haven't opened in a while
Real-time content with short TTLs

→ Cache expired, restock failed

This is why some parts of the same website work while others don’t, leading people to think the site is broken, when really it’s just different cache expiration times.

This explains why users feel the failures are “random.” On the same website, HTML text might have a 24-hour cache TTL (still valid), but images might have just a 1-hour TTL (already expired). So you see text appearing but all images blank, a bizarre sight. Content accessed by more people stays “fresher” because restocking is constantly triggered. Niche content is the opposite, the cache has likely expired long ago.

What Is an Auth Token?

Imagine going to an amusement park 🎢

At the entrance, you buy a ticket and verify your identity, then a staff member stamps your hand with a stamp.

Using the amusement park analogy to explain Auth Tokens. This concept is unfamiliar to non-technical audiences, but it’s key to understanding “why apps log you out one by one.”

The Stamp on Your Hand = Auth Token

With the stamp, you can:

Ride the roller coaster 🎢, show the staff your stamp ✓
Ride the carousel 🎠, show stamp ✓
Buy park food 🍔, show stamp ✓

No need to re-queue, re-purchase tickets, or re-verify your identity each time. The stamp represents “this person has already been verified.”

An Auth Token is that stamp on your hand. After logging into Google, your browser receives a “stamp”, then opening Gmail, Drive, or YouTube doesn’t require logging in again.

Auth Token is this “stamp.” You log into Google once, and your browser gets a token. Every subsequent request to Gmail, Google Drive, or YouTube includes this token. The server sees the token and knows “this is an authenticated user” without asking for your password each time.

But the Stamp Fades

The amusement park’s stamp uses special ink, after 15 minutes to 1 hour, the stamp fades and becomes invisible.

Why not use permanent ink?

🔒 If someone copies your stamp (token stolen)

Fading ink → the thief can use it for 15 minutes at most

Permanent ink → the thief can impersonate you forever

So tokens are intentionally designed to expire: it’s a security mechanism.

Tokens being short-lived is a deliberate security decision. If a token were valid forever, once stolen (e.g., via XSS attack, man-in-the-middle attack), the attacker could impersonate you permanently. Short-lived tokens limit the damage of theft: even if stolen, it expires in 15 minutes. It’s like a credit card expiration date, not for your convenience, but to limit the risk of fraud.

Stamp Faded? Go Back to the Ticket Booth

Stamp faded → walk back to the entrance ticket booth 🎫, show your season pass, staff re-stamps your hand. The whole process takes seconds; you barely notice.

Normally, this is a total non-issue, the app automatically “re-stamps” you in the background without you ever noticing.

But… what if the ticket booth is on the other side of the ocean?

Under normal conditions, the “re-authentication” after token expiry happens automatically in the background. The browser or app uses a refresh token (like a season pass) to request a new access token from the authentication server. The entire process takes a few hundred milliseconds, users are completely unaware. But the critical question is: where is the authentication server?

The Ticket Booth Is Across the Ocean

Google’s authentication server is likely in 🇺🇸 the US
LINE’s authentication server is likely in 🇯🇵 Japan
Microsoft’s authentication server is likely in 🇺🇸 the US

Your stamp faded → you may need to cross the ocean to get re-stamped.

But international traffic is congested = that route is jammed 🚗🚗🚗

The re-stamp request was sent… but the reply can’t get back, waited 30 seconds → timeout → failed.

You've been logged out. And you can't log back in.

This is the core Auth Token problem during a submarine cable event. Google’s OAuth authentication servers are primarily in the US (accounts.google.com resolves to US IPs). LINE’s authentication goes through Japanese servers. Microsoft’s Azure AD is also in the US. When tokens expire and the app tries to re-authenticate with these overseas servers, the international connection is congested, requests time out, and you get logged out. And the login page itself also needs to connect to overseas servers, so even “logging back in” is impossible.

Everyone Gets Logged Out at Different Times

⏱️ 20 min after cable break: Google Drive stamp may have faded → possibly logged out
⏱️ 35 min after: LINE stamp may have faded → may crash and can't log back in
⏱️ 45 min after: Online banking stamp has faded → asks to re-login → fails
⏱️ 50 min after: Company Slack stamp may have faded → possibly disconnected entirely

This is why it seems "completely random", because each app's stamp fades at a different time.

Each service has a different token validity period: Google is typically 1 hour, some banking apps 15 minutes. And each user logged in at a different time, so tokens expire at different times. This creates the chaotic “gradual failure” scenario: your colleague’s Google Drive still works (they just logged in), yours doesn’t (your token just expired). Everyone asks each other “is yours working?” and gets different answers, even more confusing.

The True Face of a Token

Technically, a token looks like this:

  eyJhbGciOiJSUzI1NiJ9.eyJ1c2VyIjoi5bCP5piOIiwic2NvcGUiOiJkcml2ZSIsImV4cCI6MTcxMTEyMzQ1Nn0.SflKxwRJSMeKKF2QT4fw

This is called a JWT (JSON Web Token), containing:

👤 Who you are

user: Xiao-Ming

🔑 What you can do

scope: drive

⏰ When it expires

exp: 1 hr

The last segment is a digital signature: prevents forgery, only the server can generate it.

JWT is the most common token format today. It has three parts (separated by .): header (algorithm), payload (content), signature. The middle payload section is base64-encoded, containing JSON data. The key part is the final signature: it’s signed with the server’s private key, so nobody can forge it. When the server receives a token, verifying the signature confirms whether it issued the token.

The Life of a Token

1️⃣ Login: enter username & password → server gives you two things

　　Access Token (entry stamp) valid for 15 min–1 hour

　　Refresh Token (season pass) valid for days–weeks

2️⃣ In use: every action carries the Access Token

　　Server sees the stamp and lets you through, no need to verify password each time

3️⃣ Stamp fades: Access Token expires → automatically renewed using Refresh Token

　　Done automatically in the background, you never notice

4️⃣ Season pass also expires: Refresh Token expires too → must re-enter username & password

　　This is why you occasionally get asked to "log in again"

The standard OAuth 2.0 flow. Access Token is short-lived (like the stamp on your hand), Refresh Token is long-lived (like a season pass). Normally, when the Access Token expires, the app automatically uses the Refresh Token to get a new Access Token from the server. This entire process happens in the background, users notice nothing. Only when the Refresh Token also expires (typically days to weeks) are you asked to re-enter your credentials.

Why Not Issue a Permanent Pass?

🔓 If tokens were permanent

Stolen → attacker impersonates you forever

Permissions changed → old token still has old permissions

Left the company → token still works

🔒 Tokens expire periodically

Stolen → invalid in 15 minutes at most

Permissions changed → updated at next renewal

Left the company → token naturally expires

Token expiration isn’t a design flaw, it’s a security mechanism, like periodically changing door lock codes: inconvenient, but more secure.

This is the fundamental trade-off between security and convenience. A permanent token is like a key that never gets changed, convenient, but once copied, you’re done. Short-lived tokens are like periodically changed passcodes, annoying, but damage from a breach is limited. Under normal network conditions, the trade-off makes sense: re-authentication takes just a few hundred milliseconds, invisible to users. But during a submarine cable event, the “re-authentication” step suddenly becomes a fatal weakness.

The Chain Reaction During a Cable Break

Access Token expires

App may attempt to use Refresh Token in the background for a new one

Refresh request possibly sent to overseas auth server

But international connection is congested… waiting 10 sec, 20 sec…

Timeout failure ✗

App determines "authentication invalid" → possibly forces logout

But the login page itself may need to connect to overseas servers → also times out ✗

Logged out, and possibly can't log back in.

This is a cascading failure:

Access Token expires (normal mechanism)
Refresh request times out due to congestion (abnormal)
App determines authentication is invalid, forces logout (normal response)
User tries to log back in, but the login flow itself also requires international connectivity (fatal weakness)

Especially for OAuth login flows, the “Sign in with Google” button connects to accounts.google.com, and that server is in the US. So you can’t even open the login page.

Your Apps May Be Logging Out One by One

t+0 min　International traffic drops: all Token timers start counting down
t+15 min　Banking token expires → logged out
t+25 min　Slack token expires → possibly offline
t+35 min　LINE needs re-verification → possibly fails
t+45 min　Google Drive token expires → possibly can't access files
t+60 min　Possibly almost all authenticated services have failed

A “single disconnection” is unlikely to happen, it’s more like a slow-motion mass logout. Different people, different apps, different times: it looks completely random.

This is a timeline summary of the entire auth token story. The key takeaway: it’s not as simple as “the internet went down.” There’s an invisible countdown timer running inside every app, and the moment it hits zero, that app “dies.” And because every service has a different token validity period and every person logged in at a different time, the whole process looks completely random and without pattern.

Next Up: DNS

CDN cache expires → content disappears. Auth Token expires → logged out.

There's a third thing also counting down…

And if this one breaks, you can’t even find where the website is.

The previous two problems were “can’t get content” and “can’t authenticate identity.” The third is even more fundamental: “can’t even look up the address.” So we need to explain from the very basics.

What Is DNS? The Internet’s Phone Book

You type google.com into your browser, but your computer doesn’t understand “google.com.”

Computers only understand numeric addresses: 142.250.185.46, this is called an IP address, like a phone number, every server has one.

DNS = a phone book 📒, translating “names” to “phone numbers” (google.com → 142.250.185.46).

Without this phone book, even knowing someone's name doesn't let you call them.

DNS = Domain Name System. We use domain names to browse the internet, but computers communicate using IP addresses. DNS is the translation layer in between, converting human-readable names into computer-readable numbers. Without DNS, you’d have to memorize every website’s IP address to go online, like having to memorize everyone’s phone number without a contact list.

How Does DNS Lookup Work? Like Calling Directory Assistance

Your phone wants to find google.com’s phone number:

1️⃣ First, check your own contacts (local cache)

If you've looked it up before, use it directly, no need to ask anyone

2️⃣ Not there → call your ISP's directory service (DNS resolver)

Your ISP has a server dedicated to looking up numbers for you

3️⃣ ISP doesn't have it either → ask all the way up to "headquarters"

Root Server → .com administrator → google.com's authoritative server

4️⃣ Found it! Save the result in your contacts for next time

This is "DNS caching": remember the result to avoid calling every time

DNS lookup hierarchy:

Local cache (your device remembers previous lookups)
ISP’s DNS resolver (like 8.8.8.8 or your ISP’s DNS)
Root servers → TLD servers (managing .com) → authoritative servers (google.com’s administrator)

Normally, this entire process takes just tens of milliseconds. And results are cached at each level, so next time you don’t have to start from scratch. But caches also have expiration dates.

DNS Cache Also Has an Expiration Date

The phone numbers in your contacts also “expire”, google.com’s TTL might be set to 300 seconds (5 minutes), some .tw websites might be set to 3600 seconds (1 hour).

Why not remember permanently? Because servers might move (change IP), do load balancing, or perform failover. If you always use the old number, you might be calling a disconnected line.

So DNS caches also have TTL: once expired, you must look up the number again, normally takes tens of milliseconds, completely unnoticeable.

DNS record TTLs are set by website administrators. Large websites typically have short TTLs (minutes) because they need to frequently adjust traffic distribution. Small websites may have longer TTLs (hours to a day). Under normal conditions, DNS re-lookup is very fast, but during a submarine cable event, many websites’ authoritative DNS servers are overseas, making re-lookups travel through congested international connections.

DNS Cache Expires = Can’t Find the Address

Imagine a website service.gov.tw with its server right in Taipei 🏢.

Your device looked it up before, your contacts have its IP → connection works, fast ✓

But the DNS cache has expired: time to look up the number again. Where’s the authoritative DNS server? Possibly in the US (e.g., AWS Route 53)

The lookup call can't get through → you can't find the address, the server is just 10 km away, but you can't find it.

The server isn’t down, the internet isn’t cut, you’ve just forgotten the address, and you can’t ask anyone.

This is the most ironic DNS cache scenario: a .tw website, server physically in Taiwan, data in Taiwan, no international connection needed at all. But its authoritative DNS server uses AWS Route 53 (in the US). When your DNS cache expires and you need to re-query, the query request has to reach the US, through congested submarine cables, and then times out. Result: a completely domestic service, unreachable because the DNS can’t be resolved. This is the concept of “dependency chains”, on the surface it’s a domestic service, but it hides overseas dependencies.

1–6 hr

Phase 4 and Beyond: Control Plane Depends on Overseas

Entering Phase 4. The cable break happened over an hour ago. BGP reconverged long ago, congestion has stabilized, and the “gradual degradation” from various cache and token expirations has mostly run its course. But people notice a new phenomenon: some things are starting to recover, while others are completely dead. This phase explains two things: (1) ISPs begin manual traffic management, (2) cloud “control planes” depend on overseas infrastructure. Together, they create a new dividing line: purely domestic services come back to life; services with an overseas “brain” stay dead.

What You Experience

LINE text messages: possibly working again! ✅
Some previously visited web pages: possibly viewable
YouTube: possibly watchable, but maybe only at 144p pixelated quality
Instagram: possibly text only, all images are gray boxes 🖼️❌
Logging into any SaaS tool: possibly spinning, failing
AWS / GCP admin console: possibly completely inaccessible

A new dividing line emerges, what works vs. what doesn’t depends on where the service’s “brain” is located.

The key feeling at this phase is “unfairness”: why are some things recovering while others are getting worse? LINE text recovers because ISPs start traffic management, giving messages high priority. SaaS and cloud admin consoles are completely dead because their “control planes” are overseas. Next, we explain in two parts: (1) what ISPs are doing, (2) the “brain overseas” problem of cloud services.

What Are ISPs Doing Behind the Scenes?

Imagine an emergency room 🏥

During a major disaster, a surge of patients floods the ER, doctors are limited, can’t treat everyone at once, so the ER uses triage.

Using the ER analogy to explain ISP traffic engineering. After the cable break, international bandwidth is halved, but traffic demand hasn’t decreased, like a surge of patients but not enough doctors. ISP network engineers must manually intervene to decide which traffic gets priority. This is the internet’s version of “triage.”

Triage: Who Gets Treated First?

🔴 Likely highest priority

DNS queries
Government websites
Instant messaging (LINE text)
Financial transactions

🟡 Likely secondary priority

General web browsing
Email
Low-resolution streaming

🟢 Likely deferrable

YouTube HD
Instagram images/video
Software updates
Cloud backups

ISP engineers may manually intervene, deciding whose packets get priority, this is why some things “recover” while others get even slower.

ISP traffic management (traffic engineering) is mostly automated under normal conditions. But during a submarine cable event, engineers manually intervene to set QoS (Quality of Service) rules. DNS and government websites get the highest priority because DNS is the foundation of all internet services. Instant messaging (LINE text) has small traffic volume but high public impact, so it also gets priority. YouTube and Instagram images/video have massive traffic volumes (high percentage of total traffic) and get deprioritized. This is why you see YouTube quality plummet and Instagram show only text without images.

Why Might LINE Text Be Working Again?

1️⃣ LINE text messages = relatively small packets, one text message is about 1 KB, one Instagram photo is about 2,000 KB, a 2,000x difference.

2️⃣ ISPs may have listed messaging as high priority, small packets + local routing + high priority = can possibly squeeze through ✅

Instagram images? Large packets + overseas source + possibly deprioritized = possibly spinning 🖼️

LINE text recovery is due to three compounding factors: (1) Extremely small packets, text messages use negligible data; even under extreme congestion they can squeeze through. (2) LINE has peering connections at TPIX (Taiwan Internet Exchange), meaning much of LINE’s text messaging actually routes domestically, not even needing submarine cables. (3) ISP traffic management lists instant messaging as high priority, ranked first in triage. All three factors combined, LINE text messages recover. By contrast, Instagram photos are often several MB, sourced overseas, and deprioritized, hence only gray boxes.

Your Internet May Not Be Broken, It May Be “Managed”

🚦 ISP engineers = traffic officers at an intersection

Normal times: green light, all cars pass, you don’t even notice the traffic officer.

Crisis times: officer steps out to direct 🖐️, “Ambulance goes first! Bus can pass! Private cars wait!”

Your YouTube may not be “broken”, it might have been asked to yield to more important traffic.

The key point here is understanding: the “partial recovery” you’re experiencing isn’t random, it’s the deliberate result of ISP engineer decisions. ISPs have the ability to differentiate types of traffic and set priorities. You never notice normally because there’s enough bandwidth for everyone to pass. But when bandwidth tightens, ISPs’ “choices” directly determine what you can and can’t use.

What Does This Mean? Something You Should Know

ISPs have the capability to classify and manage traffic, they know which packets go where and what type they are

This means ISPs' everyday routing decisions are also "choices", choosing to route your traffic overseas and back instead of peering locally

If ISPs can choose who to save in a crisis, it means ISPs are also choosing who to sacrifice in normal times

This is the core insight of the ISP traffic management section. Everyone just saw that ISPs have the ability to classify and prioritize traffic during a crisis, which means ISPs also have this ability during normal times. The Trombone Effect from Phase 2, where ISPs route local traffic to Tokyo and back, isn’t a technical limitation, it’s a cost-driven choice. Not peering locally at TPIX is also a choice. This section connects Phase 2’s critique with Phase 4’s observation: ISPs aren’t passive pipes, they’re actors with capability, choices, and accountability.

Next: The Cloud Problem

LINE text may be back, some web pages may be viewable, but SaaS tools and cloud services may be completely dead.

To understand why, we first need to understand one thing: what exactly is “the cloud”? ☁️🤔

Transitioning to the cloud control plane section. Many people’s understanding of “the cloud” stays at a vague level, “data is stored on the cloud.” We need to explain “the cloud” clearly before we can explain why “cloud in Taiwan” ≠ safe.

“The Cloud” Is Actually… Someone Else’s Computer

You’ve heard “data is stored in the cloud” ☁️, sounds light, abstract, floating in the sky.

The truth: your data is stored on someone else’s computer. That computer sits in a massive building with air conditioning, security, and backup generators. That building is called a “data center.”

Taiwan has such buildings 🏢, both AWS and GCP have data centers in Taiwan. Your data does physically reside on Taiwan’s soil ✓

First, breaking the abstraction of “the cloud.” Many people hear “cloud” and think data floats in some ethereal space. But the cloud is someone else’s computer, housed in large data centers. AWS launched a Taiwan region in 2022 (with data center in Banqiao, New Taipei). GCP also has a data center in Changhua. So “data is in Taiwan” is physically true, but what follows explains why that’s not enough.

The Factory and Headquarters

Imagine a multinational corporation that built a factory in Taiwan:

🏭 Taiwan factory

Produces goods (stores your files)

Ships to customers (responds to your requests)

Warehouse has raw materials (your data)

→ This is the "Data Plane"

🏢 US headquarters

Issues employee badges (identity auth, IAM)

Approves budgets (resource provisioning)

Signs contracts (SSL certificates)

→ This is the "Control Plane"

Factory is in Taiwan ✓　But every important decision requires calling headquarters

Cloud services split into two layers: (1) Data Plane: where data is actually stored and processed, this is in Taiwan. (2) Control Plane: management, authentication, authorization, provisioning, this is usually in the US. Many of AWS’s control plane core functions are concentrated in us-east-1 (Virginia). GCP’s global control plane has a similar centralized design. The factory can produce goods, but without headquarters’ authorization, the factory can’t open its doors, can’t ship, can’t do anything.

Factory in Taiwan, but the Key May Be in the US

🔑 Employee needs to enter the factory (you need to log into AWS) → may need to verify identity with US headquarters (IAM authentication) → request travels via submarine cable to Virginia → timeout

📋 Factory needs to ship (website needs to renew security certificate) → may need US headquarters to sign the contract (SSL certificate validation) → request travels via submarine cable → timeout → HTTPS connection fails

📞 Customer wants the factory’s address (DNS resolution) → address book may be in the US (Route 53 is in us-east-1) → query travels via submarine cable → timeout → can’t find the factory

Factory intact, materials stocked, machines running, but the doors just won't open

Three concrete scenarios illustrating control plane dependency impacts: (1) IAM (Identity and Access Management), AWS’s identity verification system. Logging into the AWS Console or API calls all require IAM verification. IAM’s core service is in us-east-1. During submarine cable congestion, verification requests time out, and you can’t log in. (2) SSL/TLS certificates, HTTPS connections require valid security certificates. Certificate verification and renewal need to connect to overseas CAs (Certificate Authorities) or AWS Certificate Manager (also in us-east-1). Certificate expires and can’t renew → HTTPS connection can’t be established. (3) Route 53, AWS’s DNS service. If your website uses Route 53 for DNS, your “address book” is in the US. DNS query timeout → can’t find your website. The common conclusion across all three scenarios: your data and servers are in Taiwan, but “the key to open the door” is in the US.

Your Data Is Right Here, but You Don’t Have “Authorization” to Open It

🔐

Your Google Drive files may physically reside in GCP's Changhua data center

But you just can't open them

Because you may need a US server to confirm authorization

It’s like putting a safe in your house but leaving the key at a bank overseas 🏦, the bank is operating normally, but you can’t make an international call anymore.

The safe/key analogy is very intuitive: if the key isn’t at home but overseas, you wouldn’t think “the safe is at home so it’s secure.” But this is exactly the current state of most Taiwanese enterprises’ cloud architecture, data in Taiwan, but authorization mechanisms overseas. The December 2021 AWS us-east-1 outage was a precedent: other physically healthy AWS regions were also affected because IAM, Route 53, and other control plane services are concentrated in us-east-1. That incident wasn’t a submarine cable issue, it was us-east-1 itself having problems, but the effect was identical: your region is fine, but the control plane is down, so you go down too.

“Cloud in Taiwan” ≠ Safe

🏭

Factory in Taiwan

✓

🔑

Key in the US

✗

📞

Phone line jammed

✗

“We use Taiwan’s AWS/GCP” may ≠ “our services will still work when international traffic drops significantly”

This is the core conclusion of the cloud control plane section. Many enterprises and government agencies, when answering “is your service resilient?”, say “we use the Taiwan AWS region” or “our GCP data center is in Changhua.” But that only means “the factory is in Taiwan”, not “the key is also in Taiwan.” If the control plane depends on overseas infrastructure, then when submarine cables are severed, your service goes down with them. “Taiwan cloud” creates a false sense of security, this is the most critical misconception that needs to be shattered.

Winners: Truly Domestic-Only Services

In this simulation, some services may be completely unaffected.

✅ Services that survive look like this:

Server in Taiwan

Authentication (Auth) in Taiwan

Authoritative DNS server in Taiwan

CDN origin in Taiwan

The entire dependency chain stays on the island → submarine cable status is irrelevant

The emphasis here: surviving a submarine cable event isn’t just about “having a server in Taiwan.” Your entire dependency chain, server, authentication, DNS, CDN origin, must all be in Taiwan. Any single link depending on overseas infrastructure is a weak point. Services completely unaffected in this simulation are those that “chose” to make every layer domestically self-sufficient. That’s not coincidence, it’s a deliberate architectural decision.

What’s the Difference? One Table

	Server	Auth	DNS	CDN Origin	During Cable Break
Fully domestic stack	🟢 Taiwan	🟢 Taiwan	🟢 Taiwan	🟢 Taiwan	✅ Normal operation
Taiwan cloud	🟢 Taiwan	🔴 US	🔴 US	🟢 Taiwan	⚠️ Runs but can’t log in
Fully overseas	🔴 Overseas	🔴 Overseas	🔴 Overseas	🔴 Overseas	❌ Completely down

Most Taiwanese enterprise services fall in the middle row, appears to be in Taiwan, but dependencies are overseas.

This table makes the differences across three architectures immediately clear. The focus is the middle row, “Taiwan cloud.” Most Taiwanese enterprise and government services fall here: server indeed in Taiwan (AWS Taiwan region, GCP Changhua), but authentication, DNS, and even some CDN logic depend on overseas control planes. This gives the illusion of “being in Taiwan,” but during a submarine cable event, it still breaks. This is also the most dangerous state, because until something goes wrong, nobody examines these hidden dependencies.

Is It a Technical Limitation?

Those services that survived didn’t get lucky, someone chose to spend extra time, extra money, and make every layer domestically self-sufficient.

“If the submarine cables broke, would our services still work?”

This is the most important message of this section: resilience is a choice, not fate. The default configuration of AWS and GCP naturally depends on overseas control planes, because these are global services, that’s a reasonable default. But if you operate critical services in Taiwan, you need to proactively change that default. Most enterprises haven’t done so, not because they can’t, but because nobody asked the question. This is also why we need policy and regulations to drive change, because relying on corporate self-awareness alone isn’t enough.

Simulation Recap

Phase	Your Experience	Possible Cause
0–5 min	VoIP calls drop	BGP reconvergence + call control server in Japan
5–30 min	Everything slows, freezes	Congestion collapse + Trombone Effect
30–60 min	Services drop one by one, logouts	Cache TTL expiry, Token expiry, DNS failure
1–6 hr	Cloud admin consoles all down	Control plane depends on overseas

Building the complete causal chain: experience → technical cause → decision-makers. The point is to show that no failure is a “natural phenomenon”, every one is the result of some organization’s engineering or policy choices.

Simulation Complete

All stakeholders need to conduct a network outage drill.

🤔 Questions for Everyone

In the scenario we just walked through, would government websites (gov.tw) hold up?
http://poslab.info/slide/20260325

How are the submarine cables doing right now?
https://drive.google.com/file/d/1n9mbFNVeukMt3g_ywP8ne9366JWWhnT5/view

Cyborg Resilience Co-lab — Ideas

The 2026 Urban Resilience Exercise: Your 30-Minute Network Survival Guide

Change 3 settings

Take 3 kinds of screenshots

Make 3 agreements

14:20 on the day: a 3-minute wrap-up

14:30–15:00: how to spend these 30 minutes

After 15:00

Why Run a Mobile-Network Throttling Drill? Is There Any Point?

References

CRC Digital Resilience Forum: Simulating a Drastic Drop in Taiwan's International Internet Traffic

Topic Outline

Phase 1: Why Did Voice Calls Suddenly Drop?

What You Might Experience

“Is It the Wi-Fi Router or the Internet?”

What Is the Internet, Really?

How Does a Post Office Know Where to Send a Letter?

Cables Cut = Routes Cut

The Chaos of Rerouting

To You, It Probably Feels Like, Everything Is Down

LINE Voice May Drop, but Text Might Survive?

Phase 2: Zombie Internet

What You Might Experience

Wait, Wasn’t the Route Fixed?

Imagine a Highway

The Chain Reaction of Gridlock

Understanding It Through Letters

What Your Experience Might Look Like

The Next Problem Is Even Stranger

🏪 The Convenience Store Story

But Some ISPs Say…

Why Do Some ISPs Route This Way?

You Don’t Notice Under Normal Conditions

Result: Server Right Next to You, but You Can’t Connect

Two Main Bottlenecks of This Phase

But It May Get Even Worse…

Phase 3: It Was Just Working, Why Is It Broken Again?

What You Experience

Back to the Convenience Store

Expiration Date: TTL

The Convenience Store Can’t Restock

Why Can Some Things Load but Not Others?

What Is an Auth Token?

The Stamp on Your Hand = Auth Token

But the Stamp Fades

Stamp Faded? Go Back to the Ticket Booth

The Ticket Booth Is Across the Ocean

Everyone Gets Logged Out at Different Times

The True Face of a Token

The Life of a Token

Why Not Issue a Permanent Pass?

The Chain Reaction During a Cable Break

Your Apps May Be Logging Out One by One

Next Up: DNS

What Is DNS? The Internet’s Phone Book

How Does DNS Lookup Work? Like Calling Directory Assistance

DNS Cache Also Has an Expiration Date

DNS Cache Expires = Can’t Find the Address

Phase 4 and Beyond: Control Plane Depends on Overseas

What You Experience

What Are ISPs Doing Behind the Scenes?

Triage: Who Gets Treated First?

Why Might LINE Text Be Working Again?

Your Internet May Not Be Broken, It May Be “Managed”

What Does This Mean? Something You Should Know

Next: The Cloud Problem

“The Cloud” Is Actually… Someone Else’s Computer

The Factory and Headquarters

Factory in Taiwan, but the Key May Be in the US

Your Data Is Right Here, but You Don’t Have “Authorization” to Open It

“Cloud in Taiwan” ≠ Safe

Winners: Truly Domestic-Only Services

What’s the Difference? One Table

Is It a Technical Limitation?

Simulation Recap

Simulation Complete

🤔 Questions for Everyone

Further Reading