QUICShift

Architecture.png

Inspiration,

"In Formula 1, telemetry data doesn't get a second chance."

Watching DRS telemetry stream from cars at 300 km/h, studying how radio frequencies cut through interference for critical pit calls—I learned that when stakes are high, ordinary file transfer fails.

QUICShift brings Formula 1-grade reliability to everyone: intelligent data transfer that adapts, predicts, and never quits.

What it does,

QUICShift enables blazing-fast, resilient file transfer over unstable networks perfect for mission-critical scenarios like F1 telemetry, medical imaging, and disaster response.

The Problem: Traditional protocols fail on unstable links. TCP is super slow. UDP loses data. You need both speed AND reliability.

Our Solution: Built on QUIC protocol (combines TCP's reliability with UDP's speed), QUICShift intelligently adapts to network conditions in real-time.

How we built it,

First we understood how the telemetry data is transferred data is transferred in formula one settings

Chunking rust // Process chunks across multiple CPU cores file.par_chunks(chunk_size).for_each(|chunk| { compress_and_queue(chunk) }); ### 2. Adaptive Transfer Controller

Our core engine monitors network quality every 2 seconds and decides:

Chunk size: 16KB (poor network) → 512KB (excellent network)
Batch size: How many concurrent tokio tasks to spawn
Compression: Heavy (slow network) vs. light (fast network)

fn adapt_strategy(network: &Metrics) -> TransferStrategy {
    let quality_score = calculate_network_quality(network);

    TransferStrategy {
        chunk_size: BASE_SIZE * quality_score,
        concurrent_tasks: (quality_score * MAX_TASKS) as usize,
        compression_level: if quality_score < 0.5 { 9 } else { 1 }
    }
}

3. Concurrent Transfer with Tokio

Spawns optimal number of async tasks based on network capacity on the node:

// Dynamically spawn tasks
for chunk in chunks.take(concurrent_tasks) {
    tokio::spawn(async move {
        transfer_with_retry(chunk).await
    });
}
```

4. Multi-Layer Integrity Checks

Per-chunk: Blake3 hash verified on arrival when the data is received on the system.
Rolling hash: Cumulative verification during transfer
Final check: Complete file hash at end.

So Basic flow is like this

Technical Flow

File → Rayon (parallel chunking) → Adaptive Controller (analyse network) → Tokio (spawn N concurrent tasks) → QUIC (multi-path transfer) → Blake3 (verify each chunk) → Reassemble with integrity check eg.

time 0s: WiFi excellent → 512KB chunks, 16 concurrent tasks
time 30s: WiFi drops → 64KB chunks, 4 tasks, switch to cellular
ttime 60s: WiFi returns → Resume 512KB chunks, 16 tasks

Challenges we ran into,

Recreating Formula 1-grade network instability wasn’t easy. We wanted to feel the chaos of real telemetry drops, so we simulated race conditions using open-source telemetry mods from Assetto Corsa, rFactor 2, and SimHub.

We faced three major challenges:

Realistic network jitter simulation: Crafting a reproducible model of radio drop-outs and latency spikes.
Adaptive logic calibration: Ensuring QUICShift reacted fast enough without becoming unstable.
Cross-platform performance: Although we mostly did testing on linux, Balancing low-level Rust concurrency with high-level async abstractions in Tokio and QUIC.

Tuning those three together in rust was like optimising a pit-stop every millisecond mattered.

Accomplishments that we're proud of,

Even though QUICShift is still evolving, a few milestones stand out:

Resilient data flow: Our adaptive controller handled 35% packet loss with zero corruption.
Seamless recovery: Transfers resumed automatically after simulated radio blackouts in the game.
CPU-level optimization: Rayon-based chunking gave us up to 4× throughput improvement on multi-core systems. we used a INTEL Ultra 9 185H based system. although this mobile processor is not really a embedded level device, it clearly showed the potential of multi-core data processing.

And beyond code, we’re proud that this project united systems programming, real-time networking, and Formula 1 telemetry into one coherent idea.

What we learned,

This journey taught us that speed isn’t everything — consistency under pressure is.

We learned how:

QUIC’s multiplexing can outperform TCP even on lossy 4G networks.
Adaptive compression can save bandwidth dynamically.
Hash verification (Blake3) ensures trust in every byte.
Real-time telemetry demands not just fast protocols, but intelligent orchestration.

And, most importantly, data transfer at 300 km/h is less about code and more about control.

What's next for Untitled

We’re just getting started. Upcoming milestones include:

End-to-end encryption layer built directly over QUIC streams.
Progressive compression engine — AI-guided choice of codec (Zstd, Brotli, LZ4) depending on data entropy.
Mobile SDKs for Android/iOS to bring QUICShift to field data collection.
Visualization dashboard — real-time analytics of throughput, latency, and reliability metrics.
Integration with object storage (S3, MinIO) for large-scale deployments.

Our vision: make Formula 1-grade reliability the new normal for everyone moving critical data — from racetracks to remote hospitals.