Cloud rendering replaces local 3D rendering with a video loop. The phone sends a tap, drag, or pinch gesture; a server updates the scene, encodes the next frame, and returns it through WebRTC. This lowers device compute and download requirements, but it makes motion-to-photon delay a direct part of shopping interaction. A rate controller must decide how much of estimated bandwidth to spend on image quality without creating an encoder or pacing queue.
Alibaba’s measurements show that the objective changes inside one session[1]. When a user rotates or zooms an object, responsiveness matters more than fine visual detail. When the user stops to inspect it, bitrate can rise without the same latency penalty. Existing controllers apply one fixed quality-latency policy to both phases. They are most likely to build a queue during motion because motion frames are 22% larger on average, and their p99 latency is 1.9 times the non-motion value.
MARC turns that observation into a frame-level controller. It predicts whether the next frames belong to a motion sequence, estimates pacing rate and round-trip time, and selects bitrate for a ten-frame window. The optimization assigns a higher latency penalty during motion and a more quality-oriented objective during inspection. It runs entirely on the server and leaves the mobile client unchanged.
A behavior signal above congestion control
Congestion control and rate control solve related but different problems. A WebRTC congestion controller estimates how much traffic the path can carry. The encoder rate controller decides how much video to produce under that estimate. Keeping a fixed safety margin prevents queue growth, but it wastes visual quality whenever the path has headroom. Using the entire estimate improves quality until one oversized frame or a bandwidth drop creates a queue that delays the following frames.
MARC does not replace the congestion controller. It receives the current pacing rate, send-queue length, and RTT, then adds a user-state signal. The server already receives input events for rendering, so a drag or zoom can mark motion without extra client instrumentation. A small predictor uses recent frame states to estimate the next sequence. A model then projects queue evolution, frame send time, network propagation, quality, and latency over the near future.
The objective accumulates frame quality minus latency penalties. Separate coefficients express the general sensitivity to latency and the extra sensitivity during motion. If a large frame fills the queue, its cost appears not only in its own delay but in every following frame that waits behind it. The optimizer therefore reduces upcoming bitrate before a purely reactive controller would observe a latency spike. During stable non-motion periods it can spend more of the available rate on detail.
The implementation uses sequential least-squares programming. With a ten-frame window, average optimization time was 24.6 microseconds and the maximum was 5.4 milliseconds, below the 33-millisecond interval at 30 frames per second. The choice matters because another tested solver was faster for very short windows but sometimes reached its iteration limit as the window grew. Production control needs a bounded answer, not just a lower average.
What the traces say about prediction
The offline dataset covered more than 200,000 sessions and 1.8 billion frames collected from February 23 through March 27, 2024. Motion accounted for only 3.4% of frames. A predictor can therefore report high overall accuracy by guessing “no motion” most of the time. The paper reports 94% to 96% next-frame classification as history grows, but the more revealing result is motion-start accuracy and recall of only about 36.8% and 36.7%.
The controller remains useful because motion tends to continue once it begins. Prediction accuracy for frames after the initial motion improves by 72%. A first frame may arrive before the model anticipates the gesture, but subsequent frames in the drag or rotation can receive a lower bitrate before their queue accumulates. Removing motion prediction doubled median send duration in the trace experiment, while predicted sequences tracked ground truth closely.
Prediction errors have a quality cost. About 2% of non-motion frames were classified as motion, and their median target bitrate was 3% below the ground-truth case. Motion-frame target bitrate was 5% below ground truth. MARC therefore does not obtain latency reduction for free; it spends a small amount of quality when uncertain. The correct comparison is the joint latency-quality frontier, not latency alone.
Offline results separate the mechanism from product effects
Trace-driven simulation compared MARC with WebRTC’s controller and several interactive-video strategies. At similar visual quality, MARC reduced p95 motion-frame queueing plus send duration by 30% to 55%. At similar latency, one selected configuration raised average bitrate 35% over Duo and reduced p95 motion-frame latency by 33 to 101 milliseconds across baselines.
Across all frames, varying the general latency coefficient traced a better quality-latency frontier. At comparable target bitrate, p95 frame latency was 22% to 60% lower. Median modeled session QoE was 3% to 36% higher than the compared algorithms, and p95 QoE was 1.3% to 21% higher. These values depend on the paper’s learned QoE functions, so they establish internal consistency rather than a universal user-satisfaction unit.
The video-quality test used 500-frame clips under multiple network traces. MARC scored 47.74 dB PSNR versus 48.13 for WebRTC, SSIM 0.9933 versus 0.9937, and phone-model VMAF 95.7 versus 96.4. Average throughput demand differed by less than 3%. The small reductions confirm the expected exchange: MARC suppresses bitrate around motion to prevent queue buildup, and objective quality decreases slightly.
One million sessions test the product outcome
Alibaba deployed MARC on Taobao’s mobile cloud-rendering service and randomly assigned requests to MARC or the default WebRTC rate controller. The A/B test ran from April 4 through April 11, 2024 and included more than one million sessions. That scale makes the engagement result more credible than a laboratory trace, although it remains one product and one user population.
MARC reduced frame latency by 29% at the median and 20% at p99. The share of motion frames whose motion-to-photon latency exceeded 150 milliseconds fell 20%. Average session freeze rate fell 71%. User session duration increased 9%, and the fraction of session time spent interacting rose 20%. These engagement metrics cannot prove a direct revenue increase, but they show that the network-level improvement changed behavior rather than only a server counter.
All added work stayed on the server. The optimization increased absolute CPU utilization by 1.3 percentage points per session. The evaluated rendering node was already limited to roughly ten sessions per GPU, leaving CPU below the capacity boundary. A CPU-constrained service would need a different calculation; 1.3 points multiplied across many sessions can become a scheduling or cost constraint.
Motion awareness is a policy, not a new transport
MARC is portable to cloud desktops, remote design tools, and VR or AR streams that alternate between manipulation and inspection. Porting requires more than detecting mouse or controller input. The operator must relearn how the target users trade delay against quality and recalibrate the objective. A medical viewer, a game, and a shopping catalog can assign different penalties to the same 150-millisecond delay.
The system also assumes that near-term pacing rate and RTT are sufficiently stable. The paper finds low variation across the first frames of observed motion sequences, but abrupt wireless changes or a long existing queue can invalidate that projection. More sophisticated forecasting may help, yet a larger model must still finish within one frame interval and remain safe when its prediction fails.
Frame bitrate is an indirect control. Encoders may overshoot a target on complex scenes, and MARC uses existing APIs rather than modifying codec internals. Fine-grained quantization or re-encoding could make the action more precise at additional compute cost. Loss recovery and last-mile scheduling remain separate sources of motion-to-photon latency.
The reusable systems lesson is to place the objective at the timescale where user value changes. A single session is not one workload class. The path capacity may be unchanged while the relative cost of latency and quality flips from frame to frame. MARC demonstrates that an application signal already present in the control loop can guide resource allocation, provided the evaluation reports prediction misses, visual-quality loss, server overhead, and online behavior alongside the headline latency reduction.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the paper’s measurements, controller, and limitations in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX ATC 2025 presentation page. Copyright remains with the authors, 2025.