pith. sign in

arxiv: 1907.01293 · v1 · pith:BRBJWDYVnew · submitted 2019-07-02 · 💻 cs.NI · cs.DC

Service-based Routing at the Edge

Dirk Trossen , Sebastian Robitzsch , Scott Hergenhan , Janne Riihijarvi , Martin Reed , Mays Al-Naday This is my paper

Pith reviewed 2026-05-25 10:38 UTC · model grok-4.3

classification 💻 cs.NI cs.DC
keywords service-based routingedge computingSDN5Gnamed servicesmulticastmobility supportflow setup time
0
0 comments X

The pith

IP services can be interpreted as named entities over layer-2 transport, enabling stateless edge routing with fast unicast and multicast adjustments.

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

The paper claims that AR/VR and similar 5G workloads need service endpoints placed close to users without routing through distant CDN points. It proposes treating every IP-based service as a named service on an L2 or similar transport network. This interpretation removes the need for per-flow state while supporting unicast and multicast natively. Route changes occur in tens of milliseconds, which the authors say enables quick failure recovery, responsive load balancing, and efficient mobility handling. The method was implemented on standard SDN hardware and mobile terminals in a backwards-compatible way, with reported gains in network utilization and flow setup times.

Core claim

Our approach interprets every IP-based service as a named service over a (L2 or similar) transport network, requiring no per-flow state in the network, while natively supporting both unicast and multicast delivery. The solution allows route adjustments in time scales of few tens of milliseconds, enabling rapid failure recovery, extremely responsive load balancing, efficient mobility support, and more.

What carries the argument

The named-service interpretation of IP services over L2 transport, which removes per-flow state and carries unicast plus multicast routing with rapid adjustments.

If this is right

  • Route adjustments complete in tens of milliseconds instead of longer control-plane cycles.
  • Both unicast and multicast delivery work without separate mechanisms or extra state.
  • Failure recovery, load balancing, and mobility handling all improve from the same fast adjustment path.
  • Implementation on existing SDN equipment shows measurable gains in utilization and setup time.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Edge nodes could host services directly without depending on a small number of global CDN providers.
  • The same named-service layer might simplify handover between different radio access technologies.
  • Operators could test whether the approach scales to thousands of concurrent named services without increasing control-plane load.

Load-bearing premise

Standard SDN infrastructure and mobile terminals can support the named-service view over L2 transport in a backwards-compatible way without adding per-flow state or hidden costs.

What would settle it

Measurements in an edge testbed that compare flow setup latency and link utilization between the proposed L2 named-service routing and conventional IP routing under identical mobility and failure scenarios.

Figures

Figures reproduced from arXiv: 1907.01293 by Dirk Trossen, Janne Riihijarvi, Martin Reed, Mays Al-Naday, Scott Hergenhan, Sebastian Robitzsch.

Figure 1
Figure 1. Figure 1: Fig.1: Edge Network Architecture [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: is used. The Name_ID field is used for the NbR operations, explained in Section 3.3, while the payload contains the information related to the transaction-based flow management described in Section 3.4. Fig.2: General Packet Structure An emerging technology for Layer 2 forwarding that suits our architecture is that of software-defined networking (SDN) [1], which allows for programmatically forwarding packe… view at source ↗
Figure 3
Figure 3. Figure 3: Fig.3: IP to named service flow mappings [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: AT&T MPLS topology 4.1.2 Results The results of [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Multicast Gain [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Multicast Gain for different Zipf exponent. Number of [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: Flow Setup Times with Fast Access Links The role of native deployment becomes more important if the access link is wireless, as typical wireless technologies have significantly higher access delays compared to fixed networks [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Flow Setup Times with Wireless Access Links [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Lookup & Indirection Latency Experiment Setup [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Device Implementations The right-hand choice in [PITH_FULL_IMAGE:figures/full_fig_p011_11.png] view at source ↗
read the original abstract

Future scenarios, such as AR/VR, pose challenging latency and bandwidth requirements in 5G. This need is complemented by the adoption of cloud principles for providing services, particularly for virtualizing service components with which virtualized instances can appear rapidly at different execution points in the network. While providing service endpoints close to the end user appears straightforward, this early service break-out is currently limited to routing requests to Point-of-Presence (POP) nodes provided by a few global CDN players deep in the customer network. In this paper, we propose instead to turn the edge of the Internet into a rich service-based routing infrastructure with services being provided through edge compute nodes, without needing indirect routing. Our approach interprets every IP-based service as a named service over a (L2 or similar) transport network, requiring no per-flow state in the network, while natively supporting both unicast and multicast delivery. The solution allows route adjustments in time scales of few tens of milliseconds, enabling rapid failure recovery, extremely responsive load balancing, efficient mobility support, and more. We implemented our solution on standard SDN-based infrastructure and in mobile terminals in a backwards-compatible manner, enabling a performance evaluation that shows significant improvements in network utilization as well as flow setup times.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The manuscript proposes turning the network edge into a service-based routing infrastructure for 5G scenarios such as AR/VR. It interprets every IP-based service as a named service over an L2 (or similar) transport network, claiming this requires no per-flow state while natively supporting unicast and multicast, enabling route adjustments on timescales of tens of milliseconds for failure recovery, load balancing, and mobility. The approach is stated to be implemented on standard SDN infrastructure and mobile terminals in a backwards-compatible manner, with a performance evaluation showing significant improvements in network utilization and flow setup times.

Significance. If the zero per-flow state claim and rapid adaptation properties can be realized on unmodified SDN hardware while remaining backwards compatible, the work would offer a meaningful alternative to current CDN-based early breakout for edge services, potentially improving responsiveness for latency-sensitive applications.

major comments (2)
  1. [Abstract] Abstract: The central claim that the solution 'requir[es] no per-flow state in the network' while supporting named-service interpretation over L2 and sub-100 ms adjustments is load-bearing, yet the description supplies no mechanism (e.g., how service names are encoded in existing L2 headers, whether forwarding relies on stateless broadcast domains, or how reactive controller rules avoid accumulating per-service entries). Without this, it is impossible to verify that standard OpenFlow pipelines are not required to install per-flow or per-destination match-action rules.
  2. [Abstract] Abstract: The performance evaluation is asserted to show 'significant improvements in network utilization as well as flow setup times,' but the abstract (and available description) provides no baselines, metrics, error bars, or experimental setup details, preventing assessment of whether the claimed gains are attributable to the proposed routing or to other factors.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address the two major comments on the abstract below and are willing to revise the abstract for greater clarity while preserving its brevity.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The central claim that the solution 'requir[es] no per-flow state in the network' while supporting named-service interpretation over L2 and sub-100 ms adjustments is load-bearing, yet the description supplies no mechanism (e.g., how service names are encoded in existing L2 headers, whether forwarding relies on stateless broadcast domains, or how reactive controller rules avoid accumulating per-service entries). Without this, it is impossible to verify that standard OpenFlow pipelines are not required to install per-flow or per-destination match-action rules.

    Authors: The full manuscript (Section 3) details the mechanism: service names are encoded directly into destination MAC addresses (or equivalent L2 identifiers) that map to OpenFlow group entries for stateless forwarding; unicast uses exact-match L2 rules only at the first hop while core switches rely on destination-based L2 forwarding without per-flow or per-service state accumulation. Reactive controller actions update group memberships on millisecond timescales but never install per-flow match-action entries. We will revise the abstract to include one sentence summarizing this L2 mapping and group-table approach. revision: yes

  2. Referee: [Abstract] Abstract: The performance evaluation is asserted to show 'significant improvements in network utilization as well as flow setup times,' but the abstract (and available description) provides no baselines, metrics, error bars, or experimental setup details, preventing assessment of whether the claimed gains are attributable to the proposed routing or to other factors.

    Authors: The abstract is a high-level summary; Section 5 of the manuscript provides the requested details, including baselines (standard IP routing and early-breakout CDN), metrics (link utilization and flow-setup latency), error bars from repeated trials, and the SDN testbed configuration. We will add one or two key quantitative results (e.g., utilization gain and setup-time reduction) to the abstract if space allows. revision: partial

Circularity Check

0 steps flagged

No circularity: system proposal without derivation chain

full rationale

The paper is a networking architecture proposal describing an interpretation of IP services as named entities over L2 transport, with claims about zero per-flow state and SDN implementation. No equations, fitted parameters, or mathematical derivation steps are present in the provided text. Central claims rest on implementation description and performance evaluation rather than any reduction to prior fitted values or self-citation chains. This matches the default expectation for non-circular system papers.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The proposal rests on domain assumptions about SDN capabilities and L2 transport rather than new mathematical derivations or fitted parameters.

axioms (1)
  • domain assumption Standard SDN infrastructure can support named service routing over L2 without per-flow state in a backwards-compatible manner.
    Invoked in the description of the implementation and performance evaluation.
invented entities (1)
  • Named service over L2 transport network no independent evidence
    purpose: To enable direct edge routing of IP services without per-flow state or indirect CDN paths.
    Introduced as the core reinterpretation of services in the proposed approach.

pith-pipeline@v0.9.0 · 5763 in / 1218 out tokens · 27853 ms · 2026-05-25T10:38:57.097024+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages · 1 internal anchor

  1. [1]

    Software-Defined Networking (SDN) Definition

    Open Networking Foundation, “Software-Defined Networking (SDN) Definition”, available at https://www.opennetworking.org/sdn-definition/, 2018

    work page 2018

  2. [2]

    OpenFlow Switch Specification V1.5.1

    Open Networking Foundation, “OpenFlow Switch Specification V1.5.1”, available at https://www.opennetworking.org/wp- content/uploads/2014/10/openflow-switch-v1.5.1.pdf, 2018

    work page 2014

  3. [3]

    Stateless multicast switching in software defined networks

    M. J. Reed, M. Al-Naday, N. Thomos, D. Trossen, G. Petropoulos, P. Spirou, “Stateless multicast switching in software defined networks”, In proceedings of ICC 2016, Kuala Lumpur, Maylaysia, 2016

    work page 2016

  4. [4]

    Multicast Using Bit Index Explicit Replication (BIER)

    IETF, “Multicast Using Bit Index Explicit Replication (BIER)”, Request for Comments 8279, November 2017

    work page 2017

  5. [5]

    Reducing State of SDN Switches in Mobile Core Networks by Flow Rule Aggregation

    Khalili, R., Poe, W., Despotovic, Z., and A. Hecker, "Reducing State of SDN Switches in Mobile Core Networks by Flow Rule Aggregation", Proceedings of ICCCN, August, 2016

    work page 2016

  6. [6]

    Resistance Against Brute-Force Attacks on Stateless Forwarding in Information Centric Networking

    B. A. Alzahrani, M. J. Reed, V. G. Vassilakis , “Resistance Against Brute-Force Attacks on Stateless Forwarding in Information Centric Networking”, ANCS (ACM/IEEE Symposium on Architectures for Networking and Communications Systems), Oakland, California, May 7-8 2015

    work page 2015

  7. [7]

    Over ICN Goes Live,

    G. Xylomenos, Y. Thomas, X. Vasilakos, M. Georgiades, A. Phinikarides, I. Doumanis, S. Porter, D. Trossen, S. Robitzsch, M. J. Reed, M. Al-Naday, G. Petropoulos, K. Katsaros, M. -E. Xezonaki and J. RiihijärviIP “Over ICN Goes Live,” Proceedings of EuCNC 2018

    work page 2018

  8. [8]

    Video of Trial at Bristol-is-Open, available at https://vimeo.com/223814430, 2017

    work page arXiv 2017

  9. [9]

    Cisco Visual Networking Index: Forecast and Trends, 2017– 2022, Updated 2019, Document ID 1551296909190103 available at https://www.cisco.com/c/en/us/solutions/collateral/service- provider/visual-networking-index-vni/white-paper-c11- 741490.html

    work page 2017

  10. [10]

    Nguyen, Nickolas Falkner, Rhys Bowden, Matthew Roughan, The Internet Topology Zoo, IEEE Journal on Selected Areas in Communications, Vol

    Simon Knight, Hung X. Nguyen, Nickolas Falkner, Rhys Bowden, Matthew Roughan, The Internet Topology Zoo, IEEE Journal on Selected Areas in Communications, Vol. 29, No. 9, October 2011

    work page 2011

  11. [11]

    Impact of traffic mix on caching performance in a content-centric network

    C. Fricker, P. Robert, J. Robert, N. Sbihi, “Impact of Traffic Mix on Caching Performance in a Content-Centric Network”, available at https://arxiv.org/pdf/1202.0108.pdf

    work page internal anchor Pith review Pith/arXiv arXiv

  12. [12]

    Analyzing the Video Popularity Characteristics of Large-Scale User Generated Content Systems,

    M. Cha, H. Kwak, P. Rodriguez, Y. Ahn and S. Moon, “Analyzing the Video Popularity Characteristics of Large-Scale User Generated Content Systems,” IEEE/ACM Transactions on Networking, vol. 17, no. 5, pp. 1357-1370, Oct. 2009

    work page 2009

  13. [13]

    QoE- Assured 4K HTTP Live Streaming via Transient Segment Holding at Mobile Edge,

    C. Ge, N. Wang, W. K. Chai and H. Hellwagner, "QoE- Assured 4K HTTP Live Streaming via Transient Segment Holding at Mobile Edge," in IEEE Journal on Selected Areas in Communications, vol. 36, no. 8, pp. 1816-1830, Aug. 2018

    work page 2018

  14. [14]

    Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)

    3rd Generation Partnership Project, TS23.501, “Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)”, available at http://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501- g10.zip

    work page

  15. [15]

    ROFL: routing on flat labels

    M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I. Stoica, “ROFL: routing on flat labels”, Proceedings of ACM SIGCOMM, 2006

    work page 2006

  16. [16]

    Hayes, D

    D. Hayes, D. Ros, L. L. H. Andrew, and S. Floyd. Common TCP Evaluation Suite. Internet-Draft draft-irtf-iccrg-tcpeval-01, Internet Engineering Task Force, January 2015. Work in Progress

    work page 2015

  17. [17]

    Performance Comparison Tools for DNS and CDN

    Geekflare, “Performance Comparison Tools for DNS and CDN”, available at https://geekflare.com/dns-cdn-performance- comparison/

    work page

  18. [18]

    Networking Named Content

    Jacobson, V. and et al., "Networking Named Content", Proceedings of ACM Context, , 2009

    work page 2009

  19. [19]

    Designing and Realizing an Information-Centric Internet

    Trossen, D. and G. Parisis, "Designing and Realizing an Information-Centric Internet", Information-Centric Networking, IEEE Communications Magazine Special Issue, 2012

    work page 2012

  20. [20]

    Deployment Considerations for Information-Centric Networking (ICN)

    A. Rahman, D. Trossen, D. Kutscher, R. Ravindran, “Deployment Considerations for Information-Centric Networking (ICN)”, Internet Draft, Internet Research Task Force ICN research group, 2019

    work page 2019

  21. [21]

    Content Delivery with Content Centric Networking, CableLabs White Paper

    White, G. and G. Rutz, "Content Delivery with Content Centric Networking, CableLabs White Paper", 2016, available at http://www.cablelabs.com/wp-content/uploads/2016/02/Content- Delivery-with-Content-Centric-Networking-Feb-2016.pdf

    work page 2016

  22. [22]

    Service Routing in Public Sector Networks

    Cisco whitepaper, “Service Routing in Public Sector Networks”, 2011,

    work page 2011

  23. [23]

    Traffic engineering for information-centric networks,

    M. Reed, “Traffic engineering for information-centric networks,” in proceedings of ICC 2012, Ottawa, Canada

    work page 2012

  24. [24]

    split TCP

    Luglio, M., Sanadidi, M. Y., Gerla, M., & Stepanek, J. (2004). On-board satellite" split TCP" proxy. IEEE Journal on Selected Areas in Communications, 22(2), 362-370

    work page 2004

  25. [25]

    fCDN: A Flexible and Efficient CDN Infrastructure without DNS Redirection or Content Reflection

    M. AL-Naday, M.J. Reed, J. Riihijärvi, D. Trossen, N. Thomos, M. Al-Khalidi “fCDN: A Flexible and Efficient CDN Infrastructure without DNS Redirection or Content Reflection”, arxiv, Mar 2018, accessed Jun 2019

    work page 2018