Junhao Su’s work gets described in one plain line: a machine-learning framework that connects performance prediction to Android communication reliability. That’s it. No product launch, no benchmark chart, no press tour. And yet I read that sentence three times, because it names the exact problem I’ve been duct-taping around for years.
I build bots. A lot of them end up on phones, or talking to phones, or relaying messages through a phone that someone left in a pocket on a train. The code is usually fine. The network is the villain. And the way most of us handle it is embarrassingly dumb: send, fail, wait, retry, wait longer, retry again, give up, log something vague. We treat the connection as a coin flip we can’t see until after it lands.
Su’s framing flips the order of operations. If you can predict performance, you can act before the failure instead of apologizing after it.
Why prediction beats retrying
Think about what a retry loop actually is. It’s a confession that your app has no model of the channel it’s using. Exponential backoff is a decent fallback and a terrible strategy, because it’s identical whether the phone is in an elevator, hopping between cell towers, or sitting on strong Wi-Fi with a momentarily busy server.
A predictive layer changes the available moves. Instead of one behavior, you get a menu:
- Downshift payloads when the near-term outlook is poor — drop the image, send the text, sync the rest later.
- Pre-fetch aggressively when conditions look good, so the bot has answers cached before the user needs them.
- Delay non-urgent telemetry instead of racing it against the message the user actually cares about.
- Switch transport or endpoint proactively rather than after three timeouts have already burned twelve seconds.
- Change what you tell the user, because “reconnecting” and “you’re offline, I saved your draft” are very different experiences.
None of that requires perfect prediction. It requires a signal that’s better than a coin flip, which is a much lower bar than most engineering conversations assume.
The second entry on the résumé matters too
Su also shows up as a co-author on a technical session at IEEE INFOCOM 2026, on optimizing split federated learning through adaptive pipeline parallelism. Different topic on paper. Same underlying headache in practice.
Split federated learning means the model gets cut in pieces across devices and servers, with training happening in a chain rather than in one place. Pipeline parallelism is how you keep every stage of that chain busy instead of idle. Adaptive pipeline parallelism means the shape of that schedule adjusts to what’s actually happening.
And what’s actually happening, for anyone running this on real phones, is network variance. A pipeline is only as fast as its slowest link, and on mobile the slowest link is rarely compute. It’s the hop between device and server. Work on communication reliability and work on adaptive pipelining are two views of the same question: how do you build a system that assumes the connection is a moving target?
What I’d actually build with this
I’m not going to pretend I know the internals of Su’s framework. The public description is a single sentence, and I’d rather say that plainly than invent details. But the direction is clear enough to act on, and you can start today with tooling you already have.
Start logging the boring stuff
Most mobile bot projects throw away the exact data a predictor would need. Round-trip times, radio state changes, request sizes, retry counts, time of day, which endpoint, whether the screen was on. Capture it, timestamped, before you have any model at all. You cannot predict what you never recorded.
Ship a stupid model first
A small classifier over recent request outcomes is often enough to pick between “send now” and “queue it.” Run it on-device, keep it cheap, and treat it as a hint rather than a verdict. The value isn’t accuracy, it’s having a decision point where you previously had a hardcoded timeout.
Make graceful degradation a real feature
Prediction is worthless if your app only knows one way to behave. Build the degraded paths first — the queued message, the cached reply, the compressed upload — then wire the model in to choose between them.
Su’s research is a small item in a busy week of AI news, and the sources don’t say much beyond those two contributions. Fine. The idea still deserves attention from anyone shipping bots to phones, because it treats the network as something you can reason about instead of something you endure. That’s a better starting assumption than the one most of our retry loops are built on.
🕒 Published: