Olivier Bonaventure and the work of making one connection survive several networks

Executive summary

• Olivier Bonaventure is a UCLouvain professor and engineering dean whose work has connected internet routing, transport protocols, running code, open education and commercial deployment.
• He was a principal academic architect and RFC co-author for Multipath TCP, while its architecture, congestion control, security and implementations came from overlapping groups of researchers and engineers.
• UCLouvain helped move MPTCP from specifications into Linux code and deployment evidence later used by Apple, telecom operators, Tessares and the upstream Linux community.
• Bonaventure’s lasting contribution is a method for protocol deployment: preserve useful interfaces, test assumptions in running systems, revise failures and transfer maintenance to institutions that can endure.

How one connection can survive a network failure

A smartphone can remain inside mobile coverage while its Wi-Fi connection collapses. A broadband customer may have a slow fixed line and an available cellular link. A server can reach the same destination through several data-centre routes even when one becomes congested or fails. Conventional Transmission Control Protocol, or TCP, normally identifies a connection through one pair of addresses and ports. When that path disappears, the application can lose its session even though another route remains available.

Multipath TCP, commonly shortened to MPTCP, was designed around that contradiction. It preserves the reliable, ordered byte stream that existing applications expect while allowing the endpoints to create several TCP subflows beneath it. Those paths can keep a connection alive, combine capacity or allow traffic to move according to local policy. The difficult part was never the observation that two paths could be better than one. The challenge was making them behave like one application service without requiring every application, server, firewall, network address translator or load balancer to be replaced at once.

That made MPTCP as much a deployment problem as a protocol-design problem.

Olivier Bonaventure’s career offers a way to understand that process. He did not single-handedly invent MPTCP, write every implementation or control the companies that deployed it. He helped build the pipeline through which a collectively designed protocol moved from standards work into software, measurement, operator products and long-term maintenance.

MPTCP was built by a network, not one inventor

A simplified account might call Bonaventure the inventor of MPTCP and draw a straight line from an academic idea to commercial use. The standards and implementation records do not support that story. MPTCP emerged from researchers and engineers at UCLouvain, University College London, the University Politehnica of Bucharest, Cisco, Apple, the Internet Engineering Task Force and, later, the Linux community.

The work was divided across several technical layers. Some participants developed the architecture. Others designed the wire protocol, congestion-control algorithms, security mechanisms or application interfaces. Kernel developers translated those documents into running code. Device companies and telecom operators then made their own decisions about path policy, product design and support.

Bonaventure’s contribution is best understood across time. He appears in the experimental and Standards Track specifications, operational-experience work, the UCLouvain research and implementation environment, tutorials, open educational material and the commercialisation route through Tessares. He helped connect stages that often remain separated: protocol design, implementation, measurement, standards revision, deployment and institutional succession.

That is a more consequential role than a sole-inventor label. Protocols rarely become infrastructure because one person has an elegant idea. They become infrastructure when several organisations can implement, test, operate, revise and eventually maintain them without relying permanently on the original research group.

A career formed around deployability

Bonaventure earned an engineering degree in computer science from the University of Liège in 1992. He then worked as a research engineer in André Danthine’s networking group while completing a doctorate. His 1999 dissertation examined how Asynchronous Transfer Mode, or ATM, could operate beneath TCP/IP while providing minimum guaranteed bandwidth.

The subject belonged to a major debate of the 1990s. ATM offered engineered virtual circuits and service classes, while the internet stack had developed around packets, endpoint control and gradual adoption. The technical problem was not simply whether ATM could carry IP traffic. It was whether new network capabilities could be introduced without discarding the applications, protocols and operational practices already in use.

That question would recur throughout Bonaventure’s career. MPTCP also places new capability beneath an existing application interface. Rather than asking software developers to replace the familiar TCP byte stream, it changes how the transport layer uses available paths. The mechanism differs from his doctoral work, but the integration problem is recognisable.

From 1992 to 1997, Bonaventure worked as a research engineer at Liège. The public record does not reconstruct every responsibility from that period, but the sequence places implementation and network experiments before his conventional faculty career. His later group would continue to combine papers with code, tutorials and measurement. He spent 1997 to 1998 at Alcatel-Bell. The reviewed material does not establish a precise job title or identify particular products, so the period should not be embellished.

It nevertheless placed him briefly inside a telecom company, where compatibility, product lifecycles and customer support impose different constraints from those of a laboratory prototype.

Bonaventure became an assistant professor at FUNDP, now the University of Namur, in 1998. He moved to UCLouvain in 2002, became professor in 2006 and full professor in 2011. At the research cutoff, UCLouvain identified him as a full professor and Dean of the Louvain School of Engineering.

The long UCLouvain period supplied something short research projects rarely provide: continuity. MPTCP needed graduate researchers, kernel development, experiments, IETF participation, operator relationships and years of maintenance. The university did not own the protocol, and Bonaventure did not write every component, but the group created an institutional base in which those activities reinforced one another.

Routing work taught him to design the transition

Before MPTCP became his most visible association, Bonaventure worked on routing, traffic engineering and convergence. These subjects confront a basic operational problem: networks must change while they continue to carry traffic. An operator may need to adjust a topology, policy or link weight while routers hold distributed state and neighbouring systems follow their own update schedules. A mathematically correct destination state is not enough. The transition can create loops, packet loss or temporary congestion before the network settles.

Bonaventure co-authored work on disruption-free topology reconfiguration in Open Shortest Path First, or OSPF, networks that received an INFOCOM best-paper award in 2007. The work treated reconfiguration as an ordered operational process rather than a single calculation. It asked how a network could move from one valid state to another while reducing forwarding disruption.

MPTCP applies the same habit at the transport layer. One application connection must continue while subflows appear, disappear or perform differently. The mechanism must account for the transition rather than assuming that the endpoint begins and ends with a stable set of routes. His work on faster recovery from Border Gateway Protocol peering-link failures addressed a still more conservative boundary. Interdomain routing combines technical state with commercial policy and security assumptions. No operator can compel every peer to upgrade at the same moment.

Later research on xBGP and secure BGP transport continued this line of enquiry. The goal was not to replace interdomain routing through a clean break, but to introduce controlled extension points or stronger transport within familiar operational structures. MPTCP was therefore one prominent example of a broader career question: how can infrastructure change without pretending that its installed base can be negotiated away?

MPTCP preserved the application while changing the transport underneath

Traditional TCP provides applications with a reliable ordered stream and binds the connection to a pair of endpoint addresses and ports. That model was effective when hosts commonly relied on one dominant network interface and changing an address usually meant changing network identity. Mobile devices, multihomed servers and data-centre fabrics exposed the limitation. An application could open several independent connections, but it then had to manage path selection, ordering and failure itself. A session tied to one connection could still disappear when that path failed.

MPTCP kept the ordinary socket abstraction while giving the transport layer knowledge of several addresses and subflows. An existing application could continue to see one connection even though the endpoints used more than one path beneath it. This mechanism can produce three different outcomes. Resilience keeps the logical connection alive when one path fails. Aggregation sends data over several paths to increase available throughput. Mobility and policy add or remove paths according to radio conditions, cost, battery use, operator rules or application needs.

Those goals do not always align. A phone may keep cellular service as a backup because using it continuously would consume energy or a data allowance. A hybrid-access gateway may use a fixed line and LTE at the same time. A data-centre host may spread traffic across several similar routes. MPTCP provides the mechanisms, while path managers, schedulers, congestion control and endpoint policy determine the service that users receive.

Compatibility with the installed internet became the central constraint. Firewalls, network address translators, load balancers, intrusion-detection systems and TCP optimisers had accumulated assumptions about ordinary TCP. They might remove unknown options, rewrite packets or expect all bytes in a connection to follow one path.

MPTCP therefore used TCP options and ordinary-looking subflows. If capability negotiation failed, the connection could continue as conventional TCP. This made gradual deployment possible, but it also limited option space, complicated the handshake and created an observability problem: the application could work even when the intended multipath service had silently disappeared.

The standards record rules out a sole-inventor story

The MPTCP architecture and standards documents make collective authorship visible. RFC 6182, which set out the architectural guidelines, was written by Alan Ford, Costin Raiciu, Mark Handley, Sébastien Barré and Janardhan Iyengar. RFC 6824, the experimental MPTCP version 0 specification, was written by Ford, Raiciu, Handley and Bonaventure. RFC 8684, the later Standards Track specification, added Christoph Paasch.

Other components had different principal authors. RFC 6356 on coupled congestion control was written by Raiciu, Handley and Damon Wischik. Michael Scharf and Ford documented application-interface considerations. Marcelo Bagnulo and later contributors participated in security analysis.

This division was not an accident. The architecture described goals such as application transparency, resilience, resource pooling and incremental deployment. The wire specifications defined options, keys, subflows, sequence mappings and failure behaviour. Congestion control addressed fairness when one logical connection could use several TCP subflows. Security work examined tokens, subflow attachment and attacker models. Implementations then converted these documents into kernel state and local operating policy.

A sound architecture does not guarantee a sound handshake. A fair congestion-control algorithm may still perform poorly on paths with very different latency. An implementation can follow an RFC and remain difficult to diagnose. Bonaventure’s influence was strongest where those layers met: using implementation and deployment evidence to improve the standards process.

RFC 6824 was published in January 2013 as an Experimental specification. It defined MPTCP version 0 and used TCP option kind 30. “Experimental” did not mean casual. It recognised that a major extension to a deeply deployed protocol needed evidence from real software and networks before it could be treated as stable infrastructure. That evidence came from research kernels, middlebox testing, data-centre experiments, Apple’s deployment and operator systems. The community found handshake, security, path-management and operational problems that document review alone could not expose.

RFC 8041, written by Bonaventure, Paasch and Gregory Detal, brought that operating experience into the standards record. It covered data centres, Wi-Fi and cellular links, proxies, middlebox interference, congestion control, scheduling, captive portals and load-balanced server farms. The document treated deployed behaviour as evidence capable of changing the protocol. That is an important institutional step. A specification does not remain authoritative simply because it was published first. When running code repeatedly contradicts an assumption, the standard must account for the network that exists.

RFC 8684 was published in March 2020, obsoleting RFC 6824 and moving MPTCP version 1 onto the Standards Track. It revised the MP_CAPABLE exchange and clarified behaviour learned through implementation. Version 1 is not wire compatible with version 0. The break created migration work, but preserving every experimental choice would have carried its own costs. MPTCP’s development shows that maturity can require an explicit version boundary when operational evidence makes the earlier design difficult to defend.

One connection, several ordinary TCP subflows

To an application, an MPTCP connection still appears as one reliable byte stream. Underneath, each subflow is an ordinary TCP connection with its own sequence numbers, congestion window, retransmissions, round-trip time and failure state. The MPTCP layer coordinates them and presents one ordered connection to the application.

The first subflow begins with a normal TCP three-way handshake augmented by the MP_CAPABLE option. This signals that both endpoints understand MPTCP and exchanges keying material used to identify and authenticate the connection. If either endpoint or an intervening device does not support the option, the session can continue as ordinary TCP.

Once the MPTCP connection exists, an endpoint can create another subflow using MP_JOIN. The joining exchange carries a token that identifies the connection and an HMAC-based mechanism derived from the connection keys. It lets another path join without disclosing the full key or making arbitrary attachment easy. The protocol does not decide when an additional subflow should be created. That responsibility belongs to the path manager and deployment policy. A phone may add cellular service only when Wi-Fi deteriorates. A hybrid-access gateway may activate fixed and mobile paths immediately. A data-centre host may discover several addresses and routes.

MPTCP can advertise and withdraw addresses and mark a path as backup. Those functions interact with network address translation, privacy and server-farm design. A local address may not be reachable from every remote path, while advertising all interfaces may expose topology that an operator prefers to keep private. Path management therefore became an important policy boundary. Early implementations placed much of the logic in the kernel. Upstream Linux later added netlink and userspace control, allowing privileged software to add or remove subflows according to device and operator requirements.

The transport must also maintain two sequence spaces. Each subflow has ordinary TCP sequence numbers, while the logical connection uses a Data Sequence Number space. The Data Sequence Signal maps bytes from a subflow into the connection-wide stream and acknowledges data at that higher layer.

A byte first sent over Wi-Fi can therefore be retransmitted through cellular without changing the order seen by the application. The receiver must distinguish loss from delay, reorder data arriving through paths with different latency and prevent one slow route from causing excessive buffering. A scheduler chooses where to send new data and retransmissions. A lowest-round-trip-time scheduler may reduce delay on similar paths but leave slower capacity unused. A redundant scheduler can transmit the same data over several paths for resilience while consuming more bandwidth. A backup scheduler can preserve cellular service until Wi-Fi fails.

These decisions depend on the service. A voice assistant values continuity and short interruption. A bulk transfer may value combined throughput. A rural hybrid-access product may try to use all available fixed and mobile capacity. The scheduler is where a general protocol mechanism becomes a specific product policy. Congestion control creates another constraint. If each subflow behaved as a completely independent TCP connection, one MPTCP session could take an unfair share of a common bottleneck. Coupled congestion control was designed to pool resources while avoiding excessive aggressiveness and moving traffic towards less congested paths.

The network topology may remain partly hidden. Two apparently separate paths can share a bottleneck, radio resource or provider link. No congestion-control algorithm can infer every commercial and physical dependency, so operators still need measurement and local policy.

Connection closure is also layered. A TCP FIN can close one subflow while the MPTCP connection continues elsewhere. A connection-level DATA_FIN closes the reliable stream. Reset and fast-close mechanisms handle abrupt failures. Linux continued adding reset, accounting, socket-option and diagnostic behaviour after the first upstream merge, showing that implementation completeness emerged over years rather than through one release.

The installed internet shaped the protocol

MPTCP endpoints do not communicate through a neutral pipe. Network address translators rewrite addresses and ports. Firewalls inspect handshake state. Load balancers distribute flows. TCP optimisers may change segmentation or payload, while monitoring systems may expect to observe the full stream on one path. These devices can pass, strip, modify or reject unfamiliar TCP options. A protocol that worked only between clean laboratory endpoints would have little value on the public internet.

The 2012 NSDI paper “How Hard Can It Be?” put this problem at the centre of the research. Costin Raiciu, Christoph Paasch, Sébastien Barré, Alan Ford, Michio Honda, Fabien Duchêne, Olivier Bonaventure and Mark Handley examined middlebox behaviour, unequal paths, reordering, buffer pressure and realistic server and operating-system constraints.

The title captured the shift from diagram to system. Splitting data across routes and reassembling it appears simple at a high level. The deployed internet turns it into a problem involving compatibility, sequence mappings, scheduling and failure. The paper received the USENIX NSDI Community Award because it supplied running code and evidence that other researchers could use.

Fallback was essential to that deployability. When MP_CAPABLE is stripped or blocked, the connection can proceed as ordinary TCP. The user is more likely to retain service, but the operator may not know that resilience or aggregation has disappeared. A production system therefore needs counters for negotiation success, fallback reason, subflow creation, path failure and scheduling. The absence of an outage does not prove that MPTCP is active. A provider cannot support a credible multipath service without observing the mechanism on which the claim depends.

MPTCP also authenticates the attachment of subflows. It exchanges keys, derives tokens and uses HMAC-based checks when another path joins the connection. Security analysis has examined token guessing, denial of service, address advertisement, subflow hijacking and on-path or off-path attackers. This does not provide application confidentiality. Transport Layer Security or another application-security layer remains responsible for protecting content. MPTCP’s authentication protects the structure of the multipath connection; it does not replace encryption above it.

Running code turned research into infrastructure

UCLouvain’s historical project account credits Sébastien Barré with beginning the main Linux MPTCP implementation lineage around 2009, drawing partly on earlier shim6-related work. Christoph Paasch, Gregory Detal, Fabien Duchêne and many others expanded the tree. It supported experiments, tutorials and early deployments.

Bonaventure’s role was that of research leader, protocol co-designer, supervisor, co-author and occasional code contributor. That is substantial without making him the principal kernel programmer. A research leader can build infrastructure by assembling people, framing questions, securing collaboration and making code available as a shared experimental platform.

The 2019 ACM SIGCOMM Networking Systems Award recognised the Linux MPTCP implementation and identified Paasch, Barré and Detal as its main developers while acknowledging a broader contributor community. Their visibility matters because the project depended on several kinds of expertise. Institution building does not replace engineering credit; it creates the conditions in which engineers can produce durable work.

The UCLouvain tree could add schedulers, path managers, socket options and experiments faster than mainline Linux. That flexibility made it useful to researchers and early adopters. It also created a maintenance burden. Users had to carry patches, follow kernel changes, integrate security fixes and support behaviour outside standard distribution lifecycles.

A research fork proves that a mechanism can work. A maintained subsystem must meet different expectations around review, compatibility, testing and support. Upstreaming is not a matter of copying code into a larger repository. It transfers responsibility into another institution and often requires interfaces to be redesigned around what that community can sustain.

Initial MPTCP support entered mainline Linux 5.6 in March 2020. The first merge provided connection establishment, protocol options, a namespace control and self-tests. It did not yet create and use several subflows simultaneously, so describing Linux 5.6 as a complete multipath implementation would overstate the milestone.

The limited first merge reflected upstream governance. Smaller steps reduced review risk and allowed the subsystem to establish tests and interfaces before taking on full multipath operation. The release also showed why a statement that a kernel “supports MPTCP” needs qualification. Version, path management, scheduler behaviour and diagnostic features determine what the support means.

Later work added a netlink path manager, concurrent use of several subflows, connection-level out-of-order handling and userspace control. Matthieu Baerts, Paolo Abeni, Mat Martineau and other upstream contributors became central during this phase. Tessares engineers also participated, but the subsystem was not simply the UCLouvain tree moved intact. The progression shows institutionalisation in practice. Protocol negotiation arrived first. Policy interfaces and real multipath use followed. Reset handling, diagnostics and self-tests continued to develop.

Mainline Linux became the common maintenance layer, while device makers and operators retained local control over path policy.

Current Linux records identify Matthieu Baerts and Mat Martineau among the MPTCP maintainers. Bonaventure is not a current Linux MPTCP maintainer. Historical influence does not create present merge authority or security responsibility. That succession strengthens the case for his influence. A protocol becomes infrastructure when it can continue without requiring its original academic leaders to accept every patch or diagnose every regression. The remaining question is whether the later community has enough maintainers, tests and funding to sustain the subsystem.

Deployment depended on product policy and operator economics

Apple turned MPTCP into visible consumer infrastructure. Its support material explains that an iPhone or iPad can use Wi-Fi as the primary connection and cellular service as a backup. Siri is the best-known example. If Wi-Fi becomes unavailable or unresponsive, the application can continue over cellular without creating a completely new logical session.

Network administrators were advised to allow TCP option 30 and expect ordinary TCP fallback when the option could not pass. The deployment showed that MPTCP could provide resilience at consumer scale. It did not mean that every iOS application combined Wi-Fi and cellular bandwidth. Apple wrote its own implementation, operated the server side and selected the product policy. Bonaventure influenced the upstream research and standards work but did not write Apple’s internal networking stack.

UCLouvain researchers later examined Apple’s handover behaviour and reported broader application access in iOS 11. The transition was not literally instantaneous, and endpoint policy still influenced the result. A connection can survive a path change while experiencing delay, reordering or reduced throughput.

Physical networks do not disappear behind the abstraction. Mobile continuity still depends on radio state, network address translation, server support, path validation and application timing. Data centres use multipath for another purpose. Several physical or equal-cost routes may exist between servers. MPTCP can expose that diversity at the transport layer, potentially improving utilisation and resilience without requiring applications to manage separate sockets.

The environment differs from a phone. Data-centre paths may have similar nominal cost but share hidden bottlenecks. Too many subflows can create unfairness or pressure switch tables. Scheduling and congestion control must fit the fabric design. The same MPTCP mechanisms support different services because the common protocol does not prescribe every local decision.

Most public internet servers did not enable MPTCP, which encouraged the use of proxies or transport converters. An operator could run MPTCP between a customer device or gateway and an operator-controlled anchor, then continue to the public server over ordinary TCP. This allowed deployment without requiring every website to change. It also placed a stateful intermediary inside the service. The proxy terminates transport state, concentrates traffic and becomes an operational dependency.

RFC 8803, edited or co-authored by Bonaventure and collaborators, defined a zero-round-trip transport converter intended to assist the deployment of TCP extensions. The design accepted that an intermediary might be more practical than waiting for universal end-to-end support.

The anchor’s ownership, location and failure domain then became part of the product. A central proxy may simplify management while increasing the blast radius of failure. Distributed anchors reduce path length but multiply state, software instances and operating objects. Capacity planning must cover the fixed and mobile traffic, connection state and failover behaviour handled by the converter.

Mobile devices add another constraint: paths have financial and energy costs. Keeping a cellular radio active can consume battery power, and traffic over a metered network can cost the user or operator. Wi-Fi may be fast but unstable; cellular may be reliable but expensive. This helps explain why Apple’s documented use emphasised backup rather than permanent aggregation. The protocol can carry traffic across several networks, but it cannot determine what the user is willing to pay or which battery trade-off is acceptable.

Tessares carried MPTCP across the commercial boundary

Hybrid access combined a fixed line such as DSL with a mobile connection such as LTE. The fixed link could provide a stable base, while cellular capacity added speed or continuity. The model was particularly attractive where replacing long copper loops with fibre would take time or require substantial capital. A typical deployment placed MPTCP-capable software in the customer gateway and at an operator-controlled aggregation point. The operator could manage both access networks, choose the scheduler and define customer support.

The service did not make every application faster. It depended mainly on TCP traffic, gateway integration, proxy capacity and the treatment of virtual private networks, UDP and other protocols. The commercial product was therefore much more than the RFC. It included software, customer-premises equipment, radio resources, monitoring and operational support.

An investor announcement identifies Tessares as a UCLouvain spin-off founded in March 2015 by Olivier Bonaventure, Gregory Detal, Sébastien Barré, Denis Périquet and Sopartec. The group combined academic and standards work, implementation experience, business leadership and university technology transfer.

A specification could not become an operator product without gateways, integration, sales, support and responsibility for deployed systems. Bonaventure should therefore be described as a co-founder, not automatically as the company’s current chief executive, controlling shareholder or day-to-day operator. Public operator announcements identified Denis Périquet as chief executive, while founder ownership and current management responsibilities remain undisclosed in the supplied record.

Proximus provided the first named operator evidence. It described a nine-month pilot in Frasnes-Lez-Anvaing that combined DSL and 4G/LTE for rural customers. The operator reported high satisfaction and speed increases of up to 20 Mbps for some participants, and said the system qualified for broader testing with live users and possible national deployment. These were claims from a participating operator rather than an independent performance audit. Even so, the pilot proved more than a laboratory benchmark.

Proximus installed the system in customer environments, coordinated two access networks and tested whether the resulting service could be supported.

A 2018 announcement reported a €3 million financing round involving Proximus, VIVES II and SRIW. It named Proximus, KPN and Telia as customers and said nearly 15,000 households in Belgium, the Netherlands and Lithuania benefited from Tessares technology. A 2021 announcement reported a €3.5 million round led by the European Innovation Council Fund and Sagemcom, with existing investors participating. The figures establish funding and customer relationships at those dates. They do not provide current revenue, profitability, valuation, customer retention or a present installed base.

BT announced Hybrid Speed Boost for small businesses in 2022 and said the product used Tessares MPTCP technology. The operator described a combination of copper broadband and EE’s 4G network and reported an average download improvement. Its support documents also made the limitations unusually clear. The boost applied to TCP web traffic and did not accelerate typical UDP gaming traffic. Virtual private network behaviour could also limit the benefit. Two access links did not become one universal pipe for every packet.

Public material from Wavenet and Digital Wallonia later said Wavenet had maintained or supported the Tessares hybrid-access solution since 2024 and served MPTCP systems used by major European operators. Tessares remained listed as an active Belgian legal entity at the research cutoff.

That evidence supports a maintenance and support transition. It does not establish that Wavenet acquired Tessares, that all intellectual property changed hands or that Tessares stopped trading. The distinction is important because infrastructure often outlives the public launch cycle. Installed systems continue to need engineers even when a startup becomes less visible.

Hybrid access was also an economic bridge rather than a permanent substitute for fibre. It was most compelling where copper performance was poor, mobile capacity was available and fibre construction would take time. Mobile spectrum and backhaul still carried costs, and gateways had to be installed and supported. As fibre reached more locations, the case for combining DSL and LTE could weaken. Tessares showed how software and operator-controlled anchors could improve service before the physical access network was rebuilt. It did not eliminate the long-term economics of access investment.

The method continued beyond MPTCP

Bonaventure’s work on education extended the same approach beyond one protocol. He wrote Computer Networking: Principles, Protocols and Practice, first released in 2011 and subsequently revised. The book was openly licensed and made available for instructors and students to inspect, adapt and redistribute. His public record also notes a 2012 Saylor Foundation award for open-textbook work. The book treated networking as something readers could examine through protocols, code and actual behaviour rather than as a set of idealised layers. Open publication also allowed the material to change as the systems changed.

Bonaventure served as ACM SIGCOMM Education Director from 2010 to 2016 and later held editorial and academic leadership positions. His group released implementation material, tutorials, virtual environments and experiments. A 2020 SIGCOMM tutorial continued the hands-on work around multipath transport.

Reproducibility was part of protocol production. Students and engineers could run the code, inspect packets and compare a clean model with the behaviour of a middlebox-constrained path. The people trained in that environment later carried expertise into Apple, Tessares, upstream Linux and other networking organisations.

His later research moved from one multipath protocol towards more programmable transport systems. QUIC operates over UDP and implements much of its transport behaviour in user space, with encryption integrated through TLS. It provides a different route around ossified kernel and middlebox assumptions than MPTCP’s TCP-option strategy.

Bonaventure and collaborators worked on pluginised QUIC, Multipath QUIC and related transport-conversion research. This did not amount to abandoning MPTCP. It expanded the question: how can transport behaviour evolve more quickly while preserving interoperability and security? User-space deployment can shorten the update cycle, but it does not remove congestion, network policy or implementation risk. The same discipline remains necessary: expose assumptions, test them and design a maintenance path.

Research on extensible Linux transport stacks and eBPF-enabled path-aware TCP explored how transport behaviour could change without adding a fixed kernel interface for every future mechanism. A constrained execution environment and locally installed logic could support experimentation while the common layer defined safety and interoperability boundaries.

Programmability creates its own risks. Different local algorithms may produce behaviour that is difficult to compare, and extension mechanisms can create new security surfaces. Future decisions can be localised only when the shared system still provides verification, observability and a way to remove unsafe code.

The xBGP project applied similar thinking to routing. It proposed a vendor-neutral mechanism for extending BGP implementations through eBPF and verified interfaces, including work with open routing stacks such as FRRouting and BIRD. Other research considered secure transport for BGP while preserving familiar TCP-oriented operating models.

These projects were research and draft work rather than evidence of universal deployment. Their relevance lies in the proposed path to change. Operators can wait years for vendors and standards processes to add a feature. A constrained extension layer may shorten that delay if implementations remain verifiable and interoperable.

Recent UCLouvain publications have also covered adaptive IPv4/IPv6 address-family selection, switched-homing and Flexicast QUIC. Flexicast seeks to combine multicast efficiency with unicast fallback over encrypted transport, while switched-homing examines how systems change among access paths according to policy and performance.

These projects remained at different research stages. They show that Bonaventure’s work in 2025 and 2026 was not merely a retrospective defence of MPTCP. It continued to examine how network capability can be deployed when paths, protocol support and authority are divided among different parties.

His role as Dean of the Louvain School of Engineering extends that institution-building record. The position is date-sensitive and does not give him authority over every research project. It does show that his influence increasingly operates through programmes, faculty structures and the environment in which other researchers work.

MPTCP’s limits define its real achievement

MPTCP did not replace ordinary TCP, and deployment remained uneven. Version 0 and version 1 are incompatible on the wire. Many servers do not enable the protocol. Middleboxes can force fallback. Paths with very different delays can increase buffering, while simultaneous use of cellular and Wi-Fi can consume energy or metered data.

Proxies allow incremental adoption but centralise connection state. Hybrid-access products may accelerate only selected traffic. A kernel can contain MPTCP support without any application using it, while an endpoint may negotiate one version when the other side expects another. Independent studies have attempted to measure MPTCP-capable systems across the internet. Such measurements can reveal option responses and broad trends, but they are vulnerable to false positives, middlebox interference and endpoints that respond to a probe without supporting a useful application service.

An option response is not the same as an active production deployment. Adoption claims should combine scanning with named product documents, implementation versions and operational traffic evidence. The dedicated IETF MPTCP working group concluded in March 2020 after completing its chartered set of documents. Protocol governance did not end. Errata, interoperability questions, extension work and maintenance moved into the TCP Maintenance and Minor Extensions working group, whose scope includes MPTCP.

That transition is part of maturity. A focused group can take a protocol through architecture, experimentation and a Standards Track revision. A standing maintenance venue then handles its interaction with the wider TCP system. Long-term authority no longer depends on keeping the original group assembled indefinitely.

The version break also warns operators about hidden installed bases. Devices, proxies, applications and embedded systems may remain on different generations for years. Ordinary TCP fallback can preserve service while concealing the loss of multipath behaviour. Operators therefore need an inventory of protocol versions and policy, not merely a flag saying that MPTCP is enabled. They must know which generation each endpoint supports, how proxies are affected and whether fallback changes a customer promise.

The public record also has limits. It supports Bonaventure’s academic roles, RFC authorship, research leadership, open textbook, Tessares co-founding and current research. It does not establish a reliable birth date, personal wealth, compensation, founder equity, a complete Tessares capitalisation table or the company’s current financial performance. It also cannot quantify his personal share of Apple’s implementation or any operator’s commercial result. Those gaps should remain open. The technical and institutional record is substantial enough without assigning team outcomes to one person.

His legacy is the pipeline

Bonaventure did not single-handedly invent MPTCP. He did not write its architecture document, its congestion-control RFC, Apple’s implementation or the current mainline Linux subsystem. He should not be described as Tessares’ current chief executive without evidence.

His contribution is more durable than those claims would suggest. He co-authored the experimental and Standards Track specifications, led a group that produced important software and deployment research, helped bring operating evidence into the standards process, co-founded a company that carried the protocol into telecom products and built educational resources that helped train later engineers. The pattern continued in his work on QUIC, eBPF-enabled transport and BGP extension mechanisms. Each project asked how new network behaviour could survive existing applications, equipment, incentives and institutional boundaries.

BTW tracks Bonaventure because his career shows how protocol infrastructure is actually made. An RFC is only one stage. Code must interoperate, failures must be measured, operators must find a commercial or operational reason to deploy it, and maintainers must inherit responsibility from the original researchers.

MPTCP’s central mechanism is a useful expression of that wider lesson. One application connection can survive while local implementations decide which paths are active, which remain in reserve and which should be abandoned. Bonaventure helped build enough of the surrounding chain for that idea to enter phones, broadband services and the Linux kernel, then continue without depending on him.