Dirk Kutscher

How can we obtain the benefits of network-assisted multipath transport without changing Internet routing?

Our paper on "MARS: Multipath Adaptive Reliable Service has been accepted for publication at the 34th IEEE International Conference on Network Protocols (ICNP). It addresses this question by combining receiver-driven transport with lightweight overlay forwarders that safely discover additional forwarding opportunities and coordinate congestion control close to network bottlenecks.

Modern cloud services, geo-distributed AI systems, and large-scale content distribution increasingly depend on moving massive amounts of data across heterogeneous wide-area networks. Existing multipath transports, such as MPTCP and MPQUIC, can only exploit the paths visible to endpoints, while routing-based approaches require changes to network infrastructure.

At a glance, MARS augments traditional endpoint multipath with lightweight receiver-driven overlay forwarding.

MARS (Multipath Adaptive Reliable Service) explores a different direction. Rather than relying solely on endpoint scheduling or modifying Internet routing, MARS introduces lightweight, deployable forwarding assistance in an overlay network.

MARS combines receiver-driven transport with cooperating overlay forwarders that safely discover additional forwarding opportunities and react to congestion much closer to network bottlenecks—all while running as an incrementally deployable UDP overlay that requires no changes to Internet routers or routing protocols.

Key Ideas

• Safe overlay path discovery that expands usable path diversity while preventing forwarding loops, backward steering, and excessive path inflation.
• Receiver-driven congestion control coordinated with intermediate forwarders using lightweight queue feedback.
• Incremental deployment, allowing MARS to operate at endpoints alone while automatically benefiting from additional cooperating overlay forwarders.
• Robust operation under heterogeneous WAN conditions, packet loss, and transient network failures.

Results

We evaluate MARS through both large-scale ndnSIM simulations and a working Mininet prototype.

The results show that:

• MARS remains competitive even with endpoint-only deployment.
• Additional overlay forwarders expose significantly richer path diversity.
• MARS reduces worst-case 95th-percentile Flow Completion Time (FCT) by up to 81.5% compared with ECMP-limited multipath baselines.
• MARS remains robust under packet loss and quickly adapts to transient network failures.

Why It Matters

MARS demonstrates how Information-Centric Networking enables deployable receiver-driven overlay multipath without requiring changes to Internet routing. Rather than replacing today's Internet, MARS shows how lightweight receiver-driven forwarding can incrementally extend existing infrastructures with richer path diversity, faster congestion response, and improved robustness for modern WAN applications.

Reference

• Yitong Li, Xinjiao Li, Dirk Kutscher; MARS: Multipath Adaptive Reliable Service, to appear in the proceedings of the 34th IEEE International Conference on Network Protocols (ICNP); Tempe, Arizona, USA, October 05-08, 2026
• Pre-print on arxiv

Today’s transport protocols schedule packets without understanding computation. SAFS introduces receiver-driven semantic-flow scheduling, allowing distributed AI runtimes to expose computation semantics so that computation-critical communication is prioritized before pipeline bubbles can form.

Modern AI systems increasingly execute as pipelines spanning multiple GPUs, servers, and disaggregated components. In these systems, network communication is no longer just a data transfer problem – it directly determines whether expensive GPU resources remain busy or become idle.

Yet today's datacenter transports remain largely application-agnostic. They optimize congestion, flow completion time, packet priorities, or deadlines, but they do not understand why a particular communication flow matters to the computation.

The figure below illustrates the core idea behind SAFS. Conventional transport schedules communication independently of application progress, whereas SAFS uses lightweight runtime semantics to prioritize computation-critical communication before the no-bubble deadline.

Our accepted IEEE ICNP 2026 paper introduces SAFS (Slack-Aware Flow Scheduling), a transport architecture that schedules communication according to AI computation semantics.

The Key Observation

A network transfer is not harmful simply because it is delayed.

Instead, it becomes harmful only when it arrives after the downstream computation has exhausted the slack that could otherwise have hidden the communication. At that point, the delay becomes an exposed pipeline bubble, leaving GPUs idle while waiting for missing data.

This leads to a fundamentally different transport objective.

Instead of asking:

Which flow should finish first?

SAFS asks:

Which communication dependency will become the next computation bottleneck?

From Packets to Semantic Flows

SAFS introduces the notion of semantic flows.

Rather than treating network traffic as anonymous byte streams, each communication flow is associated with lightweight runtime metadata describing its role within the computation. This includes information such as:

• remaining data volume,
• a no-bubble timestamp indicating when the data must arrive,
• dependency information,
• and runtime updates as execution progresses.

Receivers use this semantic information to allocate bandwidth to the communication flows that are most critical for maintaining continuous pipeline execution.

Receiver-Driven Scheduling for AI Workloads

SAFS combines these computation semantics with a receiver-driven transport architecture.

Instead of allocating bandwidth solely according to congestion, flow size, or externally assigned deadlines, receivers compute the transmission rates required to keep each communication dependency on its no-bubble trajectory.

This allows application semantics to guide transport scheduling while existing transport mechanisms continue to provide congestion control, fairness, and reliable data delivery.

Because SAFS augments rather than replaces existing transport protocols, it can be deployed incrementally without requiring changes to AI applications or accelerator hardware.

Evaluation

We demonstrate SAFS in two representative AI environments:

• Pipeline-parallel training, where communication between pipeline stages competes with background traffic.
• Disaggregated LLM inference, where hidden-state transfers determine when feed-forward computation can begin.

Across both workloads, SAFS consistently prioritizes the communication dependencies that determine end-to-end execution performance.

Highlights include:

• Up to 38.7% lower iteration time during ZeroBubble pipeline training under background traffic.
• 38.7% lower p99 TPOT than D2TCP for large-scale disaggregated inference.
• 66.2% lower p99 TPOT than Homa.
• Zero urgent deadline misses in targeted receiver-incast microbenchmarks.

Why It Matters

SAFS explores a broader research direction:

Transport protocols should understand computation—not just packets.

This represents a fundamental shift from optimizing packet delivery toward optimizing application progress. As AI systems become increasingly distributed and disaggregated, exposing computation semantics to the transport layer enables the network to prioritize the communication that actually determines application performance.

Rather than optimizing generic network metrics, SAFS directly optimizes what distributed AI workloads ultimately care about: continuous computation, high accelerator utilization, and fewer pipeline bubbles.

Reference

Ruilong Wu, Yisu Wang, Jiaxiang Zou, Xiangsen Chen, Yixiang Zhu, Xinjiao Li, Xinyu Chen, Dirk Kutscher; SAFS: Slack-Aware Flow Scheduling for Pipelined AI Workloads; to appear at the 34th IEEE International Conference on Network Protocols (ICNP); Tempe, Arizona, USA, October 05-08, 2026

In a joint panel at ACM ICN-2023 and IEEE ICNP-2023 in Reykjavik, Ken Calvert, Jim Kurose, Lixia Zhang, and myself discussed future network abstractions. The panel was moderated by Dave Oran. This was one of the more interesting and interactive panel sessions I participated in, so I am providing a summary here.

Since the Internet's initial rollout ~40 years ago, not only its global connectivity has brought fundamental changes to society and daily life, but its protocol suite and implementations have also gone through many iterations of changes, with SDN, NFV, and programmability among other changes over the last decade. This panel looks into next decade of network research by asking a set of questions regarding where lies the future direction to enable continued innovations.

Opportunities and Challenges for Future Network Innovations

Lixia Zhang: Rethinking Internet Architecture Fundamentals

Lixia Zhang (UCLA), quoting Einstein, said that the formulation of the problem is often more essential than the solution and pointed at the complexities of today's protocols stacks that are apparently needed to achieve desired functionality. For example, Lixia mentioned RFC 9298 on proxying UDP in HTTP, specifically on tunneling UDP to a server acting as a UDP-specific proxy over HTTP. UDP over IP was once conceived as a minial message-oriented communication service that was intended for DNS and interactive real-time communication. Due to its push-based communication model, it can be used with minimal effort for useful but also harmful application, including large-scale DDOS attacks. Proxing UDP over HTTP addresses this and other concerns, by providing a secure channel to a server in a web context, so that the server can authorize tunnel endpoints, and so that the UDP communication is congestion controlled by the underlying transport protocol (TCP or QUIC). This specification can be seen as a work-around: sending unsolicted (and un-authenticated) messages over the Internet is a major problem in today's Internet. There is no general approach for authenticating such messages and no concept for trust in peer identities. Instead of analyzing the root cause of such problems, the Internet communities (and the dominant players in that space) prefer to come up with (highly inefficient) workarounds.

This problem was discussed more generally by Oliver Spatscheck of AT&T Labs in his 2013 article titled Layers of Success, where he discussed the (actually deployed) excessive layering in production networks, for example mobile communication networks, where regular Internet traffic is routinely tunneled over GTP/UDP/IP/MPLS:

The main issue with layering is that layers hide information from each other. We could see this as a benefit, because it reduces the complexities involved in adding more layers, thus reducing the cost of introducing more services. However, hiding information can lead to complex and dynamic layer interactions that hamper the end-to-end system’s reliability and are extremely difficult if not impossible to debug and operate. So, much of the savings achieved when introducing new services is being spent operating them reliably.

According to Lixia, the excessive layering stems from more fundamental problems with today's network architecture, notably the lack of identity and trust in the core Internet protocols and the lack of functionality in the forwarding system – leading to significant problems today as exemplied by recent DDoS attacks. Quoting Einstein again, she said that we cannot solve problems by using the same kind of thinking we used when we created them, calling for a more fundamental redesign based on information-centric networking principles.

Ken Calvert: Domain-specific Networking

Ken Calvert (University of Kentucky) provided a retrospective of networking research and looked at selected papers published at the first IEEE ICNP conference in 1993. According to Ken, the dominant theme at that time was How to design, build, and analyze protocols, for example as discussed in his 1993 ICNP paper titled Beyond layering: modularity considerations for protocol architectures.

Ken offered a set of challenges and opportunities for future networking research, such as:

• Domain-specific networking à la Ex uno pluria, a 2018 CCR editorial discussing:
  • infrastructure ossification;
  • lack of service innovation; and
  • a fragmentation into "ManyNets" that could re-create a service-infrastructure innovation cycle.
• Incentives and "money flow"
  • Can we escape from the advertising-driven Internet app ecosystem? Should we?
• Wide-area multicast (many-many) service
  • Building block for building distributed applications?
• Inter-AS trust relationships
  • Ossification of the Inter-AS interface – cannot be solved by a protocol!
• Impact ⇐ Applications ⇐ Business opportunities ($)
  • What user problem cannot be solved today?
• "The core challenge of CS ... is a conceptual one, viz., what (abstract) mechanisms we can conceive without getting lost in the complexities of our own making." - Dijkstra

For his vision for networking in 30 years, Ken suggested that:

• IP addresses will still be in use
  • but visible only at interfaces between different owners' infrastructures
• Network infrastructure might consist of access ASes + separate core networks operated by the "Big Five".
• Users might communicate via direct brain interfaces with AI systems.

Dirk Kutscher: Principled Approach to Network Programmability

I offered the perspective of introducing a principled approach to programmability that could provide better programmability (for humans and AI), based on more powerful network abstractions.

Previous work in SDN with protocols such as OpenFlow and dataplane programming languages such as P4 have only scratched the surface of what could be possible. OpenFlow was a great first idea, but it was fundamentally constrained by the IP and Ethernet-based abstractions that were built into it. It can be used for programming some applications in that domain, such as firewalls, virtual networking etc., but the idea of continuous innovation has not really materialized.

Similarly, P4 was advertized as an enabler for new levels of dataplane programmability, but even simple systems such as NetCache have to go to quite some extend to achieve minimal functionality for a proof-of-concept. Another P4 problem that is often reported is the hardware heterogeneity so that universal programmability is not really possible. In my opinion, this raises some questions with respect to applicability of current dataplane programming for in-network computing. A good example of a more productive application of P4 is the recent SIGCOMM paper on NetClone that describes as fast, scalable, and dynamic request cloning for microsecond-Scale RPCs. Here P4 is used as an accelerator for programming relatively simple functionality (protocol parsing, forwarding).

This may not be enough for future universal programmability though. During the panel discussion, I drew an analogy to computer programming language. We are not seeing the first programming language and IDEs that are designed from the ground up for better AI. What would that mean for network programmability? What abstractions and APIs would we need?

In my opinion, we would have to take a step back and think about the intended functionality and the required observability for future (automated) network programmability that is really protocol-independent. This would then entail more work on:

• the fundamental forwarding service (informed by hardware constraints);
• the telemetry approach;
• suitable protocol semantics;
• APIs for applications and management; and
• new network emulation & debugging approach (a long the lines of "network digital twin" concepts).

Overall, I am expecting new exiciting research in the direction of principled approaches to network programmability.

Jim Kurose: Open Research Infrastructures and Softwarization

Jim reminded us that the key reason Internet research flourished was the availability of open infrastructure with no incumbent providers initially. The infrastructure was owned by researchers, labs, and universities and allowed for a lot of experimentation.

This open infrastructure has recently been challenged by ossification with the rise of production ISP services at scale, and the emergence of closed ISPs, cellular carriers, hyperscalers operating large portion of the network.

As an example for emerging environments that offer interesting opportunities for experiments and new developments, Jim mentioned 4G/5G private networks, i.e., licensed spectrum created closed ecosystems – but open to researchers, creating opportunities for:

• innovation in private 5G networks such as Citizens Broadband Radio Service (CBRS) that could enables innovation in open, deployed systems and a democratization of 5G+ networks and edge applications;
• testbeds, such as Platforms for Advanced Wireless Research (PAWR); and
• the integration of WiFi, 5G as link-layer edge RANs.

Jim was also suggesting further opportunities in softwarization and programmability, such as (formal) methods for logical correctness and configuration management, as well as programmability to add services beyond the "minimal viable service", such as closed loop automatic control and management.

Finally Jim also mentioned opportunities in emerging new networks such as LEOs, IoT and home networks.