Summary

  • The Energy Sciences Network, commonly called ESnet, is a scientific network infrastructure of the US Department of Energy’s Office of Science, operated by the Lawrence Berkeley National Laboratory. It is neither a commercial carrier nor an independent company, but federal infrastructure built for science.
  • ESnet6 brings together about 15,000 miles of dedicated fibre infrastructure, optical systems, packet routing, private networks, interconnection with clouds and research networks, measurement tools, and programmable services. The 2024 annual report recorded 57 Tbps of aggregate capacity and 1.77 exabytes of annual traffic, but the numbers measure different aspects of the system and do not mean that every user has a 57 Tbps path.
  • One of ESnet’s most lasting contributions may be its end-to-end engineering model. Science DMZ, perfSONAR, iperf3, OSCARS, SENSE, High-Touch, and EJFAT address the local systems, network reservations, telemetry, and real-time data movement that determine whether backbone capacity turns into useful scientific performance.
  • The next strategic step is not just a faster backbone. American Science Cloud, integrated research infrastructure, ESnet7 planning, real-time instrument streaming, field wireless networks, and quantum network control point toward a network that participates directly in scientific workflows. Maturity levels vary, and planning or demonstrations should not be presented as universal production services.

A scientific network, not a retail internet provider

The simplest way to understand ESnet is to follow a piece of scientific data. A detector, telescope, microscope, or simulation produces information at a laboratory or research facility. Local acquisition systems collect the data, storage and transfer servers prepare it for transport, and the laboratory network carries it to a controlled perimeter. From there, an ESnet connection can carry the data across the United States, across the Atlantic, to a Department of Energy supercomputer, through a research and education network, or into a commercial cloud.

The result returns as an analysed dataset, an alert, a model, or a decision about the next step of the experiment.

No single organisation controls this entire journey. The instrument team, the laboratory network, the regional research network, the cloud provider, the international partner, and the supercomputing facility may belong to different operators. ESnet provides the long-distance mission-oriented layer and works with the other operators so that the path works as a system. A slow storage server, a congested campus link, or an unsuitable firewall can waste the capacity of a fast national backbone, just as an ESnet failure can disrupt a well-designed local facility.

The institutional position is also specific. ESnet is a network facility of the Department of Energy’s Office of Science, funded and overseen primarily through Advanced Scientific Computing Research and operated by the Scientific Networking Division at the Lawrence Berkeley National Laboratory. Berkeley Lab itself is managed for the Department of Energy by the University of California under a laboratory operating contract. ESnet has no identified shareholders, shares, corporate valuation, or independent trading accounts. It should be described as federal scientific infrastructure, not as a company that sells network services.

Researchers usually encounter ESnet indirectly. They use an instrument, a supercomputer, a laboratory service, a university connection, or a collaborating network whose traffic traverses ESnet. The facility distinguishes institutional users from sites and end users, and states that it does not register or formally track every individual end user. The figure of more than 30,000 organisational users presented in the 2024 annual report is therefore a dated institutional measure, not an accurate subscriber count.

This operating model explains why comparisons with conventional carriers are incomplete. ESnet operates routing, optical transport, and interconnection, but it also carries out requirements reviews, develops open-source tools, builds experimental services, and helps sites fix end-to-end performance problems. Its product is not a retail connection. It is the ability to make geographically distributed scientific facilities work as components of a single shared machine. (ESnet Governance;network services)

The story begins with scarce computers and acoustic modems

ESnet’s official history traces back to the mid-1970s, when both computing and long-distance communications were scarce. At the Controlled Thermonuclear Research Computer Center at Lawrence Livermore National Laboratory, staff connected a borrowed Control Data Corporation 6600 through four acoustic modems. The equipment and speeds belong to another era, but the operational problem remains recognisable: a specialised scientific community needed remote access to computing capacity too expensive to reproduce at every participating institution.

Different Department of Energy research communities developed their own networks during the late 1970s and early 1980s. High-energy physics and magnetic fusion research had distinct facilities, collaborators, and data flows, and precursor networks such as HEPnet and MFEnet reflected those boundaries. Purpose-built networks were rational when commercial services lacked sufficient reach, performance, or operational attention. At the same time, they created duplication: each programme could negotiate circuits, maintain technologies, and develop expertise independently, leaving collaboration and long-term upgrades fragmented.

The formal creation of ESnet in 1986 consolidated these functions into a wider scientific network. The change was as much organisational as technical. A shared facility could forecast demand from multiple programmes, operate national links, coordinate international connections, and retain specialist professionals. It could also turn capacity from an isolated project concern into an infrastructure plan for the entire Department.

The initial model established several features that remain visible today. Users were defined by scientific mission, not a retail market. Central computers and instruments justified shared public investment. The network design tracked research programmes with long horizons. Operation required professionals who understood both the communications systems and the scientific consequences of a failure. Demand arrived in bursts, because a single experiment could generate traffic well above the usual baseline.

Berkeley Lab also had its own networking history. In 1974 it connected a CDC 6600 to the ARPANET, and laboratory researchers later contributed to foundational work on TCP congestion control. The work of Van Jacobson and Mike Karels belongs to the broader Berkeley Lab environment and should not be attributed solely to ESnet. The institutional overlap, however, was important: it placed a production science network close to researchers who treated protocol behaviour, measurement, and performance as engineering problems that could be studied rather than as fixed conditions.

Operations moved to Berkeley Lab in 1996. The move established the current headquarters alongside the National Energy Research Scientific Computing Center, network researchers, software engineers, and other Department of Energy programmes. It also reinforced a culture in which a production facility and an applied research organisation share professionals, laboratories, and technical questions. (ESnet history)

Why the network became a shared scientific facility

A shared scientific facility exists because some capabilities are too expensive, specialised, or interdependent for every research team to build them alone. A particle accelerator, a light source, or a leadership supercomputer follows this logic. ESnet applies the same principle to communications. Long-distance fibre rights, optical equipment, routers, international capacity, continuous operations, cybersecurity, performance measurement, and engineering support are pooled into a single facility that serves multiple programmes.

The case for public funding follows the shape of scientific demand. A commercial carrier may sell a high-capacity circuit, but it does not normally define its national architecture around a detector scheduled to start operating years later, a flow associated with a supernova that may never occur during the contract, or a workflow with little retail volume but high public value. ESnet can build before utilisation is measured because its mandate is to create scientific capability, not to generate short-term network revenue.

The facility model also changes how demand is identified. ESnet conducts formal requirements reviews with DOE science programmes. Researchers and facility staff describe instruments, data volumes, storage locations, computing destinations, timing needs, collaboration patterns, and local bottlenecks over a five- to ten-year horizon. Those findings guide site connection capacity, route diversity, transatlantic procurement, orchestration research, and service design.

This process is less visible than a new coherent optical connection, but it may be more important. A subsea spectrum agreement, a router purchase, or a second physical entry into a site can take years to fund and deploy. Waiting until an experiment starts producing data would turn predictable infrastructure needs into emergencies. Requirements reviews convert scientific plans into engineering lead time.

The reviews also make uncertainty explicit. Forecasts may change, instrument schedules may slip, data reduction software may improve, cloud usage may grow, and a facility may redesign its workflow. ESnet does not treat a case study as a guaranteed traffic order. It uses the evidence to build a range of requirements and to decide where flexibility, reserve capacity, or phased deployment is warranted.

The model avoids charging every scientist per gigabyte. Core operations receive federal funding, while some site connection costs may be distributed according to programme sponsorship and the Site User Cost Policy. That does not remove incentive differences. A sponsoring programme may prefer a cheaper connection; ESnet may prefer capacity and resilience that serve multiple programmes; and a site may postpone local upgrades needed to use the national network. The governance task is to align these decisions with scientific outcomes, not to let each institution simply shift costs onto another budget line. (ESnet Site Coordinators Committee and cost policy;requirements review reports)

Berkeley Lab operates the system, while DOE sets the mission

ESnet does not have a carrier’s corporate hierarchy. Its authority is distributed across a chain of federal programmes. The Department of Energy’s Office of Science sets the mission. Advanced Scientific Computing Research provides the principal programmatic and budgetary oversight. Berkeley Lab hosts the Scientific Networking Division, which is responsible for designing, operating, and developing the facility. The University of California manages Berkeley Lab for the Department under contract. Connected institutions participate through site coordinators and the ESnet Site Coordinators Committee.

Inder Monga serves as Executive Director of ESnet and leads the Scientific Networking Division at Berkeley Lab. Public leadership also identifies Chin Guok as Chief Technology Officer and head of Planning and Innovation, Adam Slagell as Chief Security Officer, Jon-Paul Herron as Director of Network Engineering, and Susan Lucas as Deputy of Business Operations. Beneath these posts sit roles in optical engineering, routing, site engineering, network operations, software, measurement, orchestration, security, project management, and science community engagement.

The breadth of this structure corrects the simplified picture of a national network as a collection of fibres and routers. ESnet needs professionals who can procure spectrum, operate BGP, build telemetry systems, maintain open-source software, investigate packet behaviour, plan installations, manage security evidence, and translate scientific requirements into network designs. The organisation is simultaneously operational and development-oriented.

Public records present an unresolved programme management question. ESnet’s current governance page identifies Benjamin Brown as its designated programme manager in ASCR, while recent requirements review materials identify Carol Hawk as ESnet programme manager. The public sources may not have been updated in a coordinated way, or responsibilities may have changed or been split. The available data do not support choosing a single current structure without additional confirmation.

The ESnet Site Coordinators Committee gives connected institutions a formal operational channel. Each site names a coordinator who can approve requests affecting the institution’s connection, communicate requirements, and take part in policy or planning discussions. This is institutional user governance, not direct voting by every scientist whose data cross the network.

This structure creates a practical division of responsibilities. ESnet controls its backbone and services. A connected site controls its campus equipment, Data Transfer Nodes, local security, and power. ASCR controls programme-level funding. The science programmes define the consequences of delays or failures. International partners control their own networks. The full workflow works only when these different decision areas remain aligned. (ESnet leadership;governance)

ESnet4 separated ordinary IP traffic from large science flows

By the mid-2000s distributed experiments were starting to change the traffic profile. The Large Hadron Collider would produce data at CERN and distribute them through a global hierarchy of laboratories and computing centres. General internet connectivity was still needed, but a small number of science transfers could be large enough to overwhelm ordinary links. Building a single undifferentiated network for both patterns made it harder to manage capacity and offer service guarantees.

ESnet4 responded with a hybrid architecture. An IP core carried general science communications. A separate Science Data Network used high-capacity optical circuits for large flows and allowed dynamic path provisioning. Metropolitan rings connected the main laboratories, while collaboration with Internet2 and international partners extended the system beyond DOE sites.

The difference was not simply between slow and fast traffic. General IP service needs wide reach and resilient routing. A planned multi-terabyte transfer can benefit from a reserved Layer 2 path with known start time, capacity, and endpoints. The Science Data Network recognised that a small number of predictable, high-value flows could justify a different control model from conventional packet forwarding.

OSCARS emerged in this environment. The On-demand Secure Circuits and Advance Reservation System let authorised users or applications request network resources for a defined period. The system needed to find a path, check topology and policy constraints, reserve capacity and VLAN resources, create the state on the devices, and remove that state when the reservation ended. It turned a task previously done through manual coordination into a service that software could request.

ESnet4 also showed that raw speed was no longer the only bottleneck. A reserved circuit can protect capacity on the long-distance network, but the application may still be slow if a storage system cannot read the data quickly enough or if a local firewall discards packets. That insight led directly to the Science DMZ architecture and end-to-end measurement.

The period established a recurring pattern in ESnet design. A scientific problem appears first as a traffic requirement. The facility builds physical capacity, a control mechanism, and an operational method around that requirement. When the method proves useful, the software and architectural guidance spread beyond the original experiment. (Historical material on ESnet4 and ESnet5;OSCARS)

Science DMZ pushed the bottleneck to the institutional edge

A national backbone can work correctly while the researcher faces poor transfer performance. The reason is straightforward: the backbone is only one segment of the path. Enterprise firewalls, shared campus cores, ageing routers, underpowered servers, packet loss, and storage limitations can reduce a high-capacity route to a fraction of its designed speed.

Science DMZ is ESnet’s answer to this end-to-end reality. The architecture places Data Transfer Nodes on a high-performance path close to a controlled institutional perimeter. Security policy is tailored to the limited services exposed by those systems, rather than forcing sustained science flows through a general-purpose stateful firewall designed for many categories of enterprise application.

The phrase can be misread as a proposal to remove security. A Science DMZ still depends on hardened hosts, router access-control lists, monitoring, vulnerability management, limited application exposure, and operational discipline. The design changes where and how controls are applied. It avoids placing in the main path a device with inadequate session performance or behaviour simply because that device is part of the institution’s conventional security standard.

Performance measurement is built into the architecture, not an optional dashboard. perfSONAR nodes run controlled tests of throughput, packet loss, latency, and path changes. When two sites disagree about a transfer, the measurements can help localise whether the problem starts in a host, a local link, a regional network, the ESnet backbone, or an international partner. Without that evidence each operator can assert that its own segment is healthy while the researcher remains unable to transfer the data.

Data Transfer Nodes also need their own engineering. Network cards, CPU placement, memory, disks or parallel file systems, TCP buffers, and transfer software determine achievable throughput. The Fasterdata guidance and ESnet’s technical consultancy turn these details into repeatable practices. The approach has spread well beyond the DOE laboratories, but ESnet does not operate every installation that uses the name.

Science DMZ became influential because it turned a procurement question into a systems question. Buying a faster circuit does not fix a path that is limited elsewhere. The useful unit of performance is the full workflow, from storage to storage or from instrument to computing, with each administrative domain measured and linked to clear responsibility. (Science DMZ guidance;network performance tools)

ESnet5 brought continental 100G into production

The next capacity transition was supported by the Advanced Networking Initiative and funding from the US economic stimulus programme. ESnet received $62 million through the American Recovery and Reinvestment Act to develop a 100 Gbps long-distance prototype and support the migration to ESnet5. The investment included more than new routers. ESnet obtained rights to spectrum capacity on a national fibre infrastructure, giving the programme more control over wavelength deployment and upgrade.

ESnet5 entered production in late 2012. At the time DOE and ESnet described it as the world’s fastest science network. That historical claim was attached to a pioneering continental 100G deployment. It should not be repeated as an unqualified world ranking in 2026. Research networks now publish capacity by different measures, including individual interface speeds, aggregate backbone capacity, optical spectrum, and experimental demonstrations. The available evidence does not provide a neutral current comparison that establishes a universal winner.

The economic effect of 100G was larger than a tenfold interface upgrade. Science projects could plan routine long-distance transfers that had previously occupied links for much longer. Laboratories could centralise some computing or storage instead of reproducing them locally. International collaborations gained a more capable North American backbone. The new capacity also exposed local limitations more quickly, increasing the value of Science DMZ and perfSONAR.

ESnet5 maintained the hybrid relationship between packet services and dedicated science paths. It also deepened the importance of automation. At 100G scale, reserving capacity, diagnosing failures, and maintaining consistent services across a national infrastructure could not rely solely on one-off device configurations.

The project shows how public infrastructure investment changes scientific options before any single experiment fills the network. Capacity creates a reserve for future instruments, but that reserve is not waste in the same way as idle retail capacity. Its value includes avoiding experiment delays, accommodating failures, and allowing new workflows to be tested without waiting for another build cycle.

That logic also demands discipline. Announced capacity needs to be linked to real scientific use, and investments must stay adaptable when forecasts change. ESnet’s later work on telemetry, caching, and orchestration reflects an effort to extract more scientific value from every installed bit, rather than treating continuous physical expansion as the only answer. (Historical ESnet5 announcement)

ESnet6 is an optical, packet, and software system

The ESnet6 project began in 2017 and was publicly launched on 11 October 2022, after roughly six years of design and construction. Berkeley Lab reported more than 46 Tbps of aggregate capacity at launch, spread across a dedicated infrastructure of about 15,000 miles, with backbone links between 400 Gbps and 1 Tbps. The 2024 annual report later recorded 57 Tbps and links up to 1.2 Tbps. The figures belong to different dates and describe an expanding system, not conflicting definitions of a static network.

The physical layer includes long-distance fibre paths, optical line systems, amplifiers, spectrum rights, colocation facilities, and local entry points. The 2024 report counted 278 locations with optical amplifiers. Coherent optics carry multiple high-speed channels over fibre, while amplifiers and reconfigurable optical equipment maintain signal levels and steer wavelengths. A path shown on a map may be controlled through dark fibre, spectrum, a lit service, or a partner agreement. The 15,000-mile description does not establish that the Department of Energy holds legal title to every cable.

Above the optical layer, routers and service edges supply IP, private routing environments, Layer 2 services, peering, and connectivity to clouds. The annual report counted 78 locations with routers. Individual sites may connect at 10, 100, or 400 Gbps depending on requirements, while backbone links can aggregate several interfaces or wavelengths to reach higher values.

The software layer sets ESnet6 apart from a capacity-only upgrade. Automation maintains device and service state. Programmable telemetry supplies more detailed evidence to operators. OSCARS provisions reserved paths. SENSE experiments with application-driven coordination across different domains. High-Touch uses programmable hardware to deliver greater visibility over packets and flows. APIs and testbed interfaces let successful research advance towards operations.

The build also gave greater weight to resilience. Diverse routes, multiple site entries, independent power, alternative routers, and high-availability locations reduce the chance that a single failure removes a laboratory from the national system. These protections have different scopes. A redundant backbone does not help if both local circuits run through the same duct, and a second router does not create resilience when both devices depend on the same power feed.

ESnet6 must therefore be understood as a layered facility. The fibre creates physical reach. The optics create capacity. The routers create packet services and private networks. The software creates repeatability and programmability. The measurement verifies that the promised path actually works. Organisational agreements enable crossing boundaries that ESnet does not own. (ESnet6 launch;2024 annual report)

What 57 Tbps means — and what it does not

Network statistics often condense several layers into a single number. The 57 Tbps that ESnet reported for 2024 represent aggregate engineering capacity distributed across the system. They do not correspond to a single physical link, to the throughput available to every laboratory, or to the traffic carried at every moment. The same report describes backbone links between 400 Gbps and 1.2 Tbps, seven US sites connected at 400 Gbps or above, and 2.7 Tbps of transatlantic capacity. Each number answers a different question.

The report also described 78 locations with routers and 278 locations with optical amplifiers across an infrastructure of roughly 15,000 miles. The network connected all 17 DOE national laboratories and counted 28 DOE user scientific facilities, 277 relationships with research and education networks, commercial networks, and other network types across five countries, more than 30,000 organisational users, and 137 staff and contractors spread across 24 states.

The numbers describe different populations and should not be summed as if they form a customer total: routers, facilities, partner networks, institutional users, and workforce are separate measures.

A site connection represents capacity at an institutional boundary. A backbone link represents capacity between network points. An optical system may carry several wavelengths, and a logical service may use only part of the physical layer. Aggregate capacity sums many resources that cannot simultaneously serve the same source and destination. Traffic volume measures data carried over time, not the peak rate available at an instant.

ESnet carried 1.77 exabytes during calendar year 2024, up from 1.7 exabytes in 2023. The 4% increase was low compared with the historical average annual growth of about 55% that the facility has reported since 1989. A single year does not demonstrate that scientific demand has plateaued. Large projects come online irregularly, software changes may reduce transfers, and a single international experiment or event can quickly change the traffic mix.

Traffic is also concentrated. The 2024 report stated that Large Hadron Collider activities accounted for roughly half of all traffic. Fermilab was the largest external sender at 136 petabytes; NERSC was the largest DOE recipient at 75.3 petabytes; and Oak Ridge was the largest DOE sender at 58.3 petabytes. These figures reveal important workloads but do not constitute a complete ranking of scientific value. A smaller transfer may be more urgent or support a one-of-a-kind instrument.

Capacity planning therefore requires several perspectives at once: average and peak traffic, utilisation by route, reserve for failures, site link speeds, scientific timelines, and future requirements. A network designed only around average use may fail during a supernova or a cable break. A network designed only for the largest theoretical event may create expensive, inflexible assets.

ESnet’s engineering problem is to place capacity where the workflows that need it can reach it, and then to verify that the end systems can use it. That is why the capacity figure must be presented alongside Science DMZ, measurement, orchestration, and requirements reviews, and not as a self-explanatory ranking at the top of the article. (ESnet by the Numbers)

AS293 routes for a mission, not a retail market

ESnet’s public autonomous system number is AS293. The network exchanges routes with DOE sites, research and education networks, commercial networks, and paid transit providers. Routing policy determines which paths can carry scientific traffic, how failures are handled, and which external networks receive direct interconnections.

The peering policy is selective. Potential peers must use BGP, maintain current information in the Internet Routing Registry and PeeringDB, avoid RPKI-invalid announcements, and follow routing security practices associated with MANRS. ESnet requires IPv6 or dual-stack peering and will not accept new IPv4-only relationships. Direct private interconnection starts at a 100G port, with a strong preference for 400G.

These conditions reflect mission and operational cost. A direct interconnection consumes ports, engineering time, and monitoring capacity. ESnet does not need to peer with every network just because public routes exist. It seeks relationships that improve DOE scientific paths, reduce transit dependence, or connect important collaborators. Public internet access is supplemented by paid transit from Hurricane Electric and Lumen for destinations not reached efficiently by research networks or direct peering.

The network publishes BGP communities that differentiate ESnet-connected sites, research and education networks, and commercial networks. Connected institutions can use these markings to apply policy, although downstream interpretation remains outside ESnet’s control. A community is descriptive metadata, not a universal guarantee that every network will make the same routing decision.

Routing security also has limits. Rejecting RPKI-invalid announcements blocks one important category of misroute, but it does not prevent all leaks, compromised peers, valid origins mistakenly announced, or incorrect origin authorisations. Hijack monitoring can identify unexpected origin changes, but detection may occur after propagation. Blackholing can protect a site during an attack by discarding traffic destined for an address, but that protection works by sacrificing reachability of the affected prefix.

Mission-driven design appears in the service boundaries. ESnet carries public IP traffic but does not seek to win the consumer transit market. Its route policy is organised around scientific reach, resilience, and trustworthy interconnection. The network’s value comes from the quality of the paths it creates for the community it serves, not from maximising the number of retail customers attached to AS293. (ESnet peering policy)

Physical connections, private services, and paths to the cloud

ESnet’s service catalogue starts with physical connectivity. Eligible sites can connect locally or through a remote point of presence at 10, 100, or 400 Gbps. When a facility lies distant from the dedicated infrastructure, a Service On-Ramp may use dark fibre or a lit circuit provided by a carrier. Access design is part of the scientific path, and the last segment provided by a third party can become the main performance limit or failure point.

Layer 3 IP service offers routed connectivity in both IPv4 and IPv6. A Layer 3 virtual private network creates a separate logical IP and BGP environment for a multi-site programme while sharing the physical infrastructure with other services. Layer 2 virtual private networks provide point-to-point or multipoint Ethernet connectivity, configured statically or provisioned through OSCARS. These services let experiments connect facilities without exposing every relationship over the public internet.

Private service does not mean physically isolated service. Logical separation depends on router configuration, tagging, routing instances, access controls, and operational practices. A shared platform failure can affect several services, while a configuration error can break the intended separation. The value lies in controlled segmentation and predictable connectivity, not in claiming that no shared dependencies exist.

Cloud Connect extends ESnet paths to major commercial cloud environments, including AWS, Microsoft Azure, Google Cloud, and Oracle. A site can reach the provider’s entry point over dedicated Layer 2 or Layer 3 connectivity, rather than relying on ordinary public internet routing. This can improve path control and reduce exposure to variable transit, but it does not eliminate cloud-side security, provider failures, identity design, data egress costs, or regional availability.

The cloud relationship shows how ESnet’s role is changing. DOE science no longer exists only in federal laboratories and supercomputers. Researchers may use commercial object storage, specialised services, or on-demand computing. ESnet must connect these resources without claiming that the cloud is part of the federal network or that a private circuit makes a cloud account secure by itself.

Other services include secondary DNS, network time, route hijack monitoring, and blackholing. Each addresses a supporting dependency that can disrupt research even when optical capacity remains available. A name failure, incorrect time, route leak, or denial-of-service attack can make a scientific system unusable without damaging the fibre.

Together the service catalogue represents a series of operational contracts between network layers. Physical connectivity establishes the path. Routing creates reach. Private services create logical boundaries. Cloud interconnection extends the system to commercial infrastructure. Security and support services reduce known failure modes. The user still needs to build a working endpoint and local network at each end. (ESnet network service catalogue)

OSCARS makes capacity reservable

Most internet traffic uses the capacity that is available when packets arrive. That model works well for general communications, but some science transfers are scheduled, large, and costly to delay. OSCARS lets authorised users and applications reserve network resources for a specific period.

A reservation can identify endpoints, start and end times, capacity, VLAN information, route exclusions, and other constraints. The system examines the topology and existing commitments, finds an acceptable path, creates the needed state on the network, and removes it when the reservation ends. The service must prevent the same scarce resource from being allocated twice and must consider maintenance or failures that change the available topology.

The importance is operational, not cosmetic. Manual circuit provisioning can require days of coordination among engineers. A programmatic reservation can be created in minutes and become part of an experiment’s workflow. The network moves from being a fixed background pipe to a resource that software can request alongside storage or computing.

OSCARS is an open-source production system and has been adopted or evaluated by other networks and testbeds. Some public adoption metrics appear on pages that also include historical material. The safe conclusion is that the system has spread beyond ESnet, without assuming that every listed deployment remains current or technically identical.

A reservation does not guarantee application throughput. It can protect a defined amount of network capacity, but it cannot make a storage server read faster, fix packet loss on a campus network, or tune an operating system. If the application achieves only a fraction of the reserved rate, the diagnosis must return to the end-to-end path.

Reservations also raise allocation questions. A priority experiment may benefit from guaranteed capacity, while unused reservations can reduce flexibility for other users. Policies must decide who may request the service, how conflicts are resolved, and whether a reservation can be pre-empted in favour of another. These decisions are part of facility governance, even when the provisioning code is automated.

OSCARS remains one of the clearest examples of ESnet applied software turning into infrastructure. It converted an operational practice into a repeatable service, preserved human policy around authorisation, and gave scientific applications a controlled way to express network requirements. (OSCARS)

SENSE tries to coordinate the network with end systems

A reserved network path solves only one part of a distributed workflow. Storage systems, transfer services, and computing resources also have their own availability, capacity, and policies. SENSE — Software-defined network for End-to-end Networked Science at the Exascale — extends orchestration beyond a single network domain.

The project models networks and end systems as resources that can be discovered. A scientific application can describe the intended outcome, such as moving a dataset between facilities at a given rate. SENSE assembles models of the participating domains, negotiates resources, provisions network and transfer services, observes telemetry, and releases the resources when the workflow finishes.

This is harder than configuring a single circuit. The participating organisations keep their own authority and data models. One domain may expose capacity while another exposes storage endpoints or transfer services. Policies, credentials, and maintenance windows differ. SENSE must coordinate these elements without assuming that a central controller can command every system.

During the 2024 Large Hadron Collider Data Challenge, SENSE-enabled workflows sustained 330 Gbps between Caltech and the University of California, San Diego. The result shows that application-driven orchestration can operate at a substantial rate in a specific real workflow. It does not prove that SENSE is a universal production service at every ESnet site. The 2024 report still described the project as being in the research phase.

The distinction between OSCARS and SENSE reveals an evolution in the unit of automation. OSCARS reserves network resources within a known service domain. SENSE attempts to negotiate a full path that includes systems belonging to different organisations. The first has a clearer production boundary. The second offers greater scientific value but carries more governance and integration risk.

For operators the practical question is who answers for the failure. When an application declares an intent and the workflow underperforms, the cause may lie in the resource model, the network, the storage, a credential, the application, or a synchronisation problem between domains. Orchestration must supply evidence precise enough to show each operator which part of the negotiated state diverged.

SENSE points toward an infrastructure in which applications request outcomes rather than just circuits. Its progress should be measured by repeatable multi-domain production use, clear support responsibilities, and the ability to recover from partial failures, not only by the highest demonstrated transfer rate. (SENSE;2024 applied research)

EJFAT carries scientific events directly to remote computing

Traditional science data movement often follows a file-based sequence. An experiment produces data, local systems process them until they can be written to files, the files enter storage, and a later transfer sends them to another facility for analysis. This pattern is well understood and operationally reliable, but it delays feedback and demands local storage and computing scaled to peak acquisition.

EJFAT — ESnet–Jefferson Lab FPGA Accelerated Transport — offers a different path. It streams real-time event data, encapsulated in UDP, from an instrument to available computing workers, possibly at a remote supercomputing centre. A programmable FPGA-based SmartNIC reads the event identifiers and forwards all fragments belonging to the same event to a single worker. As computing nodes become available or busy, the control system can change the distribution.

Event grouping matters. A generic load balancer can distribute packets across servers, but scientific processing may require every fragment of a detector event to reach the same worker. EJFAT separates the high-speed forwarding function from the scheduling of computing workers and lets each side scale independently.

In April 2024 a demonstration streamed data from Jefferson Lab in Virginia to the Perlmutter supercomputer in California at 100 Gbps for real-time processing without an intermediate disk step. Later tests used computing resources at several facilities and roughly 20,000 cores, according to ESnet reports. These are specific demonstrations, not a guarantee that every instrument can adopt the system without engineering changes.

The Facility for Rare Isotope Beams offers a more recent operational example. ESnet reported in July 2026 that researchers streamed raw experiment data through EJFAT at approximately 5–6 Gbps to remote supercomputers. A run that produced 615 GB over 15 hours was processed in 20 minutes on eight Perlmutter nodes using machine learning inference. The lower network rate than the 100G demonstration does not make the result less important; the scientific benefit was faster feedback during a real workflow.

Real-time streaming changes the economics of a facility. A detector can use shared computing rather than building enough local capacity for every peak. Researchers can examine results while scarce beam time is still available. The system also creates new dependencies. A network interruption, a computing allocation issue, or an error in event distribution can affect the experiment in real time, rather than just delaying a later file transfer.

EJFAT remains an advanced prototype or emerging platform, not a universally supported service. Production adoption will require integration with instruments, security, FPGA availability, operational responsibility, scheduling agreements, and clearly defined behaviour when UDP packets are lost. Its importance lies in showing that the long-distance network can be part of the acquisition loop, not just arrive after it. (EJFAT;FRIB science highlight)

High-Touch, perfSONAR, and iperf3 make the path observable

A high-capacity network can fail in ways that aggregate utilisation graphs do not reveal. Brief bursts can fill a queue, packets can arrive out of order, loss may affect only one direction or one traffic class, and a route can change between tests. Security-relevant flows can also disappear inside statistical sampling.

High-Touch uses programmable hardware and software to collect packet and flow telemetry more detailed than traditional sampled records. In 2024 it was used to investigate Large Hadron Collider throughput, packet reordering associated with Rubin Observatory traffic, and security events. The goal is diagnostic precision and identifying behaviours that an aggregate traffic total would hide.

Deeper evidence has a cost. Packet and flow information require storage, processing, access controls, and careful interpretation. They can reveal communicating endpoints, collaboration patterns, and the timing of scientific activities. A system built to provide operational visibility therefore becomes a sensitive data asset.

perfSONAR operates at another layer. It is a distributed measurement system supported by a multi-organisation partnership, in which ESnet is a core entity and founder. More than 2,000 locations were reported globally in 2024, and ESnet operates more than 30 sites. Controlled tests measure throughput, latency, loss, and path behaviour between participating nodes.

The distributed design is central. A researcher may report a slow transfer, but a test between well-placed perfSONAR nodes can show whether the underlying path supports the expected rate. Directional tests can isolate asymmetries. Repeated measurements can reveal when the degradation began. Traceroute data can identify a path change, although the observed route and the application’s actual forwarding behaviour may differ.

iperf3 provides active throughput tests over TCP, UDP, or SCTP, with support for both IPv4 and IPv6. ESnet maintains the open-source tool and reports tests above 150 Gbps on 200G paths, under specific conditions. A synthetic test is not an application benchmark. It helps determine whether the host and network can carry traffic under controlled conditions, after which storage and application behaviour can be investigated separately.

Together, High-Touch, perfSONAR, and iperf3 offer different views of reality. High-Touch observes production flows with greater precision. perfSONAR supplies scheduled or on-demand measurements across multiple domains. iperf3 directly tests endpoint and network throughput. No single view is complete, but the combination reduces the temptation to diagnose a distributed failure from a single operator’s local dashboard. (Network performance tools;2024 operational innovations)

Caching can remove traffic instead of carrying it faster

Adding capacity is not the only way to improve a science network. Some datasets are requested repeatedly by researchers in the same region. Carrying every copy over the long-distance network wastes capacity and increases delay, even when the backbone can absorb the load.

ESnet’s 2024 applied research report described five regional cache nodes used by science data communities. In the study set the caches reduced long-distance traffic by an average of 33 terabytes per day. Two thirds of the requests were served locally, and the average cache hit rate was 94%. The effect varied significantly by location: the reported long-distance traffic reduction reached 69.3% in Southern California, 48.4% in Chicago, and 6.6% in Boston.

The differences are informative. A cache’s value depends on dataset popularity, local users, storage size, replacement policy, and service configuration. A cache placed close to a community that repeatedly analyses the same data can eliminate large transfers. A cache serving diverse or rarely repeated datasets may consume storage without producing the same benefit.

Caching also changes control. The network operator begins to take part in data placement, while science communities must decide which datasets can be copied, how freshness will be maintained, and who is authorised to access them. Storage failures and stale content become operational concerns adjacent to the network.

The study shows why the most efficient bit may be the one that never enters the backbone. Optical upgrades increase supply. Caching changes demand. Workflow scheduling can shift transfers outside peak periods. Compression or local filtering can reduce data before transmission. A mature infrastructure programme evaluates all these mechanisms, rather than measuring progress only by terabits installed.

The result should remain limited to the studied deployment. It does not prove that every science dataset will achieve a 94% hit rate or that caching can replace new capacity for unique real-time flows. It provides evidence that data architecture and network architecture can be designed together. (2024 applied research activities)

Transatlantic science demands physical diversity and capacity

ESnet’s domestic infrastructure cannot be separated from its international obligations. High-energy physics is organised around facilities and computing centres on both sides of the Atlantic, and the 2024 annual report attributed roughly half of ESnet’s traffic to Large Hadron Collider activities. A cable failure between Europe and North America can therefore affect a core science workload even when every domestic router is working.

During 2024 and early 2025 ESnet expanded its reported transatlantic capacity from approximately 700 Gbps to 2.7 Tbps. A major part of the programme was a 15-year agreement with Aqua Comms for a quarter of a fibre pair on a route linking New York, Dublin, and London. ESnet also shares capacity and costs with GÉANT on several cable systems. The engineering goal is to reach at least 3.2 Tbps over four physically diverse paths, with an architecture capable of growing beyond 10 Tbps.

The difference between capacity and diversity is decisive. Two logical services can share a cable, a landing station, or a terrestrial duct and fail together. Subsea repair can require fault location, permits, a cable ship, suitable weather, and physical recovery of the damaged fibre. Restoration can take weeks or months. That is why ESnet plans for scenarios with three simultaneous cable failures, rather than assuming a single backup route is enough.

Long-term spectrum rights give the facility more upgrade control than repeated purchases of turnkey circuits. They also create commitments to particular cable systems, landing infrastructure, and operational partners. ESnet does not remove maritime risk by procuring spectrum. It gains the ability to design capacity and resilience across several systems but remains dependent on cable owners, repair processes, and partner networks.

This is another context in which the word “dedicated” requires care. ESnet controls dedicated rights and infrastructure on important routes, but the physical asset model varies. Domestic and international paths may involve dark fibre, spectrum, lit services, colocation, and partner capacity. A line on a map does not reveal the same level of ownership or repair authority on every segment.

The relationship with GÉANT shows why research networks can be cooperative without being centrally controlled. The two organisations can share costs and coordinate scientific traffic, but each remains responsible to its own institutions and members. End-to-end performance still depends on national research networks, campus systems, and experimental facilities that lie beyond the control of both backbones. (Transatlantic milestone;2024 annual report)

Scientific demand combines steady scale, rare peaks, and hard deadlines

The Large Hadron Collider supplies steady scale. Its distributed computing model moves experiment data between CERN, Fermilab, Brookhaven, universities, and other centres, producing sustained international traffic. The planned high-luminosity operation is expected to increase detector data, simulations, and replication. The network needs to carry huge flows routinely while keeping enough route diversity to survive cable or facility failures.

The Vera C. Rubin Observatory imposes a deadline. The telescope in Chile is designed to produce an image of roughly 13 GB every 30 seconds. The data path allows fast processing at SLAC and the generation of transient entity alerts so that other observatories can respond. ESnet reports a goal of carrying each image over approximately 12,000 miles in less than seven seconds. The route includes partner research networks in South America and elsewhere, so the result depends on coordinated engineering beyond ESnet’s domain.

DUNE creates an exceptional peak. During a supernova the neutrino programme foresees the need to move up to 600 TB in 100 seconds. Over twenty years the programme is expected to generate roughly 900 PB. These are planning requirements for a future operation, not a description of current traffic. They matter because the event cannot be rescheduled once capacity is available. A network built only around average utilisation may fail at the moment of greatest scientific value.

Fusion research combines international distance with a long development horizon. In May 2026 a test moved 176 TB of data from ITER in Marseille to the DIII-D facility at General Atomics in San Diego at nearly 80 Gbps. ITER was still under construction, so the transfer demonstrated readiness rather than routine full-scale operation. Requirements materials foresee some future fusion workflows at about two petabytes per day and at least 200 Gbps.

FRIB and Jefferson Lab show a third pattern: the experiment may need remote analysis while the data are still arriving. EJFAT lets event streams reach computing resources at NERSC or Oak Ridge without waiting for files to be completed and copied. Light sources, electron microscopes, and other instruments face similar decisions about local filtering, remote AI inference, and how quickly results must return to the operator.

Climate and Earth sciences broaden the demand again. Large simulations and observational datasets move between computing and storage facilities, while field sensors may be located where conventional fibre is unavailable. No single announced rate represents all these needs. ESnet must serve persistent bulk transfers, rare spikes, low-latency feedback, international collaboration, and remote acquisition within the same facility model. (Rubin Observatory case study;DUNE case study;requirements reviews)

Requirements reviews turn science plans into network architecture

ESnet cannot wait for an experiment to produce its first dataset before procuring fibre, routers, or transatlantic capacity. Long-distance agreements, equipment purchases, site construction, and software development take years. The facility therefore carries out requirements reviews with DOE science programmes over a five- to ten-year horizon.

Researchers and facility staff describe instruments, expected data volumes, storage locations, computing destinations, time constraints, international collaborators, cloud use, and resilience needs. Networking and computing specialists then analyse the full workflow. A request for a larger link may reveal a more important problem in local storage, route diversity, security architecture, or transfer software.

The review process is a form of co-design. The science programmes explain what they are trying to do; ESnet translates the goal into infrastructure dependencies and tests whether the proposed path can work. The outcome may influence site connection capacity, new routes, subsea procurement, Science DMZ deployment, orchestration research, staffing, and the schedule for a future network generation.

The main High Energy Physics review, completed in 2025 and published in January 2026, involved 127 entities and 14 case studies in a report of about 400 pages. Its importance is not in guaranteeing that every forecast is correct. Instruments may be delayed, software may become more efficient, and new workloads may appear. The value lies in a documented record in which researchers, network engineers, computing centres, and funders can examine the same assumptions and revise them deliberately.

Forecasting remains hard because scientific demand is discontinuous. A supernova may never occur during an experiment’s lifetime, while an AI workflow may grow faster than the formal review cycle. Average traffic growth is useful for budgeting but cannot replace case-specific planning. The exceptionally low 4% ESnet traffic increase in 2024 does not prove that long-term demand has stopped; it shows why a single year should not drive a decades-long infrastructure programme.

Requirements reviews also distribute responsibility. A laboratory cannot assume that the national backbone will fix an inadequate campus path, and ESnet cannot assume that a science programme will adapt after capacity is built. Placing the dependencies in a shared plan makes later disagreements more concrete. (Requirements review reports)

Wireless Edge and QUANT-NET test the limits of the facility

A national fibre network serves fixed institutions well. Scientific instruments do not always operate in such places. Geothermal fields, environmental observatories, and temporary campaigns may lack carrier coverage, reliable power, or an economically viable fibre route. ESnet’s Wireless Edge programme investigates how private cellular networks, Wi-Fi, directional radio, and satellite systems can extend a scientific workflow to those sites.

A geothermal deployment in Nevada, disclosed in June 2026, combined private 4G using Citizens Broadband Radio Service spectrum, long-range Wi-Fi HaLow, conventional Wi-Fi, Starlink backhaul, directional radio, and a self-powered portable tower. The design responded to the conditions of a single field. It was not a general ESnet wireless product and could not offer the sustained capacity of long-distance fibre. Terrain, weather, spectrum, power, and the satellite provider remained part of the service path.

The more important organisational point is that ESnet did not stop at the nearest fibre point and treat the rest as another institution’s responsibility. Its science engagement role handled acquisition, backhaul, and long-distance transport as a single workflow. This approach can be more valuable than a uniform product, because remote scientific sites face different physical constraints.

QUANT-NET explores another frontier. The ASCR-funded project is building a three-node quantum network testbed linking Berkeley Lab and two University of California, Berkeley sites over about five kilometres. The work includes ion traps, photon coupling, entanglement swapping, Bell-state measurements, time-sensitive control, and a modular software framework.

The relationship with ESnet lies mainly in control and orchestration. Quantum experiments need classical communication, precise timing, and coordination among devices that are still hard to operate. Open-source control software can make experiments more repeatable and reduce manual tuning. The testbed is not a production quantum internet and does not carry large volumes of conventional science data over entanglement.

Wireless Edge and QUANT-NET should therefore be judged by what they teach and what can be reused. Neither demonstrates that every ESnet user will receive wireless access service or a quantum link. They extend the facility’s research function into areas where future science networks may require new physical media and control systems. (Wireless Edge deployment;quantum networking research)

American Science Cloud and ESnet7 shift the planning unit from sites to workflows

The Integrated Research Infrastructure programme and the emerging American Science Cloud reflect a change in how the Department of Energy describes its facilities. Instead of treating an instrument, a network, a data repository, and a supercomputer as separate services, the programmes aim to make them operate as a federated environment for scientific data, AI, and high-performance computing.

ESnet’s role lies in connectivity and orchestration. Data must move from instruments to storage and accelerators; users and services need controlled access; workflows need to discover available resources; and telemetry must show whether the system is achieving the scientific goal. EJFAT, SENSE, OSCARS, Cloud Connect, and High-Touch address parts of this problem, but none alone constitutes the American Science Cloud.

At Confab26, Inder Monga was identified as Project Deputy for the American Science Cloud, and programme sessions included demonstrations and planning for the next network generation. This is evidence of active institutional work, not proof that a universal science cloud was complete as of August 2026. Access policy, connected resource inventory, production support, and governance were still open questions.

ESnet7 appears in the same planning environment. The name is real, and innovation sessions examined telemetry, packet inspection, data movement, AI, and quantum networking. ESnet6, however, remains the current production generation. No final public architecture, design baseline, vendor selection, full budget, or launch date was identified in the available evidence.

This distinction matters because network generations create expectations long before equipment is installed. A planning programme can influence research priorities, vendor engagement, and capital requests. It should not be presented as a completed backbone. The most defensible interpretation is that ESnet uses operational experience from ESnet6 and current workflow projects to decide what a seventh generation should be.

Speed will remain important, but the evidence suggests that programmability and intelligence may become equally central. A faster link does not tell an application where available computing exists, does not identify a microburst, does not schedule a detector stream, and does not prove that a multi-domain service has been correctly torn down. The strategic question for ESnet7 is how much of the scientific workflow the network should understand and coordinate without becoming an unmanageable central controller. (Confab26 programme;2024 applied research)

Federal funding sustains the facility, but the budget line is not revenue

ESnet does not fund its backbone by selling capacity to the public. The Department of Energy funds it primarily through the ASCR activity called High Performance Network Facilities and Testbeds. The FY 2027 request proposed $103 million for this programme line, compared with $97.261 million in the prior enacted column.

The figures are the best public indicator of the programme’s scale, but they are not an ESnet profit-and-loss statement. The line also supports network-related testbeds, software maintenance, upgrades, and research activities. It does not reveal a separate annual operating cost for the production backbone, the capital investment of each network generation, or the revenue associated with individual site connections.

Public funding allows the facility to invest before demand becomes commercial. It can procure long-term spectrum, maintain open-source tools, support low-volume high-value experiments, and build route diversity beyond what immediate utilisation would justify. The same model creates dependence on congressional appropriations, Department priorities, and Berkeley Lab’s operating framework.

Site connections are not always cost-free. The ESnet Site User Cost Policy allows institutional users to bear connection-related expenses, depending on sponsorship, eligibility, and incremental requirements. The unit of the relationship is the site, not the individual researcher. End users are neither charged nor separately registered by ESnet.

The absence of standalone accounts limits financial analysis. Public materials do not disclose full vendor concentration, payroll, depreciation schedules, per-route asset records, or an annual capital budget. Calling the $103 million “ESnet revenue” would be inaccurate. The most precise conclusion is that a federal programme funds a production facility, its upgrades, software maintenance, and testbeds through a broader activity line.

The funding structure also affects strategic choice. A commercial network can abandon a route that does not cover its costs. A public science facility must balance national mission, scientific opportunity, and long-term capacity with budget constraints. This can justify investments with no immediate financial return, but it also makes transparent prioritisation and the evidence from requirements reviews essential. (ASCR FY 2027 budget request;ESCC and site policy)

Reliability, routing security, and telemetry create their own obligations

ESnet’s 2024 report recorded a notable availability result: all ten Office of Science sites included in the metric achieved 100% service availability, excluding scheduled maintenance. It was the first year in which every site simultaneously exceeded the 99.9% requirement. The annual report also gave a wider availability figure of 99.99%. These are useful measures, but with different scopes, and they do not prove that every service, institution, and international path remained uninterrupted.

The Site Resilience Program examines diverse entries, routers, power, and failure domains at connected facilities. This reflects an uncomfortable reality: a national backbone can be redundant while a laboratory still depends on a single duct or piece of local equipment. Reliability needs to reach the building and the data transfer system, not end at the backbone map.

Routing policy offers another layer of control. ESnet rejects RPKI-invalid announcements in peering relationships, requires up-to-date routing registrations, and provides hijack monitoring and destination blackholing. These controls reduce known risks but do not make inter-domain routing infallible. A valid origin can still be associated with a leak or a policy mistake, and blackholing protects other systems by making the affected destination unreachable.

Automation creates a similar trade-off. Standardised configuration, inventory, and orchestration can reduce manual errors and speed recovery. A template, a policy, or a data record error can also propagate quickly across many devices. The appropriate response includes staged deployment, independent validation, clear rollback or progressive recovery procedures, and limits on the authority of any single automation account.

Operational data deserve the same attention. The facility data policy states that router utilisation information and NetFlow may be retained indefinitely and replicated in storage on both US East and West Coasts. Active perfSONAR measurements are kept for six months on a single disk without backup. Router utilisation and traceroute information are public, while flow and security records have restricted access.

This does not contradict the statement that ESnet does not formally track every end user as a subscriber. These are two different systems. ESnet does not maintain an individual registration and billing relationship, but network metadata can identify endpoints, communicating institutions, times, and traffic patterns. High-fidelity telemetry improves diagnosis and security but increases the need for minimisation, access control, review of retention periods, and responsible use.

The soundest resilience model is not a claim of perfect availability. It is a set of mechanisms with defined limits: physical diversity, site engineering, routing security, measurement, incident response, data governance, and a willingness to publish the scope of each metric. (Availability milestone;facility data policy;peering policy)

What ESnet represents

ESnet’s story can be read as a sequence of faster networks: specialised precursor systems, ESnet4, the continental 100G ESnet5, and the multi-terabit ESnet6. The timeline is real, but it does not capture the more important continuity. The facility repeatedly changed the architecture around the scientific work when raw capacity stopped solving the problem.

The Science Data Network separated exceptional flows from ordinary traffic. OSCARS made capacity reservable. Science DMZ altered the institutional perimeter. perfSONAR and iperf3 turned performance disputes into measurements. SENSE connected application intent to multiple administrative domains. EJFAT brought the long-distance path into the detector loop. Caching changed demand, and transatlantic spectrum expanded ESnet’s control over international growth.

The organisation’s authority remains bounded. DOE and ASCR set mission and funding. Berkeley Lab operates the facility. The University of California manages the laboratory under contract. Site coordinators approve changes that affect their institutions. International partners control their own networks. Cloud providers, carriers, cable owners, and equipment vendors retain power over components on which ESnet depends.

This distribution of control is not an inconvenience that software can eliminate. It is the condition under which a science network operates. The practical achievement lies in delivering enough coordination to deliver a workflow without pretending that a single institution owns the entire path.

The same discipline must govern claims about the future. ESnet7 is in planning, SENSE remains in the research phase in the latest full report, EJFAT is an advanced prototype or emerging platform, QUANT-NET is experimental, and the American Science Cloud was still being built. The evidence is more useful when the maturity level is described accurately.

ESnet’s long-term importance lies in the shared scientific facility model. The network is treated as a scientific instrument, with requirements, operations, software, measurement, research, and public funding. This model recognises that a detector and a supercomputer thousands of miles apart generate little joint value if the systems between them are not designed as a single path.

The question, therefore, is not whether ESnet is the fastest network by some universal ranking. No neutral current measure in the available evidence supports that claim. The defensible conclusion is stronger and more useful: ESnet is one of the most capable documented science networks in the world, and its principal contribution is making end-to-end operational distributed science work. (ESnet history;ESnet6 launch;2024 annual report)

Sources