Pith. sign in

REVIEW 3 major objections 5 minor 55 references

MOSE: A Novel Orchestration Framework for Stateful Microservice Migration at the Edge

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that stateful edge-microservice migration can be implemented and orchestrated together, preserving the client connection and automatically configuring strategy, bandwidth, and iteration count to meet KPI targets, cutting…

desk verdict A genuinely useful orchestration layer, but the headline numbers rest on a weak baseline and a self-cited model that needs stronger validation. read the letter →

arxiv 2506.09159 v2 pith:CZFOO34V submitted 2025-06-10 cs.NI

Antonio Calagna , Yenchia Yu , Paolo Giaccone , Carla Fabiana Chiasserini This is my paper
classification cs.NI
keywords edgecomputingservicemigrationstatefulcontainerliveorchestrationmobilenetworkscomputervisionmachinelearning
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that stateful migration of edge microservices can be both implemented cleanly and configured automatically, and it introduces MOSE to do both. MOSE preserves the live connection between a moving client and the migrated service while an orchestrator chooses the migration strategy, the network bandwidth, and the number of pre-copy iterations so that operator-set targets on migration duration and downtime are met. The authors validate MOSE on benchmark microservices and report up to 77% lower migration downtime than the state of the art, and they show it meeting KPI targets for a UAV autopilot service and a multi-object-tracking service. If the claim holds, stateful migration stops being a manually tuned, service-specific operation and becomes a configurable edge resource.

What carries the argument

The load-bearing piece is the PAM model, an analytical model of stateful-migration KPIs that predicts migration duration and downtime from state size, dirty-page rate, bandwidth, and per-step processing costs, with parameters calibrated by the DPRGen benchmark. Around it, COAT is the connection-preservation mechanism: an Open vSwitch overlay that recreates the container's network namespace at the destination and updates the network flow so the client connection survives migration. The third component is the Migration Designer algorithm, which feeds PAM predictions and the requested objective into the configuration algorithm and outputs the strategy, the bandwidth to reserve, and, for Iterative PreCopy, the number of iterations. MOSE agents exchange these commands over the Zenoh protocol instead of SSH, which is the source of much of the measured speedup.

What would settle it

Run MOSE on a memory-intensive microservice whose dirty-page rate varies over time and record whether the measured migration duration or downtime ever exceeds the PAM-computed upper bound for the configuration MOSE selected; one such violation would break the safety guarantee that the configuration meets the target.

Watch

Extended reading notes

Core claim

The central claim is that one framework can jointly implement stateful container migration, migrate the client connection transparently, and orchestrate migration parameters against explicit KPI targets. MOSE combines COAT, an overlay-network procedure that moves the network namespace and redirects traffic, with PAM, an analytical model that predicts upper bounds on migration duration and downtime. The orchestration algorithm uses those predictions to select between Cold Migration, PreCopy, and Iterative PreCopy, to compute the minimum bandwidth that meets a downtime target, and to set the number of pre-copy iterations that meets a duration target. In the reported experiments, the measured downtime and total duration stay below the predicted upper bounds, and MOSE reduces downtime by up to 77% relative to state-of-the-art scripted migration.

Load-bearing premise

The orchestration decision stands on the assumption that the PAM model, with the dirty-page rate set to its maximum, gives a valid upper bound on migration duration and downtime for arbitrary microservices, so the strategy, bandwidth, and iteration count MOSE selects actually meet the KPI target.

Editorial extensions

If this is right

  • Operators can specify a target migration duration or a target downtime and receive a concrete migration configuration without manual tuning.
  • Because the client connection is migrated without protocol or kernel changes, stateful migration can be applied to existing microservices rather than only to services written for migration.
  • For the validated workloads, measured KPIs stay below the PAM upper bound, meaning the framework reliably over-reserves migration resources instead of violating a target.
  • The reduction of migration steps from seconds to sub-seconds makes stateful migration viable for latency-critical services, such as the UAV autopilot where trajectory error drops by up to 97%.
  • When the objective is resource minimization, MOSE selects the lowest bandwidth that still meets the downtime target, cutting allocated bandwidth by up to 91% in the multi-object-tracking use case.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the PAM upper bound generalizes to services not in the validation set, the same orchestration loop could be extended to migrating chains of microservices, deciding the order and the links over which to move them.
  • The framework currently assumes an existing bandwidth monitoring system for one of its inputs; equipping MOSE with its own periodic Zenoh probes would make deployment self-contained and testable.
  • Worst-casing the dirty-page rate is a safe but conservative choice; tracking dirty-page dynamics over time could tighten the bound and free bandwidth or allow more pre-copy iterations.
  • Because the migration scheduler is declared orthogonal, a natural next experiment is to couple MOSE with a mobility predictor that triggers migration just before a handover, aligning the migration budget with the radio trajectory.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. This paper proposes MOSE, a framework for stateful migration of microservice containers at the network edge. MOSE combines a CRIU/Podman-based migration procedure with an OvS-based overlay that preserves the client connection, and an orchestrator that uses the authors' previously proposed PAM analytical model to choose among cold migration, PreCopy, and iterative PreCopy and to set the migration bandwidth and the number of PreCopy iterations so that target KPIs (migration duration and downtime) are met. The experimental section reports per-step timings for SockPerf and iPerf3, showing large reductions relative to a script/SSH-based baseline, and two use cases (UAV autopilot and Ultralytics MOT) to demonstrate configuration under two objectives: minimize downtime and minimize resource usage. The central claims are that MOSE reduces migration downtime by up to 77% relative to the state of the art and that the PAM model provides an upper bound that lets the orchestrator meet KPI targets.

Significance. If the central claims hold, MOSE makes a useful contribution: it turns stateful container migration from a manually tuned, SSH-driven operation into an automatically configurable service with connection preservation, and it provides an experimental validation on realistic workloads, including an ML tracking service with a substantial dirty-page rate. The paper reports 90% confidence intervals over 100 repetitions and honestly notes that measured KPIs stay below predicted bounds. The main significance lies in the orchestration algorithm and its empirical validation rather than in the migration primitives themselves, which are largely inherited from the authors' prior COAT and PAM work. The absence of released code or data limits independent reproducibility but does not invalidate the reported experiments.

major comments (3)
  1. [Sec. IV-B/IV-C, Figs. 8, 10, 13-14] The orchestrator's KPI guarantees rest on treating PAM's prediction as an upper bound on T_mig and T_down, with the dirty-page rate set to its maximum value. PAM's parameters are estimated with the DPRGen benchmark from the authors' prior work [3], and the bound is validated only for SockPerf, iPerf3, the UAV autopilot, and the Ultralytics MOT MS. These are all network-oriented or ML-inference processes; the paper does not provide a derivation or empirical evidence that the bound holds for process-heavy or memory-intensive microservices with complex state structures such as many threads, many sockets, file descriptors, or workload phases. Since the orchestration algorithm may output a bandwidth or iteration count under a false bound and miss the target KPI, the manuscript should either prove the upper-bound property under stated assumptions or characterize its domain of validity, and should release the model code and parameters to make the claim independently testable.
  2. [Sec. V-B, Tables I-II; Sec. VI-A/VI-B] The baseline used for the headline 77% downtime reduction is a scripts/SSH-based migration procedure from the authors' own previous testbed [45], not a published migration framework. The text itself attributes the gains to replacing SSH with Zenoh and to direct Podman/OvS API calls, so the headline conflates implementation-level signaling improvements with the orchestration contribution. The comparison should be reframed as relative to the authors' prior script-based implementation, or augmented with a comparison against a published framework such as the proxy-based or Kubernetes-based approaches cited in Sec. II, to justify the phrase state of the art.
  3. [Sec. V-B, Tables I-II] The SotA Iterative PreCopy configuration, in particular the bandwidth and the number of PreCopy iterations, is not reported for the baseline. Without these parameters, the reader cannot determine whether the comparison is apples-to-apples with the MOSE configurations, for which I=8 and I=9 are stated explicitly. The authors should report the baseline configuration or explain why it is the natural published choice.
minor comments (5)
  1. [Sec. VI-B, Figs. 15-16] The probabilistic analysis assumes a truncated normal distribution of available bandwidth with 1 Gbps mean and 100 Mbps standard deviation; the paper should state explicitly that this is a synthetic illustration and justify the distribution parameters, since no empirical link measurements are provided.
  2. [Sec. II and Sec. IV-A] The claim that no existing framework jointly tackles the four listed challenges would be easier to evaluate with an itemized comparison against [17], [19], and [28], which also address orchestration or connection preservation; currently those works are described only briefly.
  3. [Tables I-II] The acronym MOSE-RM appears in Tables I and II while the rest of the paper uses MOSE-MR; the notation should be made consistent throughout.
  4. [Sec. V-C, Fig. 8b] The growing gap between predicted and measured migration duration as the number of PreCopy iterations increases is reported without discussion; a brief explanation of its cause and its implications for bound tightness would be useful.
  5. [Figs. 8, 10, 13, 14] The predicted curves are presented as point predictions without confidence intervals; the authors should clarify whether error bars are omitted intentionally or are unavailable for the model outputs.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: MOSE's orchestration predictions are validated against independent measurements on four microservices, so the self-cited PAM model is used as external, testable support rather than as a conclusion that reduces to its own inputs.

full rationale

The paper's central derivation is MOSE's orchestration algorithm (Sec. IV-C, Fig. 5), which uses the self-cited PAM model [3] to compute migration configurations (strategy, bandwidth, iteration count) and predicts upper bounds on migration duration and downtime. The potentially load-bearing self-citation is PAM, introduced by the same authors in [3], and its parameters are calibrated on the DPRGen benchmark from [3]. However, the paper does not stop at the model: in Sec. V-C and Sec. VI it compares PAM's predicted upper bounds against measured T_mig and T_down on SockPerf, iPerf3, a UAV autopilot MS, and an Ultralytics MOT MS. In every reported configuration, the measured values are below the predicted bounds, e.g., 'the measured migration duration is always shorter than the prediction thereof, thus validating the capability of PAM of providing an upper bound for such KPI.' This is an external, falsifiable test: the model parameters were not fit to these four microservices' migration durations, and the MS-specific inputs (state size, dirty-page rate) are measured independently of the predicted KPI. The worst-case dirty-page-rate setting is a conservative modeling choice, not a way of forcing the measured result. The remaining concern, that PAM's upper bound may not transfer to arbitrary, more complex microservices, is a correctness or generality risk, not a circularity: it does not make the reported predictions equivalent to their inputs by construction. The self-citations to [3] are load-bearing, but they are independently supported by the measurements in this paper, so they do not constitute circular reasoning under the stated rules.

Assumptions & free parameters 1 free parameters · 8 assumptions · 0 invented entities

The framework introduces no physical entities; its load-bearing components are the PAM model (a fitted model from the authors' prior work) and several domain assumptions about tool behavior, bandwidth estimation, and baseline representativeness. The central orchestration result therefore rests on calibration done outside this paper plus untested generality of the upper-bound property.

free parameters (1)
  • PAM model parameters = Not reported; estimated via DPRGen benchmark in [3]
    Migration Designer uses PAM to predict KPI upper bounds and to compute L and I (Sec. IV-C, Fig. 5). These parameters are calibrated in prior work, not derived here.
assumptions (8)
  • ad hoc to paper PAM model [3] provides valid upper bounds on migration duration and downtime for the tested and similar microservices.
    The orchestration algorithm (Fig. 5) uses PAM predictions to choose strategy, bandwidth, and iterations. This paper does not re-derive PAM; it validates the bound only on SockPerf, iPerf3, a UAV autopilot, and an Ultralytics MOT MS.
  • domain assumption Zenoh provides sufficiently low-latency, high-throughput pub/sub messaging to avoid SSH-like signaling overhead.
    Used in Sec. IV-B and IV-D to justify replacing SSH with Zenoh; performance claims for Zenoh come from cited benchmarks, not from measurements in this paper.
  • domain assumption CRIU checkpoint/restore and Podman APIs support the described stateful migration steps on the testbed.
    Standard tools assumed to work as documented in Sec. III; the whole framework depends on their behavior.
  • domain assumption Available bandwidth can be measured or estimated accurately by an existing monitoring system or Zenoh probes.
    Sec. IV-B assumes this without evaluating estimation error; the configuration algorithm depends on accurate L estimates.
  • domain assumption COAT/OvS overlay preserves the client connection transparently across migration.
    Based on the authors' prior COAT work [3]; it is central to the connection-preservation claim and is not independently verified by a third party.
  • domain assumption The scripts/SSH-based baseline used for state-of-the-art comparison is representative of published migration frameworks.
    The quantitative improvements in Tables I-IV compare MOSE against this baseline; if a more optimized published framework were used, the margins would change.
  • domain assumption A dedicated network slice isolates migration traffic at 1 Gbps between source and destination hosts.
    Sec. V-A: results depend on this link capacity and the isolation assumption.
  • domain assumption Dirty-page rate measured via CRIU's memory-change tracking is accurate and stable during migration.
    Profiling module uses a CRIU-based estimate (Sec. IV-B); the worst-case upper bound relies on this measurement.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MOSE: A Novel Orchestration Framework for Stateful Microservice Migration at the Edge." pith.science (2026). https://pith.science/paper/CZFOO34V

@misc{pith2026250609159,
  author       = {Pith},
  title        = {Pith review of: MOSE: A Novel Orchestration Framework for Stateful Microservice Migration at the Edge},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CZFOO34V}},
  note         = {Machine review of arXiv:2506.09159}
}
read the original abstract

Stateful migration has emerged as the dominant technology to support microservice mobility at the network edge while ensuring a satisfying experience to mobile end users. This work addresses two pivotal challenges, namely, the implementation and the orchestration of the migration process. We first introduce a novel framework that efficiently implements stateful migration and effectively orchestrates the migration process by fulfilling both network and application KPI targets. Through experimental validation using realistic microservices, we then show that our solution (i) greatly improves migration performance, yielding up to 77% decrease of the migration downtime with respect to the state of the art, and (ii) successfully addresses the strict user QoE requirements of critical scenarios featuring latency-sensitive microservices. Further, we consider two practical use cases, featuring, respectively, a UAV autopilot microservice and a multi-object tracking task, and demonstrate how our framework outperforms current state-of-the-art approaches in configuring the migration process and in meeting KPI targets.

Figures

Figures reproduced from arXiv: 2506.09159 by the authors.

Figure 2
Figure 2. Enhanced Stop&Copy stage for the stateful MS migration [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 1
Figure 1. Stateful MS migration under the Iterative PreCopy strategy. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 4
Figure 4. MOSE Agent and Orchestrator: modules and libraries. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (10 more)
Figure 5
Figure 5. Figure 5: Configuration algorithm executed by the MOSE orchestrator. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 7
Figure 7. Figure 7: Testbed setup for the MOSE framework. As an example, [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: MOSE-MD (a)-(b) and MOSE-MR (c)-(d) performance. (a) Number of iterations for varying target migration duration and measured [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: UAV autopilot MS migration reference scenario. [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 10
Figure 10. Figure 10: MOSE migration results for UAV autopilot MS (a) for [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]
Figure 12
Figure 12. Figure 12: Ultralytics MS performance vs. YOLO model size. [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]
Figure 13
Figure 13. Figure 13: MOSE-MD performance and configuration for varying target migration duration and YOLO model size. [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]
Figure 14
Figure 14. Figure 14: MOSE-MR performance and configuration for varying target downtime and YOLO model size. [PITH_FULL_IMAGE:figures/full_fig_p012_14.png]
Figure 15
Figure 15. Figure 15: MOSE-MD probability mass function for varying YOLO model size and target migration duration. [PITH_FULL_IMAGE:figures/full_fig_p014_15.png]
Figure 16
Figure 16. Figure 16: MOSE migration strategy probability for downtime minimization and for varying target migration duration and YOLO model size. [PITH_FULL_IMAGE:figures/full_fig_p014_16.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

55 extracted references · 51 canonical work pages

  1. [3]

    Design, model- ing, and implementation of robust migration of stateful edge microser- vices,

    A. Calagna, Y . Yu, P. Giaccone, and C. F. Chiasserini, “Design, model- ing, and implementation of robust migration of stateful edge microser- vices,”IEEE Transactions on Network and Service Management, 2023

    work page 2023

  2. [45]

    TCP Connection Management for Stateful Container Migration at the Network Edge,

    Y . Yu, A. Calagna, P. Giaccone, and C. F. Chiasserini, “TCP Connection Management for Stateful Container Migration at the Network Edge,” in IEEE MedComNet, 2023

    work page 2023

  3. [1]

    Migrat- ing enterprise legacy source code to microservices: On multitenancy, statefulness, and data consistency,

    A. Furda, C. Fidge, O. Zimmermann, W. Kelly, and A. Barros, “Migrat- ing enterprise legacy source code to microservices: On multitenancy, statefulness, and data consistency,”IEEE Software, 2018

    work page 2018

  4. [2]

    Erl,Service-Oriented Architecture: Analysis and Design for Services and Microservices, 2nd ed

    T. Erl,Service-Oriented Architecture: Analysis and Design for Services and Microservices, 2nd ed. USA: Prentice Hall Press, 2016

    work page 2016

  5. [4]

    Proxmox,

    D. Maurer and M. Maurer, “Proxmox,” https://www.proxmox.com/en/

    work page

  6. [5]

    Kubernetes,

    J. Bedaet al., “Kubernetes,” https://kubernetes.io/

    work page

  7. [6]

    Live migration of containerized microservices between remote Kubernetes Clusters,

    K. Kaur, F. Guillemin, and F. Sailhan, “Live migration of containerized microservices between remote Kubernetes Clusters,” inIEEE INFO- COM, 2023

    work page 2023

  8. [7]

    Edge computing in iot context: Horizontal and vertical linux container migration,

    C. Dupont, R. Giaffreda, and L. Capra, “Edge computing in iot context: Horizontal and vertical linux container migration,” inGlobal Internet of Things Summit (GIoTS), 2017

    work page 2017

Show all 55 references
  1. [8]

    Migration-based dynamic and practical virtual streaming agent placement for mobile adaptive live streaming,

    J. Liu, Q. Yang, G. Simon, and W. Cui, “Migration-based dynamic and practical virtual streaming agent placement for mobile adaptive live streaming,”IEEE Transactions on Network and Service Management, vol. 15, no. 2, 2018

    2018

  2. [9]

    Mobility aware and dynamic migration of mec services for the internet of vehicles,

    I. Labriji and et al., “Mobility aware and dynamic migration of mec services for the internet of vehicles,”IEEE Transactions on Network and Service Management, vol. 18, no. 1, 2021

    2021

  3. [10]

    Application agnostic container migration and failover,

    M. Terneborg, J. K. R ¨onnberg, and O. Schel ´en, “Application agnostic container migration and failover,” inIEEE Conference on Local Com- puter Networks (LCN), 2021

    2021

  4. [11]

    Evaluating distributed MPI checkpoint and restore using docker containers and CRIU,

    G. Berg, M. Brattl ¨of, A. Blancheet al., “Evaluating distributed MPI checkpoint and restore using docker containers and CRIU,” inIEEE International Conference on Environment and Electrical Engineering (ECEIC), 2019

    2019

  5. [12]

    Using container migration for HPC workloads resilience,

    M. Sindi and J. R. Williams, “Using container migration for HPC workloads resilience,” inIEEE High Performance Extreme Computing Conference (HPEC), 2019

    2019

  6. [13]

    The impact of container migration on fog services as perceived by mobile things,

    C. Puliafito, A. Virdis, and E. Mingozzi, “The impact of container migration on fog services as perceived by mobile things,” inIEEE SMARTCOMP, 2020

    2020

  7. [14]

    An implementation of job migration function using CRIU and podman in docker-based user-pc computing system,

    H. Htet, N. Funabiki, A. Kamoyedji, X. Zhou, and M. Kuribayashi, “An implementation of job migration function using CRIU and podman in docker-based user-pc computing system,” inACM ICCCM, 2021

    2021

  8. [15]

    Enabling mobile service continuity across orchestrated edge networks,

    O. I. Abdullaziz, L.-C. Wang, S. B. Chundrigar, and K.-L. Huang, “Enabling mobile service continuity across orchestrated edge networks,” IEEE Transactions on Network Science and Engineering, 2019

    2019

  9. [16]

    Live migration of virtual machine and container based mobile core network components: A comprehensive study,

    S. Ramanathan, K. Kondepu, M. Razo, M. Tacca, L. Valcarenghi, and A. Fumagalli, “Live migration of virtual machine and container based mobile core network components: A comprehensive study,”IEEE Access, vol. 9, 2021

    2021

  10. [17]

    An architecture proposal for checkpoint/restore on stateful containers,

    R. H. M ¨uller, C. Meinhardt, and O. M. Mendizabal, “An architecture proposal for checkpoint/restore on stateful containers,” inACM/SIGAPP Symposium on Applied Computing, 2022

    2022

  11. [18]

    Optimal container migration/re-instantiation in hybrid computing environments,

    S. Aleyadeh, A. Moubayed, P. Heidari, and A. Shami, “Optimal container migration/re-instantiation in hybrid computing environments,” IEEE Open J. of the Communications Society, 2022

    2022

  12. [19]

    5G-Edge Relocator: a Framework for Application Relocation in Edge- enabled 5G System,

    G. Panek, P. Matysiak, N. E.-h. Nouar, I. Fajjari, and H. Tarasiuk, “5G-Edge Relocator: a Framework for Application Relocation in Edge- enabled 5G System,” inIEEE ICC, 2023

    2023

  13. [20]

    Learning-based microser- vice placement and migration for multi-access edge computing,

    K. Ray, A. Banerjee, and N. C. Narendra, “Learning-based microser- vice placement and migration for multi-access edge computing,”IEEE Transactions on Network and Service Management, vol. 21, no. 2, pp. 1969–1982, 2024. 14 0 2 4 6 8 10 12 14 16 18 20 22 24 x 0.0 0.2 0.4 0.6 0.8...

    1969

  14. [21]

    Reinforcement learning-based optimization framework for application component migration in nfv cloud-fog environments,

    S. N. Afrasiabi, A. Ebrahimzadeh, C. Mouradian, S. Malektaji, and R. H. Glitho, “Reinforcement learning-based optimization framework for application component migration in nfv cloud-fog environments,” IEEE Transactions on Network and Service Management, vol. 20, no. 2, pp. 186...

    2023

  15. [22]

    Follow me fog: Toward seamless handover timing schemes in a fog computing environment,

    W. Bao, D. Yuan, Z. Yang, S. Wang, W. Li, B. B. Zhou, and A. Y . Zomaya, “Follow me fog: Toward seamless handover timing schemes in a fog computing environment,”IEEE Communications Magazine, 2017

    2017

  16. [23]

    Differentiated service/data migration for edge services leveraging container character- istics,

    P. Bellavista, A. Corradi, L. Foschini, and D. Scotece, “Differentiated service/data migration for edge services leveraging container character- istics,”IEEE Access, vol. 7, 2019

    2019

  17. [24]

    Seamless virtualized controller migration for drone applications,

    N. An, S. Yoon, T. Ha, Y . Kim, and H. Lim, “Seamless virtualized controller migration for drone applications,”IEEE Internet Computing, vol. 23, no. 2, 2019

    2019

  18. [25]

    LXC container migration in cloudlets under multipath TCP,

    Y . Qiu, C.-H. Lung, S. Ajila, and P. Srivastava, “LXC container migration in cloudlets under multipath TCP,” inIEEE COMPSAC, 2017

    2017

  19. [26]

    Experiences implementing live VM migration over the W AN with multi-path TCP,

    F. Le and E. M. Nahum, “Experiences implementing live VM migration over the W AN with multi-path TCP,” inIEEE INFOCOM, 2019

    2019

  20. [27]

    Achieving sub-second downtimes in large-scale virtual machine migrations with LISP,

    P. Raad, S. Secci, D. C. Phung, A. Cianfrani, P. Gallard, and G. Pu- jolle, “Achieving sub-second downtimes in large-scale virtual machine migrations with LISP,”IEEE Transactions on Network and Service Management, vol. 11, no. 2, 2014

    2014

  21. [28]

    Server-side QUIC connection migration to support microservice deployment at the edge,

    C. Puliafito, L. Conforti, A. Virdis, and E. Mingozzi, “Server-side QUIC connection migration to support microservice deployment at the edge,” Pervasive Mobile Computing, vol. 83, 2022

    2022

  22. [29]

    Warrens: Decentralized connectionless tunnels for edge container networks,

    T. Goethals, M. Al-Naday, B. V olckaert, and F. De Turck, “Warrens: Decentralized connectionless tunnels for edge container networks,”IEEE Transactions on Network and Service Management, vol. 21, no. 4, pp. 4282–4296, 2024

    2024

  23. [30]

    A PMIPv6 approach to maintain network connectivity during VM live migration over the internet,

    S. Kassahun, A. Demessie, and D. Ilie, “A PMIPv6 approach to maintain network connectivity during VM live migration over the internet,” in IEEE International Conference on Cloud Networking (CloudNet), 2014

    2014

  24. [31]

    Enabling live migration of containerized applications across clouds,

    T. Benjaponpitak, M. Karakate, and K. Sripanidkulchai, “Enabling live migration of containerized applications across clouds,” inIEEE INFOCOM, 2020

    2020

  25. [32]

    Good shepherds care for their cattle: Seamless pod migration in geo-distributed kubernetes,

    P. S. Junior, D. Miorandi, and G. Pierre, “Good shepherds care for their cattle: Seamless pod migration in geo-distributed kubernetes,” inIEEE International Conference on Fog and Edge Computing (ICFEC), 2022

    2022

  26. [33]

    Design and Im- plementation of Microservice Migration at the Edge,

    Y . Yu, A. Calagna, P. Giaccone, and C. F. Chiasserini, “Design and Im- plementation of Microservice Migration at the Edge,” inIEEE Wireless Communications and Networking Conference (WCNC), 2024

    2024

  27. [34]

    OpenStack,

    “OpenStack,” https://www.openstack.org/

  28. [35]

    Checkpoint/restore,

    CRIU, “Checkpoint/restore,” https://criu.org/Checkpoint/Restore and https://github.com/checkpoint-restore/criu, 2017

    2017

  29. [36]

    The Containers Organization, “Podman,” https://github.com/containers/ podman/ and https://podman.io/, 2022

    2022

  30. [37]

    Open vSwitch,

    Linux Foundation, “Open vSwitch,” https://www.openvswitch.org/

  31. [38]

    Eclipse Foundation, “Zenoh,” https://github.com/eclipse-zenoh/zenoh, 2022

    2022

  32. [39]

    Scalable and bounded-time decisions on edge device network using eclipse zenoh,

    C.-S. Shih, H.-J. Lin, Y . Yuan, Y .-H. Kuo, and W.-Y . Liang, “Scalable and bounded-time decisions on edge device network using eclipse zenoh,” inIEEE RTCSA, 2022, pp. 170–179

    2022

  33. [40]

    A performance study on the throughput and latency of Zenoh, MQTT, Kafka, and DDS,

    W.-Y . Liang, Y . Yuan, and H.-J. Lin, “A performance study on the throughput and latency of Zenoh, MQTT, Kafka, and DDS,” arXiv:2303.09419, 2023

    2023 arXiv

  34. [41]

    Benchmarking Comparison of Zenoh vs NATS,

    Pete LeVasseur, “Benchmarking Comparison of Zenoh vs NATS,” https: //github.com/PLeVasseur/zenoh-benchmark

  35. [42]

    Comparison of middlewares in edge-to-edge and edge-to-cloud communication for distributed ros-2 systems,

    J. Zhang, X. Yu, S. Ha, J. Pe ˜na Queralta, and T. Westerlund, “Comparison of middlewares in edge-to-edge and edge-to-cloud communication for distributed ros-2 systems,”Journal of Intelligent & Robotic Systems, vol. 110, no. 4, Nov. 2024. [Online]. Available: http://dx.doi.org...

    2024 doi

  36. [43]

    On the performance of zenoh in industrial iot scenarios,

    M. Bar ´on, L. Diez, M. Zverev, J. R. Ju ´arez, and R. Ag ¨uero, “On the performance of zenoh in industrial iot scenarios,”Ad Hoc Networks, vol. 170, p. 103784, 2025. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1570870525000320

    2025

  37. [44]

    Ability to monitor task memory changes,

    Pavel Emelyanov, “Ability to monitor task memory changes,” https:// lwn.net/Articles/546966/

  38. [46]

    SockPerf,

    Mellanox Technologies, “SockPerf,” https://github.com/Mellanox/ sockperf

  39. [47]

    ESNet, “iPerf3,” https://github.com/esnet/iperf

  40. [48]

    Dronecode Foundation, “PX4,” https://github.com/PX4 and https://px4. io/

  41. [49]

    Open Source Robotics Foundation, “Gazebo,” https://github.com/ gazebosim and http://gazebosim.org

  42. [50]

    Ultralytics YOLOv8,

    G. Jocher, A. Chaurasia, and J. Qiu, “Ultralytics YOLOv8,” 2023. [Online]. Available: https://github.com/ultralytics/ultralytics

    2023

  43. [51]

    You only look once: Unified, real-time object detection,

    J. Redmon, S. Divvala, R. Girshick, and A. Farhadi, “You only look once: Unified, real-time object detection,” inIEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2016

    2016

  44. [52]

    BoT-SORT: Robust asso- ciations multi-pedestrian tracking,

    N. Aharon, R. Orfaig, and B.-Z. Bobrovsky, “BoT-SORT: Robust asso- ciations multi-pedestrian tracking,”arXiv preprint 2206.14651, 2022

    2022 arXiv

  45. [53]

    YOLOv8 Overview,

    G. Jocheret al., “YOLOv8 Overview,” https://docs.ultralytics.com/ models/yolov8/

  46. [54]

    MediaMTX,

    Bluenviron, “MediaMTX,” https://github.com/bluenviron/mediamtx

  47. [55]

    Optimized pre-copy live migration for memory intensive applications,

    K. Z. Ibrahim, S. Hofmeyr, C. Iancu, and E. Roman, “Optimized pre-copy live migration for memory intensive applications,” inACM International Conference for High Performance Computing, Networking, Storage and Analysis, 2011. Antonio Calagnais a post-doc researcher at Politecni...

    2011

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.