Paper summary
Isolate control traffic before bursts interfere
Predicting each virtual switch’s control traffic helps a shared network hypervisor allocate its processing capacity.
Virtual switches share the network hypervisor’s message-translation resources. Bursts from one control channel can delay another, so Meteor assigns each virtual switch a separate processing quota based on its predicted traffic.
Predict and enforce a quota per switch
A traffic meter collects recent control traffic and topology features. An LSTM autoencoder predicts the next time window, and a switch tap converts the prediction into a translation quota. Messages above the quota are buffered and processed when capacity becomes available.
View full-size figureCompare isolation and prediction windows
The implementation builds on Libera and compares prediction accuracy, control-channel isolation and processing overhead. Tests with 8–128 virtual switches compare Meteor with Libera and a reactive quota scheme for forwarding setup and network monitoring. A two-second window balances prediction accuracy and control-processing delay in these experiments.
| Component | Role |
|---|---|
| Traffic meter | Collect recent traffic and topology features |
| LSTM autoencoder | Predict demand in the next window |
| Switch tap | Convert demand into a translation quota; buffer excess messages |
Key takeaways
- Control-channel isolation depends on anticipating unequal demand. Per-switch predictions turn a shared processing budget into differentiated allocations.
- Prediction alone cannot contain a burst. Buffering during translation is what turns the estimated allocation into enforced isolation.