[Qirg] Re: draft-cacciapuoti-qirg-quantum-native-architecture-01 & Napoli architecture in general

[Angela Sara Cacciapuoti <[e-mail]>]

Dear Rod, Dear Wojtek,

Thank you so much for all the time and thought you put into this. We really appreciate it. 

It has helped us clarify several important points and identify a number of places where the draft needs to be more precise and revised.

As you (Rod) mentioned, you and Wojtek are broadly aligned on the main points, so I thought it would be easier to reply to both of you in a single email.

I hope neither of you minds.

This will be a long email too. Sorry about that.

Let me start with the TL;DR and then go through the individual points.

One framing point before the details: the I-D defines architectural principles; [5] explores one particular routing realization; and [6] proposes a protocol-organization model. Classical mechanisms and signaling remain necessary in all three. I will try to keep these levels separate below.

> 
> Da: Rod Van Meter <rdv=[e-mail]>
> 
> Oggetto: [Qirg] draft-cacciapuoti-qirg-quantum-native-architecture-01 & Napoli architecture in general
> 
> Data: 11 agosto 2026 alle ore 11:18:06 CEST
> 
> A: "[e-mail]" <[e-mail]>
> 
> 
> 
> Hi folks,
> 
> 
> 
> All of this is personal opinions, except for the bit on the use of the
> 
> word "forwarding".
> 
> 
> 
> I'm going to jump in here with some comments on this draft as
> 
> well. Sara and Marcello are probably still on vacation and so probably
> 
> can't reply soon, but I'm heading out on about six weeks of travel
> 
> myself (starting with a visit to my mother), and wanted to get this
> 
> out before I go.  Jessica, Caterina, Joaquin and Amar may have
> 
> independent responses to my comments here, of course.  (Minor
> 
> editorial note: this was mostly written with "they" rather than "you",
> 
> as if the authors aren't listening or responding.  My apologies if
> 
> that bothers you, but this is mostly addressed to a) myself and b) the
> 
> original authors.)
> 
> 
> 
> I mostly agree with Wojtek's comments on the I-D; I had written about
> 
> half of this before seeing his comments, and I think we're pretty well
> 
> aligned.  I especially agree with his comments on justification of
> 
> scalability, which I think will show up in my comments here.
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fqirg%2FPpx5rAawj_cUAoVRQ6e0Co6A4MY%2F&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874352260%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MLTreD7FKcZ2M5476xJg77jak0xbTqwbLccclZo4mpc%3D&reserved=0
> 
> 
> 
> I went deeper into the associated research papers because I wanted to
> 
> understand better where the ideas in the draft come from and where the
> 
> overall effort to create a specification might be going.  Of course
> 
> ideas and opinions change over time, so just because they wrote
> 
> something in a paper several years ago doesn't necessarily mean they
> 
> still think it's the best way to go.  (Or even a fresh paper may
> 
> represent an exploration of an alternative instead of a fleshing out
> 
> of a direct part of the architecture.)
> 
> 
> 
> With apologies, this is going to be VERY long (over 5,000 words). It
> 
> has taken me a lot of work, so I hope that in the end it helps push
> 
> forward the conversation on Quantum Network and Internet
> 
> architectures, including helping to identify what's common among some
> 
> of the candidates and what the differences are, based on differences
> 
> in assumptions about technological development as well as goals for
> 
> the system.
> 
> 
> 
> 
> 
> TL;DR:
> 
> 
> 
> * I think the main Napoli architecture is a 4G architecture, well beyond
> 
> where the technology will take us for the foreseeable future. (The
> 
> very latest major paper does have some 1G-like characteristics
> discussed more below.)

Some aspects of the design could indeed have this “4G” flavor and require technologically demanding capabilities. However, I do not think that this characterization applies to the architecture as a whole.
Furthermore, the 1G-3G taxonomy describes repeater technologies and their error-management capabilities rather than complete network architectures. This is also why I think we need to be careful and agree on the terminology.

Also, part of the Dynamic-Kernel execution model (Executor and part of the Engine) has now been implemented on our deployed, multi-vendor quantum internet testbed in Naples. These experimental results are currently under review and are not yet public, so we cannot point you to a public paper at this stage. Once they become publicly available, we will follow up on the mailing list and share them with the members, so that we can eventually move forward the discussion in light of the experimental evidences. 

More generally — and this is perhaps a philosophical difference between us — I do not think that an architecture should be constrained only by what the technology can do today. Rather, it should try to capture the invariants of the problem: in our case, the non-local, consumable, stateful, and dynamically-evolving nature of entanglement, together with no-cloning, decoherence, and the unavoidable role of classical signaling. Those properties will remain even as memories, gates, entanglement rates, and error correction improve.

This does not mean ignoring implementability. Specific mechanisms must be assessed against realistic technological assumptions, and the architecture should admit progressively deployable realizations. But I would distinguish the lifetime of an architectural abstraction from the maturity of one particular implementation.
The Internet itself was — or at least was in part — designed with this ambition: its basic abstractions survived while link capacities, processing power, memory, and access technologies changed by orders of magnitude over the following decades.
I am not claiming here that we necessarily got the architecture right. I am only saying that I would evaluate separately whether the architecture captures the enduring properties of the problem and whether each proposed realization is feasible within a particular technological generation.


> 
> * The many-long-lived-tunnels method is interesting and bears a lot
> 
> more research.  It could be a good choice for working around the
> "edges" of a dense core.

I see the analogy — and we briefly discuss it in the paper you label as [4] — and I agree that this is an interesting direction worth investigating further.

There is one distinction worth making, though. A classical tunnel creates a virtual adjacency, but packets still traverse the underlying multi-hop path whenever data is transmitted. By contrast, once an entanglement-enabled link has been established and remains available, it provides a directly usable — and consumable — connectivity resource between remote nodes. So, although the two may look similar as overlay abstractions, they are operationally different. We return to this distinction later in the email.

> 
> * Overall, I'm skeptical of packet-based quantum network
> 
> architectures, but they bear further research and matching to
> 
> projected technology development.  Lots of smart people disagree
> with me here.

Fair enough, we know this is a fundamental point on which reasonable positions differ. The packet abstraction is a deliberate architectural choice in our draft. From an architectural viewpoint, a classical packet is a structured bit string comprising a header and a payload, independently of how those bits are physically encoded. Likewise, we view a quantum packet as a structured quantum state — possibly describing a composite system — organized into a quantum header and a quantum payload. In our suite [6], the meta-header has an explicitly sequential structure: it contains the service intent followed by an ordered, append-only sequence of stamps. Whether these logical fields are encoded using one or multiple carriers, one or multiple quantum systems, or different degrees of freedom of the same carrier lies below the architectural abstraction boundary. The architecture specifies their logical decomposition and semantics without committing to a particular physical encoding or carrier-level realization. More on this below.

> 
> * Personally, even if you accept the idea of packets for quantum
> 
> networks, I don't think the in-band, all-quantum packet structure
> 
> will be a good choice; I don't see any reason for the headers not to
> 
> be carried over a coordinated classical channel, and carrying them
> in the quantum channel comes with a high cost.

This is probably where we disagree most. I can agree that a coordinated classical header may work in controlled environments. My main concern is whether a separately maintained classical control field can remain consistently aligned with an evolving quantum-resource state in a general, dynamic network. Specifically, my concern has two distinct parts. First, a control field maintained on a separate classical channel requires an explicit mechanism to bind it to the corresponding quantum-resource instance and preserve causal alignment as that resource is transformed, consumed, lost, or replaced. So association and reconciliation semantics have to be provided. Second, a classical field may describe a quantum control state, but it cannot itself carry or be coherently operated on as that quantum state. This distinction matters for abstractions such as Quantum Addressing. More on this below.

> 
> * The dynamic kernel approach I like; I find it similar to our
> 
> approach.  It's event-driven, and actions are compiled to physically
> 
> appropriate actions locally and executed as independently as
> possible.

Thank you! I like it a lot too :) To me, the closest similarity lies in the recursive nature. At the same time, there are important differences in the state and coordination semantics, which we discuss below.

> 
> * The active-packet approach (either stamps or superposed addresses),
> 
> which differs from our RuleSets in that they are carried in the
> 
> quantum packets rather than stored as connection state at the
> 
> routers, seems to me to be solving a non-problem, and the cost of the
> 
> complexity and performance demands introduced are will be the wrong
> tradeoff.

This is closely related to the previous disagreement. I do not see resource-state reconciliation as a non-problem. 
On the contrary, I believe that, beyond controlled environments, continuously reconciling a separate classical control representation with a distributed and evolving quantum-resource state will itself become a barrier to scalability.
More later in the email.

> 
> * At the end of this tome, there is a little bit of a comparison to
> our architecture.

Detailed response below.

> 
> 
> 
> 
> 
> References I worked from to understand the Napoli architecture:
> 
> 
> 
> 1. Angela Sara Cacciapuoti, Marcello Caleffi, Jessica Illiano, C. De
> 
>  Risi, A. Abane, Joaquin Chung
> 
>  Quantum-Native Architectural Tenets and Philosophy for the Quantum 
> 
> Internet
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cacciapuoti-qirg-quantum-native-architecture%2F&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874376637%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ltoirW3Qtb5R7hNOFkEujs1dXLheLLaT99lS64JI7lM%3D&reserved=0
> 
> 2. Marcello's slides covering the -00 version of that draft
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F124%2Fmaterials%2Fslides-124-qirg-design-principles-for-the-quantum-internet-quantum-control-plane-caleffi-00&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874391482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=087Ebs7b%2B2oQ0BlDcitDEAM2faI5BUUiFgmU5cybU%2BM%3D&reserved=0
> 
> 3. Sara's slides covering the -01 version of that draft
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F126%2Fmaterials%2Fslides-126-qirg-draft-cacciapuoti-qirg-quantum-native-architecture-01&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874405869%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lnbjiJANeH2ovvbkg6d4fOTyCOdAqjlUr%2Fo4s%2FxrUjo%3D&reserved=0
> 
> 4. Angela Sara Cacciapuoti, Jessica Illiano, Marcello Caleffi
> 
>  Quantum Internet Addressing
> 
>  IEEE Network
> 
>  https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F2306.05982&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874420234%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bZ5elrq8YO0oC4DQa0MS6BHC%2FmxXQwM2QTBNOS6hrQM%3D&reserved=0
> 
> 5. Marcello Caleffi, Angela Sara Cacciapuoti
> 
>  Quantum Internet Architecture: Unlocking Quantum-Native Routing via
> 
>  Quantum Addressing
> 
>  IEEE Trans. Communications
> 
>  https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F11322738&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874434729%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dhi3q0sNlcVIKn4W2Y80nHK3cTx%2F3kChUoBwAPNP6i8%3D&reserved=0
> 
> 6. Angela Sara Cacciapuoti, Marcello Caleffi
> 
>  A Quantum Internet Protocol Suite Beyond Layering
> 
>  IEEE Transactions on Network Science and Engineering
> 
>  https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1109%2FTNSE.2026.3679795&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874448869%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iFT5yJXo6OlNLNtEp%2FQ%2F18HPmIffwjWTlxzF3SRmWp8%3D&reserved=0
> 
> 7. Jessica Illiano, Marcello Caleffi, Antonio Manzalini, Angela Sara 
> 
> Cacciapuoti
> 
>  Quantum Internet Protocol Stack: a Comprehensive Survey
> 
>  https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F2202.10894&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874463503%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zcDDbecqr%2FEoRFV%2Bz6LSzAbRs24UN5H9F690qjKKpmQ%3D&reserved=0
> 
>  (n.b.: this survey doesn't cover their own architecture, and it's
> 
>  good but now rapidly becoming dated as a lot of work has come out
> 
>  in the last four years.  But if you need to get oriented, it's
> 
>  solid place to start.)
> 
> 
> 
> (I also skimmed a couple of others but didn't keep good notes on them.)
> 
> 
> 
> Let me oversimplify the assumptions, problem and architectural
> decisions down to about six points:

Your simplification is useful, but I think it combines architectural assumptions of the I-D with specific mechanisms explored in [5] and [6]. Let me try to separate them.
> 
> 
> 
> 
> 
> -1. The key assumptions are that
> 
> -1.1 high-fidelity entanglement itself is plentiful; and
> 
> -1.2 execution of quantum programs at quantum nodes
> 
>  (including routers in the quantum network) is cheap, reliable
>  and low latency.

No, I would not characterize these as assumptions of our architecture. The I-D defines architectural principles and abstractions; it does not prescribe specific protocols, algorithms, hardware realizations, or performance thresholds. Indeed, it is explicitly agnostic to both the routing model and the repeater generation. Specific mechanisms explored in the related papers — notably the Grover-based realization in [5] — may require advanced quantum-processing capabilities, but those requirements should not be transferred to the architecture as a whole.
Of course, every operational quantum-network realization has some minimum physical-feasibility conditions: the quantum resources must retain sufficient quality for long enough to complete the required operations. In a memory-based realization, for example, the available memories and coherence times must be adequate for the relevant protocol timescales. If they are not, that realization cannot work — but this is true for any quantum-network architecture. It is not equivalent to assuming that high-fidelity entanglement is plentiful or that quantum computation at every router is cheap, reliable, and low latency. We will revise the wording of the draft wherever it may suggest otherwise.

> 
> 0. The key challenge in designing quantum networks is achieving
>  scalability in managing quantum entanglement.

Yes, agree.

> 
> 
> 
> 0.1. Excessive per-connection state passing through central routers
>  doesn't scale.

Not quite. Our concern is not primarily the amount of per-connection state or the processing capabilities of classical routers. 
It is the association and causal-consistency problem introduced when a classical control representation is maintained separately from a non-local and dynamically evolving quantum-resource state, across both the nodes sharing the resource and the functions acting on it.

> 
> 0.2. Path length has higher impact in quantum networks than in classical
> 
>  networks, so it is crucial to minimize the use of "stretched" paths
> 
>  that are longer than the minimal path between two nodes.
> 

I would not state this as an assumption or requirement of the architecture. The routing mechanism you discuss later belongs to [5], not to the I-D. That paper provides one constructive example showing that a control plane grounded in quantum abstractions — such as quantum addressing — can support a routing mechanism with constant entangling stretch and sublinear routing-table size. Neither this routing mechanism nor stretch minimization is mandated by the I-D.

More generally, [5] is intended as one concrete example of what becomes possible when the control plane can represent and manipulate network information natively as quantum states, rather than being restricted to classical representations. It demonstrates one capability enabled by this design choice. Iit does not prescribe that capability as an architectural requirement. Let me also clarify why we chose compact routing as the case study. We were not trying to argue that routing-table growth or path stretch is necessarily the most pressing problem for a future Quantum Internet — or, for that matter, for today's classical Internet.

Rather, compact routing provides a particularly useful benchmark because it exposes a fundamental and extensively studied trade-off in classical routing: reducing routing state while controlling the resulting path stretch. Starting from such a well-characterized classical problem allows us to ask a sharper question: does changing the nature of the information that the control plane can represent and manipulate change what can be achieved?

This is particularly relevant to [5]. To the best of our knowledge, [5] provides the first compact-routing construction achieving fully name-independent routing without relying on an underlying name-dependent scheme. Hence, node identifiers remain topology-agnostic: compactness is not obtained by embedding topological information into the addresses. Instead, Quantum Addressing enables sets of node identities to be represented and manipulated natively as quantum states, and the routing construction exploits this additional capability.

This was also very much in the spirit of a question that arose repeatedly in the early QIRG discussions, particularly from participants coming from the classical networking community: what can a quantum network actually do that cannot be done by a classical network? Our formulation of this question is whether the “quantumness” can enable network functions or control abstractions that are unavailable when the network is restricted to classical information and operations. [5] was intended to provide one concrete, constructive example in this direction. We deliberately chose a classical networking problem with a long research history so that the distinction could be made explicit and evaluated against a well-established theoretical baseline.

So I think we actually agree that compact routing need not be a pressing operational concern for today's Internet, nor necessarily the dominant routing concern for a future Quantum Internet. That is not the point [5] was intended to establish. Its role is to demonstrate that, once “quantumness” is admitted into the control plane, the resulting design space need not be limited to classical control mechanisms.


> 
> 1. The unit of communication is the quantum packet, which is
> 
>  "forwarded" across entangled tunnels, although the stated goal is to
> 
>  create E2E entanglement for end nodes; I don't quite understand yet
> 
>  how forwarding and entanglement swapping interact in this
>  architecture.

Entanglement swapping is one of the operations included in our generalized forwarding semantics. This is also consistent with the routing/forwarding decomposition adopted in the survey by Amar et al. that you cite later. There, quantum forwarding is explicitly distinguished from classical hop-by-hop packet forwarding: it comprises elementary-entanglement generation and entanglement swapping — and, where needed, purification and robustness mechanisms — to establish end-to-end entanglement. In our terminology, swapping consumes existing entanglement resources to extend or reconfigure entanglement connectivity. A quantum packet may therefore progress through local transformations and, when required, inter-node transfers. In this sense, swapping and forwarding are not alternative mechanisms: swapping is one of the mechanisms through which generalized quantum forwarding can be realized.
Hence, the term generalized forwarding should not be understood as an unchanged object transported across classical-like paths.

> 
> 2a. Routers should maintain large numbers of long-lived virtual
> 
>  tunnels, which are multihop router-to-router connections that they
> 
>  continually restock with Bell pairs.  (n.b.: The authors don't
> 
>  usually use the term "tunnel", but I think it's helpful here, and
>  they usually use the term EPR rather than Bell pair.)

This is close, but I would make two clarifications. The two-tier organization described in the I-D does allow ESPs proactively maintaining entanglement resources among one another. However, what they maintain should not be understood as a set of long-lived classical-like tunnels that are continuously stocked with guaranteed Bell pairs. The maintained object is an entanglement-enabled connectivity relation, not a guarantee that a fixed number of Bell pairs is continuously available between ESPs. The individual entanglement resources realizing that relation are volatile, consumable, may decohere, and are not guaranteed to be continuously available. Thus, “maintenance” here should be understood as maintaining the capability to provide that entanglement-enabled connectivity, rather than continuously restocking a persistent tunnel to some guaranteed level.
There is also a second, architectural point. Section 8.1 makes the broader architectural abstractions compatible with both proactive and reactive entanglement-generation regimes. Proactive maintenance is therefore one realization described in the draft, not a requirement imposed by the architecture on every implementation.


> 2b. E2E connections are routed through these tunnels, minimizing the
>  number of virtual hops and possibly applying other cost metrics.

This describes the specific routing mechanism in [5], not an architectural requirement of the I-D. The draft deliberately does not prescribe a routing algorithm, a cost metric, or the minimization of virtual hops. Even in [5], I would not say that connections are routed through tunnels in the classical sense. Routing operates over an entanglement graph by selecting e-hops and manipulating the associated entanglement resources according to the adopted entangling-cost metrics.

> 
> 3. The normal per-packet processing of headers, including selecting
>  the nexthop, should all be done utilizing quantum computation.

In the specific routing mechanism in [5], yes

> 
> 4. Each quantum packet should carry "stamps", which are state for the
> 
>  processing of the packet itself.  The stamps essentially represent
> 
>  program fragments, processed via a Plan of Action constructed
>  independently at each node along the path from the set of stamps.

Partly. Stamps belong to the mechanism described in [6], not to the architectural principles defined by the I-D. They are appended to the packet’s meta-header, but I would not describe them as program fragments. A stamp is an append-only record certifying the outcome of an action at an action-commit boundary: it records what has already happened; it does not prescribe what should happen next.

At each node, the node-local Dynamic Kernel constructs a speculative local Plan of Actions from the service intent, the accumulated stamps, and the node’s current internal state. The PoA contains the candidate node actions, whereas the stamps provide the minimal authoritative execution history that subsequent nodes will exploit. The PoA itself is never carried in the packet: each node constructs it locally according to its capabilities and currently available resources.

We have now implemented and simulated an executable specialization of this behavior in our open-source Q2NS/ns-3 simulator, over repeater chains with up to 1000 nodes (https://zenodo.org/records/22092701) The results confirm that the meta-header growth is bounded by the number and granularity of the logical actions that actually reach an action-commit boundary during service fulfillment.

More precisely, the required committed-action sequence is determined jointly by the service intent, the adopted policy, the capabilities of the participating nodes, and the resources already available in the network. Once the service semantics, policy, and admissible actions are fixed, an upper bound on the meta-header growth can therefore be derived before execution; the actual size reached at runtime depends on which actions are required under the encountered resource and capability conditions.
Therefore, “bounded” does not mean constant with network size. It means that the meta-header contains only the finite execution history logically required to bring that service instance to success or failure, rather than an ever-growing record of retries, speculative plans, or transient state.

> 
> 
> 
> There's a lot more to it than just this, but I think those capture the
> 
> essential ideas.  I wish I could better articulate this in terms of the
> 
> problems being solved, but I'm not sure I really can yet.
> 
> 
> 
> Let's set aside the <-1> assumptions for the moment, but they underlie
> 
> a lot of the following work, and represent probably the biggest
> 
> divergence from my own thinking.
> 
> 
> 
> The challenges in <0> above are reasonable concerns. Let's look at them:
> 
> 
> 
> <0.1> As it happens, I worry a lot less about the amount of classical state
> 
> needed to support a quantum connection (even in our rather active,
> 
> distributed computation-oriented architecture) than I do about the
> 
> availability of entanglement to be shared among a set of E2E
> 
> connections passing through a node, regardless of whether the
> 
> connection is designed to use classical state at routers or not. That
> 
> is, personally I think <-1.1> won't be a valid technological point for
> 
> a long time yet.
> 
> 
> 
> I did just a little asking around, and while the people I asked didn't
> 
> have published numbers yet, it seems that a router at an IXP can
> 
> expect to see several million IP flows passing through over the course
> 
> of a minute.  That's a lot, but the memory for connection state
> 
> wouldn't be a problem; the challenges would be doing the per-packet
> 
> processing at line rate, and managing buffer space properly if it is
> 
> anything other than FCFS.  With quantum event rates FAR lower (six
> 
> orders of magnitude? more?), the processing isn't the problem, but
> 
> buffer space management is indeed a big deal and an open area of
> 
> research.
> 

I think your argument addresses a different scalability problem from the one we mean in I-D. 

I agree with you that storing classical per-connection state is unlikely to be the main technological bottleneck, particularly when quantum-event rates are so much lower than classical packet rates. I also agree that quantum-memory availability, coherence constraints, and the allocation of scarce entanglement among competing connections are major open problems. We are not assuming those problems away.

But that is not the scalability problem we mean. Our concern is neither the number of bits needed to describe a connection nor the computational capacity of a router to process those bits. 
It is the additional binding and causal-consistency obligation (reconciliation) introduced when a classical control representation is maintained separately from the quantum-resource state to which it refers.

The comparison with the number of IP flows through an IXP does not quite capture this distinction. 
An IP flow does not normally require every router along its path — and potentially additional remote nodes — to maintain synchronized copies of the descriptors of an evolving, non-local resource state. Classical forwarding state is locally readable, copyable, and independently updateable. Entanglement is different: it is shared across nodes, cannot be locally inspected as an ordinary state variable, and can be consumed or reconfigured by operations performed at one of the participating nodes.

Take a simple swapping operation. Before the swap, the relevant resources may be the (A!-!B) and (B!-!C) entanglement relations. After the operation at (B), those resources have been consumed and a new (A!-!C) relation has been created, subject to the measurement outcome, corrections, fidelity, and remaining coherence budget. Any separately maintained classical representation must now reconcile (record and causally associate) that transition across the affected nodes and any controller or protocol function relying on it. Until that reconciliation completes, different entities may reason from different views of resource availability, ownership, or partner identity. With multipartite entanglement and concurrent operations, the number of affected dependencies becomes even larger. 

Lower quantum-event rates certainly reduce the absolute processing load, but they do not remove this reconciliation problem. The relevant quantity is not simply events per second; it is whether the classical representation can be updated and disseminated before it becomes stale relative to resource consumption, decoherence, and subsequent control decisions. In fact, when entanglement is scarce, an inconsistent reservation or a decision based on a resource that has already been consumed is more—not less—costly. So entanglement scarcity and state reconciliation are distinct problems, but they interact.

In particular, I think that a classical representation can be reconciled in a small, controlled environment with bounded concurrency, known participants, and tightly managed timing. My concern is whether the same approach remains viable in a general, dynamic, heterogeneous, and eventually multi-domain network, where local quantum operations continuously alter shared resource relations. I do not see router memory capacity or per-event processing speed as answering that question.

This is also why our proposal does not try to eliminate classical signaling — measurement outcomes, acknowledgments, and synchronization messages are obviously still required. The aim is instead to reduce the scope over which correctness depends on reconciling a separately maintained classical description with evolving quantum-resource states. 

In the Dynamic-Kernel approach, each node plans from its local resource state together with the minimal, authoritative procedural commit history carried by the packet. Distributed operations may still use classical signaling internally, but their partial outcomes remain local; only terminally committed outcomes become visible to subsequent processing.

So I completely agree that quantum-buffer management and entanglement availability deserve substantial research. I would just keep them separate from the issue raised in I-D: even if router memory and processing were effectively free, a separately maintained description of a non-local quantum resource would still introduce a distinct consistency and timeliness requirement.

As said, the issue we are targeting becomes even more apparent when we move beyond bipartite entanglement. Consider, as an architectural stress case, two distributed multipartite states — for example, graph states — each shared among remote nodes, that are manipulated and hence transformed through an operation involving only a subset of their participating nodes.

The operation may involve only a few nodes, but its consequences need not remain confined to those nodes. It can change the structure and identity of a quantum resource shared across tens or, eventually, hundreds of participants—or, recalling Kleinrock's seminal 1975 vision of computer networks at scale, perhaps even thousands.

A separately maintained classical representation would then have to capture considerably more than the equivalent of "a swap succeeded." It would have to identify which distributed resource instances were consumed or transformed, what new resource resulted, which nodes participate in it, and which subsequent operations are causally permitted to act on that resource. At the same time, other operations may be taking place concurrently on different parts of the same distributed state or on resources that overlap with it.

None of this means that maintaining such a classical description is impossible in principle. The architectural question is different: over what scope, with what consistency guarantees, and within what time bounds must that description be reconciled before other nodes or protocol functions can safely make decisions based on the resulting resource? Or, putting the question more simply: as the network scales in the number of nodes, distributed resources, concurrent operations, and administrative domains, is maintaining and reconciling a separate classical description of those evolving non-local quantum resources the abstraction on which we want the scalability of a general-purpose Quantum Internet to depend?

This is why we view the issue as more fundamental than classical memory capacity or per-event processing rate. In a network built primarily around independently managed Bell pairs, the reconciliation problem can look like bookkeeping among a small number of endpoints and intermediate nodes. Multipartite entanglement makes the distributed nature of the problem much more explicit: an operation involving only a subset of the participating nodes can alter the semantics of a quantum resource whose identity and operational relevance extend across the distributed system.

This is precisely the kind of architectural scaling question that the I-D is intended to expose. We are not claiming that classical descriptions cannot be maintained, nor that classical signaling can or should disappear. We are asking whether correctness should continue to depend on maintaining only a separate classical representation that must track, with sufficient timeliness and causal consistency, an increasingly dynamic set of non-local quantum resources as the network scales.


> 
> <0.2> I agree, we should be working to minimize the amount of "work"
> 
> needed for each E2E connection.  That's one of the key metrics we
> 
> looked at back in our path selection paper
> 
> [https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F1206.5655&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874484564%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XWUr8ssyQdrHO3Fbd7%2Fr2Fxzu14dL2I%2FIuThFsppmEg%3D&reserved=0]  But I don't think that the
> 
> "stretching" of paths due to shortcomings in the addressing and
> 
> routing architecture are as big a concern as the Napoli team does.
> 
> 
> 
> One key reference they keep coming back to is
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F0708.2309&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874504653%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IUBnHX3vukgE1cbXsHphE9fa5trIwHg0Hy3yUCFiXlU%3D&reserved=0.  That particular paper is
> 
> interesting, but doesn't seem to me to be very mainstream; it has some
> 
> 2007 opinions about how the Internet was evolving that in the end seem
> 
> not to have happened over the last 20 years.
> 
> 
> 
> One of the authors of that is kc claffy, who is one of the most
> 
> important people in Internet measurement and (interesting side note to
> 
> me, at least!)  got her start during an extended visit to Japan and
> 
> whose first paper was with T. Asaba, Jun Murai and Osamu Nakamura.
> 
> 
> 
> Anyway, the Krioukov paper is on "compact routing", which is not a
> 
> term you will hear from Internet people much. What it appears to mean
> 
> is worrying about routing table growth and address aggregation for
> 
> routing purposes.  The canonical place to learn about that these days
> 
> is probably Geoff Huston's annual blog entries for APNIC, most
> 
> recently https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.apnic.net%2F2026%2F01%2F08%2Fbgp-in-2025%2F&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874520568%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yRG%2BEFc3fLjPohRGFZRj2F3Effv9BYrGJnGnUlVLiw0%3D&reserved=0
> 
> The IPv4 table is now a little over a million entries, which is a lot
> 
> but not the disaster it was feared to be twenty years ago.
> 
> 
> 
> The "compact routing" folks fear that keeping the routing table size
> 
> manageable means selecting suboptimal routes that result in
> 
> "stretching" a path.  AFAICT, this is in truth a non-issue in today's
> 
> Internet, but the Napoli team worries about it in their quantum
> 
> network design.
> 
> 
> 
> So, I think it's reasonable to expect that quantum networks can select
> 
> a "best" path for the foreseeable future.  The survey by Amar &
> 
> friends is great https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F10882978&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874536843%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IHmjx5HmZVEkENbPOrJvqPTUd1UL5AST2LI3dISWVJA%3D&reserved=0.  I
> 
> think the big question right now is not the abstract, graph-theoretic
> 
> problem of path selection, but instead how to integrate path selection
> 
> and resource management/access multiplexing.  We did some preliminary
> 
> work on that long ago
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faqua.sfc.wide.ad.jp%2Fpublications%2FAparicio-master-thesis.pdf&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874856572%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rV9kYpxzNxpju45NFqQQCOPicZdIsPoH5QmlbNjEbJY%3D&reserved=0
> 
> and some in the restricted environment of a data center network/LAN
> 
> just recently in https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F2605.07295&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874874482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gRKrbJI6gncOLY%2Fq2Y2dPR%2BgASBqwILGTN5lh6b6djY%3D&reserved=0 (which will be
> 
> presented next month at IEEE QCE).  There are some other people out
> 
> there working on this, as well, and I'm falling behind on the
> 
> literature here; both the Napoli team and a couple of other things
> 
> I've read recently have references I hadn't seen before, such as
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F10575563%2F&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874890130%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vEktV4tDhYubpQA0lkj04xVwVIK4GjHLmfixe03eic8%3D&reserved=0.
> 
> 
> 

I think this is another point where our motivations may have become crossed. Path stretch is not what motivates the I-D.

In [5], we use compact routing as a concrete case study: once the control plane is grounded not only in classical abstractions but also in quantum ones, such as Quantum Addressing, we can construct a routing protocol with sublinear quantum routing-table size and entangling stretch bounded by a constant. To be clear, we are not claiming that classical abstractions are unnecessary. Our claim is that they need to be augmented with quantum abstractions.
These routing properties are results of the specific mechanism developed in [5], not architectural requirements of the I-D. The mechanism is therefore discussed in [5], while the I-D deliberately stops at architectural principles and does not prescribe a routing protocol.

But the more fundamental point is neither table size nor routing itself. The confusion may come from our own wording in the I-D, which still presents Quantum Addressing mainly through routing and forwarding examples. We should make its broader role clearer in the next revision.

The departure we propose is semantic. A conventional control plane — which is concerned with routing, configuration, management, policy enforcement, and resource coordination — performs these functions through classical representations. Our Quantum Control Plane retains those classical mechanisms while augmenting them with quantum-native abstractions that can be encoded and operated on as quantum states. Classical abstractions and classical signaling remain necessary: they are complemented, not replaced.
Quantum Addressing is one such abstraction, but it is neither restricted to routing nor intended to represent the entire quantum control structure. It can represent and support operations on sets (via superposition) of candidate nodes, paths, or domains and can therefore contribute to resource selection, distributed coordination, and service fulfillment — not only to next-hop computation. We still need both the physical-network view and the dynamically evolving entanglement view.

Recent work on quantum-enabled clock synchronization and networked quantum metrology provides a useful precedent. Quantum states and nonclassical correlations — and, depending on the protocol, entanglement — are used as operational resources for a network-relevant coordination function. Some experimental protocols combine photon correlations with classical communication and post-processing, which is actually close to the point we are making: quantum resources augment rather than eliminate classical mechanisms. The narrower analogy is that quantum resources need not merely be represented and managed by a control mechanism; they can participate in performing the coordination function.

[6] provides an example at a different architectural level. It is a protocol suite organized around dynamic composition that allows the network to complete a requested service through distributed, node-local execution. Its meta-header contains the service intent — including the participating nodes expressed through Quantum Addresses — and the accumulated action-commit stamps. Each Dynamic Kernel uses this information, together with its local state, to construct and execute a local Plan of Action. As these local actions commit, the service progresses toward completion.

Quantum Addressing is therefore one component of the meta-header, not the whole control structure. The stamps serve a different purpose: they provide the authoritative procedural execution history that allows subsequent nodes to determine what remains to be done. Also, this packet-carried procedural control should not be confused with external QCP/EDC orchestration, which may provide optional policies or hints but is not required for the correctness of service completion in [6]. The structural gain here is that no continuously refreshed global execution plan is required: only committed outcomes cross node boundaries through the packet-carried history.

A separately maintained classical control field (classical header) could certainly be considered, but it would still need an explicit association and reconciliation mechanism to remain aligned with the evolving quantum resource to which it refers. This implies that the alignment problem still has to be solved.

Seen in this way, [5] and [6] illustrate quantum-native abstractions at two different levels. [5] uses Quantum Addressing within a control-plane routing mechanism operating over the entanglement graph. [6] embeds Quantum Addressing within a richer in-band control structure used by a dynamically composed protocol suite to complete a requested service.

So yes, I agree that integrating path selection with resource management and access multiplexing is an important problem, and your earlier metric could be instantiated within the more general entangling-cost formulation used in [5]. It is simply not the motivation for the draft. Our architectural thesis is broader: limiting control semantics to classical representations introduces an additional association and reconciliation requirement and prevents quantum states and operations from being used natively as control abstractions. 

Saying with different words, separating procedural control from an evolving quantum resource introduces an additional association and causal-consistency requirement that could become a scalability bottleneck. And, restricting the control plane to classical representations prevents it from natively preserving and coherently operating on genuinely quantum control variables. This semantic capability motivates augmenting — not replacing — classical control with quantum-native abstractions. [5] and [6] provide two concrete examples of the resulting design space.

> 
> ** Quantum Packets **
> 
> 
> 
> <1> Quantum packets: here's where I get stuck most on understanding
> 
> the architecture.  With apologies to the authors, even after reading
> 
> the above, I'm not quite sure what constitutes a packet and how it
> 
> moves through the network.  Maybe my brain is working from too
> 
> different a point of view.  But the most up-to-date reference [6] is
> 
> also, happily, the most concrete on processing.  It provides some
> 
> information on how the metadata in the packet is created and updated,
> 
> how a packet is processed and how it moves through the network.
> 
> 
> 
> I am unclear on whether a packet is believed to be reliably delivered.
> 
> Some of the papers pay a lot of tribute to early datagram work from
> 
> the 1970s, so I think maybe the packets are assumed to be unreliable.
> 
> Moreover, somewhere they mentioned that since we are building E2E
> 
> entanglement, it's okay to drop some things because they aren't
> 
> carrying valuable data.  However, given how much work goes into each
> 
> packet, this might be a poor choice.
> 
> 
> 
> The figure from Sec. 5 of [1]:
> 
> 
> 
> 
> 
> +---------------------------------+----------------------------------+
> 
> |       Quantum Header            |     Quantum Payload     |
> 
> +---------------------------------+----------------------------------+
> 
> |   - Quantum Address |A>         |  - Entangled qubits |e_i>        |
> 
> |   - Optional metadata           |   (bipartite or multipartite)    |
> 
> +---------------------------------+----------------------------------+
> 
> 
> 
> (Here's hoping the ASCII art figure survives modern mail writers &
> 
> readers.)
> 
> 
> 
> This is simplified and a little different from Fig. 3 in [5], which
> 
> includes:
> 
> 
> 
> header:
> 
> - src addr: x_i
> 
> - dst addr: x_j
> 
> - an array of address structures, |A> = |A_j^1>,|A_j^2>,|A_j^3>...
> 
> **each of which is a weighted superposition of node addresses**
> 
> payload:
> 
> - an array of qubits: |e_1>,|e_2>,|e_3>...
> 
> 
> 
> Note that x_i and x_j are *classical*, single-valued addresses; any
> 
> given packet has exactly one source and one destination address.
> 
> However, these addresses are encoded in qubits, such that the entire
> 
> packet can all be viewed as a single block of qubits.
> 
> 
> 
> However, the next set of header fields (which I think is what is
> 
> called "metadata headers" or "meta-headers" in some of the papers and
> 
> in the figure above?) *is* in a weighted superposition.  This is very
> 
> likely the source of the confusion over whether or not the Napoli
> 
> architecture is proposing that destination addresses be in
> 
> superposition in a way that "splits" quantum amplitude over a set of
> 
> destinations, as at least some of the Innsbruck papers propose
> 
> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nature.com%2Farticles%2Fs41534-021-00472-5&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874909588%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p0KZF%2B2h1EbccO51AFYA9Q2Vlv8ui68tr1luZ449HAc%3D&reserved=0)
> 
> 
> 
> [Edit: I now think Fig. 3 of [5] is incorrect.  See more on this
> 
> below, but I'm keeping the description here just in case I'm wrong
> 
> about it being wrong, and to help others understand where I went wrong
> 
> if I'm right about it being wrong. (Confused yet?  So am I.)]
> 
> 
> 
> I'm a little unclear on whether |A> in the I-D figure above [1] is
> 
> supposed to be the same as |A> in [5].  I think not.
> 
> 
> 
> Focusing on the |A> from [5], it appears to be a *complete routing
> 
> table for the network*, carried *in the packet itself*.  This is a
> 
> striking design choice, with implications that echo through all of the
> 
> architecture.  I'm also not entirely certain I've understood it right.
> 
> 
> 
> Note that |A> is *not* a source route header, a la RFCs 5095
> 
> (deprecating part of RFC 2640), 6275, or 6554, or like SRv6 (described
> 
> in a whole plethora of RFCs including 8754).  I actually don't see why
> 
> this couldn't be a source route, which would simplify all of the
> 
> processing and allow this meta-header to be carried in the classical
> 
> channel.  If you don't like stateful connections and are worried about
> 
> path selection overhead, this can help, but it doesn't solve the
> 
> scalability problem of having most of the network nodes know a LOT
> 
> about the network topology; in fact in might make it worse.
> 
> 
> 
> But sticking with the proposed structure, here's what I understand
> 
> (which might be wrong).  (This idea is also tied up with the
> 
> many-tunnels notion, which we'll defer for a bit, so part of this is
> 
> oversimplified.)
> 
> 
> 
> Sec. II-D of [5] says, "[F]orwarding decisions...[are]...enabled by a
> 
> quantum header in the packet, as illustrated in Fig. 3, which carries
> 
> the quantum equivalent of source-destination addresses. This approach
> 
> generalizes 'next-hop' selection in the quantum realm by applying
> 
> appropriate quantum operations to quantum addresses in routing tables,
> 
> thereby eliminating classical header parsing."  Then the caption to
> 
> Fig. 3 says, "Quantum packet structure. The header carries quantum
> 
> information for the quantum routing logic, such as source-destination
> 
> quantum network address |x_i>, |x_j>, and quantum superpositions
> 
> |A_j>, representing set of quantum nodes introduced in Sec. IV-B,
> 
> while the payload carries entangled qubits (ebits) to be shared among
> 
> network nodes."
> 
> 
> 
> I now think that that description surrounding the packet structure in
> 
> Fig. 3 is wrong, that |A_j> is *held at the router nodes*, not
> 
> included in the packet.  Also note that the packet figure in the I-D
> 
> (the ASCII figure reproduced above) is simpler and does not appear to
> 
> include the routing information.
> 
> 
> 
> Assuming those qubits labeled ebits are locally buffered at the router
> 
> (as discussed next), I'm now back to not understanding what a "packet"
> is in this architecture.


Rod, no apologies needed: these are very useful comments. I think, however, that three different levels are being mixed here: the architectural packet abstraction in the I-D, the specific routing packet used in [5], and the packet realization used by the protocol suite in [6].

The packet structure in the I-D is deliberately more general than the one in [5]. The I-D defines only the architectural boundary: a quantum packet has a quantum header carrying addressing and other control information, and a quantum payload carrying the quantum resources on which the network operates. It does not prescribe the fields required by a particular routing mechanism, protocol suite, or service. The structure can therefore be specialized according to the network function being implemented.

[5] provides one such specialization for its quantum-routing mechanism. There, ∣xi⟩ and ∣xj⟩ are quantum addresses represented by computational-basis states.They are perfectly distinguishable quantum states that encode one source and one destination in that particular realization.

The ∣Ajl⟩ fields have a different role. Each of them represents one partition of the e-neighborhood of a particular ESP vj. They are announced by vj as routing-control information and therefore belong in the quantum header rather than in the payload. Once received, this information can be retained in the corresponding local routing-table entry. Thus, being carried in a packet when announced and being stored at a router for subsequent queries are not mutually exclusive.

They are also not a complete routing table carried inside every packet, and they do not encode the complete entanglement graph. They describe scoped e-neighborhood information associated with a particular e-hop. The complete local routing table contains multiple entries and remains at the ESP.
So I do not think Fig. 3 of [5] is wrong in the sense you suggested.

Also, ∣A⟩ in the I-D should not be identified one-to-one with the complete field structure used in [5]. In the I-D, it denotes the more general Quantum Addressing abstraction. In [5], that abstraction is specialized into source and destination address fields and superposed e-neighborhood fields for a particular (compact) routing mechanism. In [6], it is embedded in an even broader meta-header: Quantum Addresses identify the participants in the service intent, while the meta-header also carries the other intent parameters and the accumulated action-commit stamps.

The superposed e-neighborhood fields in [5] should also not be interpreted as splitting the packet payload across several destinations, as in the Innsbruck proposal. In [5], the superposition is used as a control structure: the routing logic queries whether the target address belongs to one of the represented e-neighborhoods and selects the corresponding e-hop. The payload does not enter a superposition of destinations merely because a header field contains a superposition of node identifiers.
For the same reason, ∣Ajl⟩ is not a source route. A source route carries an ordered sequence of nodes through which a packet should pass. A classical source route could certainly be studied as another routing mechanism—the I-D does not exclude it—but it would not be a different encoding of the same mechanism in [5]. It would replace local quantum-address processing with a precomputed path that would still have to remain valid with respect to the evolving entanglement graph.

As to what it means for a quantum packet to “move,” Generalized Quantum Forwarding should be understood as a forwarding abstraction, rather than as a single primitive operation or merely the physical transmission of a carrier from one node to another. It captures the overall semantics by which a packet is processed and advanced: the relevant header or meta-header information is processed to determine the applicable actions; the payload and its associated entanglement resources may be transformed, consumed, or left unchanged; and, when required, the resulting packet is transferred to the selected next node. A quantum packet therefore progresses logically through a combination of local transformations and inter-node transfers. This does not imply that the same immutable block of qubits—or even the same physical carriers—traverses every physical link.

The protocol suite in [6] makes the above distinction concrete. Processing at a node may update the meta-header through action-commit stamps and manipulate the payload as service fulfillment progresses. ACT_FORWARD(nh) is the specific action that transfers the resulting packet—and the authority over its meta-header—to the selected next node. The actual sending of the packet is therefore one action within generalized forwarding, not its complete definition. This is consistent with [5], where packets carrying locally held members of EPR pairs are propagated through sequences of quantum operations rather than merely through transmission over physical links.

On reliability, the I-D does not prescribe either a reliable-delivery or a best-effort packet service. That is a protocol-level property. In [6], retries and backoffs can occur within the selected protocols, and an action reaches a terminal outcome as either success or explicit failure. ACT_DROP is also a possible terminal action. The relevant reliability question is therefore whether the requested quantum service is completed under its specified requirements, rather than whether every individual packet is guaranteed to reach a destination unchanged.

> 
> 
> 
> 
> 
> ** Routing and Next Hop Selection **
> 
> 
> 
> So, proceeding from this point forward as if the routing info is held
> 
> at the router...
> 
> 
> 
> A router has a "quantum routing table", illustrated in Fig. 5 of
> 
> [5].  (They use "entanglement service provider", or "ESP", but as far
> 
> as I can tell an ESP is just a router, so I'll stick with the term
> 
> router here.)  This is Sec. IV-B, mentioned above as being where |A_j>
> 
> is defined.
> 
> 
> 
> They define a routing table entry (Fig. 5) as (I'm reordering fields
> 
> in a way that makes sense to me, not their order):
> 
> 
> 
> * the nexthop address (|v_j> in the figure; I am going to write it
> 
> without the ket as v_j since it's effectively classical info)
> 
> * the matching condition, which is not simply a longest prefix, as
> 
> in a UNIX-like or Internet-like FIB; it's a *SUPERPOSITION* of the
> 
> addresses of the *NEIGHBORS* of v_j.  (recall v_j is our
> 
> neighbor, so this is the neighbors of that neighbor)
> 
> * some "ebits": I believe these are the *actual* qubits that are
> 
> entangled with the neighbor v_j!  The result of the routing lookup
> 
> is not just "you should send to v_j", it's "here's a qubit entangled
> 
> with v_j for you to use."  (Or, presumably, "here are enough qubits
> 
> to send the entire packet to v_j.")  Thus, this isn't really a
> 
> _routing_ table, it's a combined FIB and buffer management table!
> 
> This is an important distinction.
> 
> 
> 
> I put "routing table" in quotes because it's not a RIB (routing
> 
> information base), and in fact I don't think it's exactly a FIB
> 
> (forwarding information base) either.  What I *think* it actually is,
> 
> is a combined FIB and buffer management subsystem.  This is also a bit
> 
> of a departure from other proposed architectures.
> 
> 
> 
> For every virtual neighbor a router has, there is an independent
> 
> routing table entry.  It's a little bit like an inverted FIB in a UNIX
> 
> system, where the lookup key is the dst addr, and the result is an
> 
> interface index or a neighbor's address, except that we have to scan
> 
> the entire table and query the node address superposition in order to
> 
> figure out if this particular neighbor is the right match.
> 
> 
> 
> The addresses being matched are *not* labeled |A_j> in Fig. 5, but in
> 
> Fig. 7 and Eqs. 36 & 37 they are.  So I guess we're on solid ground
> 
> here saying that the we're *NOT* doing source routing with the routing
> 
> table carried in the packet itself.
> 
> 
> 
> The next hop is selected from this table using Grover's quantum search
> 
> algorithm https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGrover%2527s_algorithm&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874928871%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qKh8MkLrfaDx4ChlVShuum2n1swQ0wxsfu7DowPlny8%3D&reserved=0. Sec. IV
> 
> of [5] covers this in detail.  I don't believe this is an effective
> 
> design choice, but I also don't think it's actually crucial to the
> 
> architecture so this isn't a showstopper criticism.  (It is, however,
> 
> one of the key points related to their claim that classical control
> 
> doesn't scale, which, as Wojtek pointed out, is claimed frequently but
> 
> not supported by any data or quantitative analysis I have seen in any
> 
> of the papers I have read.)
> 
> 
> 
> The proposed implementation of Grover will require hundreds of
> 
> long-lived, high-fidelity qubits and thousands or tens of thousands of
> 
> high-fidelity gates.  This essentially implies that each quantum
> 
> router is a full-fledged quantum computer, with a lot of memory and
> 
> quantum error correction.  This is one of the primary reasons I say
> 
> this is a 4G architecture.  It assumes an even stronger
> 
> repeater/router node than the 3G architecture.
> 
> 
> 
> I spent a long time studying the circuit they propose, but in the end
> 
> the key point for our purposes is that it selects a virtual neighbor
> and a buffered qubit or qubits that are entangled with that neighbor.

I think we are mostly aligned here, now that the packet-structure issue discussed above has been cleared up. A few qualifications, though.

First, an ESP is not quite “just a router.” In [5], it is a tier-2 Quantum Data Plane entity implementing Generalized Quantum Forwarding. This includes next-e-hop selection, but also the generation, purification, swapping, transformation, and consumption of entanglement resources. Routing and next-e-hop selection are therefore only part of its role.

Your reading of the table is otherwise broadly correct. Each entry couples the e-hop address and its matching information with the actual locally stored halves of EPR pairs shared with that e-hop. This coupling is deliberate: unlike a classical forwarding decision, a quantum-forwarding decision cannot be executed independently of the consumable quantum resource required to realize it. I agree, however, that simply calling this a “routing table” may invite an overly classical RIB/FIB interpretation, and we should make the terminology clearer.

The FIB analogy is useful, but I would stop short of calling the table a complete buffer-management subsystem. [5] does not specify generic buffer-management functions such as scheduling, admission control, or replacement policies. I would describe it more precisely as an entanglement-aware forwarding table. The associated entanglement resources are also not necessarily “enough qubits to send the entire packet” to vj. They are pre-established entanglement resources that generalized-forwarding operations, such as swapping or purification, can manipulate or consume to extend the requested entanglement connectivity. More precisely, the lookup identifies a matching table entry and hence the corresponding e-hop. That entry stores a certain number of locally held halves of EPR pairs shared with the e-hop, which constitute locally available entanglement resources for the subsequent generalized-forwarding operations. The lookup therefore identifies the entry and it does not itself “return” the stored entangled qubit. Nor does [5] assume that their number is determined by the size of the quantum packet: the number of entanglement resources maintained per entry is explicitly left as a design parameter.

One further clarification: the mechanism does not sequentially scan the entire table. The entry labels are prepared in superposition, and the Schrödinger oracle queries the associated superposed e-neighborhood information coherently and non-destructively. If the target address is absent from a given e-neighborhood field, the oracle acts trivially on that field: it is neither measured nor modified, and its superposition remains available for subsequent queries. If the target is present, the oracle coherently couples the corresponding entry label to the hitting component of the address field and induces the conditional phase inversion used to mark that entry; the address field is still not measured. If no address field contains the target, no stored superposed address is measured, collapsed, or otherwise altered. Whether this is the right technological tradeoff is, of course, a separate and fair question.

On ∣Ajl⟩, why this is not source routing, why the table is held locally rather than carried in every packet, I think we have already covered the relevant distinctions above.

The same applies to the architectural status of Grover-based lookup: as discussed above, it is one specific mechanism explored in [5], not a requirement of the I-D. Likewise, our concern about the scalability of purely classical control is not derived from Grover’s speedup or from routing-table size; it concerns the reconciliation of a separately maintained classical representation with an evolving non-local quantum-resource state.

Finally, I would distinguish the resource requirements you mention from the results reported in [5]. Figure 7 illustrates a straightforward, explicitly unoptimized circuit for a small address size; it is not intended as a fault-tolerant resource estimate.
The figures you mention — hundreds of long-lived qubits and thousands or tens of thousands of gates — do not appear to be results reported in [5], so I assume they derive from a separate resource model or implementation analysis you conducted (I’m genuinely interested in it). I agree that such estimates may well indicate that this particular realization is technologically demanding, but they necessarily depend on assumptions such as the oracle decomposition, native gate set, error model, and error-correction overhead.
In any case, these costs pertain to that particular realization in [5], not to the architectural assumptions of the I-D.


> 
> 
> 
> Addressing point <2a> & <2b>:
> 
> 
> 
> The "virtual neighbors" are what I am calling tunnel endpoints. As
> 
> best I can tell, the set of neighbors for each node is intended to be
> 
> long-lived.  Although other researchers have proposed dynamic
> 
> entanglement swapping with set of perpetually-changing neighbors that
> 
> must be tracked (which I think is impractical), I think in the Napoli
> 
> architecture tunnels are perpetually "recharged" with entanglement so
> 
> that there are always Bell pairs available.
> 
> 
> 
> What I have called tunnels, they call virtual neighbors with
> 
> "activated entanglement-proximity", and the topology on top of that
> 
> they call the "artificial topology".  In [5] II-D, they refer to
> 
> "artificial topology maintenance" which requires them to "continuously
> 
> regenerate virtual links" as they are depleted by forwarding.
> 
> 
> 
> Under the assumption that entanglement is readily made, this seems
> 
> like a potentially good choice.  It can be used to simplify routing
> 
> around/across a dense network core.  It's trying to solve the problem
> 
> of potentially needing to understand the entire Internet topology,
> 
> which is a crucial issue.
> 
Thanks!
> 
> 
> 
> As I understand it, if the network consists of n_e routers, each
> 
> router has O(sqrt{n_e}) neighbors.  Although they use O(.) notation, I
> 
> believe the intended constant factor is 1, so if you have 100 routers,
> 
> each has ten neighbors; if you have 100,000,000 routers, each has
> 
> 10,000 neighbors.  10K tunnels/neighbors sounds like a lot, but in
> 
> classical terms it's really not; when I was at Network Alchemy around
> 
> the year 2000, we built a VPN gateway that used a single Pentium CPU
> 
> and was designed to handle 30,000 IPsec tunnels.  Sufficient
> 
> production of entanglement, availability of buffer memory, and
> 
> multiplexing across the tunnels instead are the challenges, which
> 
> aren't really addressed by the Grover routing table lookup.
> 
> 
> 
> The key idea behind this particular number is to make every
> 
> router-router pair be one or two virtual hops away as often as
> 
> possible, and effectively never more than three.  This is especially
> 
> crucial for the Grover lookup, which they have designed to search
> 
> across the set of neighbors-of-neighbors.  If each router has
> 
> 0(sqrt{n_e}) neighbors, then the set of neighbors-of-neighbors is
> 
> O(sqrt{n_e}^2) = O(n_e).
> 
> 
> 
> However, intelligent selection of the set of neighbors is tricky. If
> 
> they are selected so that each added tunnel adds a new node to the
> 
> topology, of course it will be cycle-free, and you will end up with a
> 
> tree that is exactly n_e - 1 links.
> 
> 
> 
> If instead they are selected at random (with replacement), then the
> 
> topology graph will contain triangles and larger cycles.  A little
> 
> calculation shows that as n_e --> infinity, P(distance > 2) --> 1/e =
> 
> ~36%.  That would be a problematically large probability in their
> 
> scheme.
> 

Thanks! This is very useful, because I think the probability calculation assumes a different construction from the one in [5].

First, we do not set the number of e-neighbors to sqrt{n_e} with a constant factor of one. In the construction, k=(1+m)sqrt{n_e} log⁡(n_e), which we abbreviate as O(sqrt{n_e}). Therefore, the examples of 10 neighbors for 100 nodes and 10,000 for 100 million nodes do not follow from the parameterization used in the paper. This is also an asymptotic sufficient construction, rather than a claim about the operationally optimal number of neighbors.

More importantly, e-neighbors are not selected uniformly at random with replacement. For an ESP vi, N(vi) is the set of the k ESPs closest to vi according to the selected entangling-cost metric w. We deliberately leave the specific metric open: it may capture fidelity, entanglement-generation cost, delay, or another performance criterion, while requiring it to satisfy the metric and isotonicity properties stated in the paper. Overlapping neighborhoods are therefore allowed; the construction does not assume that every new virtual link reaches a previously uncovered node, nor that the neighbors-of-neighbors are disjoint.

The randomized component is instead the baseline covering construction. Using known covering results, the partial-anchor construction guarantees Property 1 with high probability: every e-neighborhood contains at least one anchor. The full-anchor construction guarantees Property 2 with high probability: for any destination, an ESP has an e-neighbor tracking that destination. These properties give paths of at most three and two entanglement hops, respectively, with high probability. For additive metrics, the corresponding entangling-stretch bounds are five and three. So your calculation about asymptotic probability is not the model analyzed in [5].

I do agree with your broader resource point: entanglement generation, quantum-memory availability, and multiplexing among concurrent demands are major challenges, and the Grover lookup does not solve them. That was not its intended role. The narrower question addressed in [5] is whether, once the entanglement overlay is constructed according to the stated model, quantum-native addressing can provide sublinear routing state and bounded entangling stretch.

> 
> [5] III invests a lot of effort in discussing path cost and proving
> 
> various constraints on a couple of variants in selection, but TBH I
> 
> get lost in how the path cost is used to select neighbors.  Every node
> 
> creates a tunnel/virtual link with every node with an entanglement
> 
> cost (deliberately left undefined here, but could be e.g. time to make
> 
> a Bell pair) below a certain threshold, plus some set of other nodes
> 
> in the network that I think are randomly chosen.  To me, this scheme
> 
> seems to require a LOT of classical knowledge about the complete
> 
> network topology, including the ability to efficiently determine the
> 
> set of nodes below that threshold and the ability to select other
> 
> nodes in the network at random.
> 
> 
> 
> Moreover, this results in network-wide total work to create and
> 
> maintain sqrt{n_e} tunnels * n_e nodes = n_e^{3/2} total virtual
> 
> links.  If n_e = 10^8, then this is 10^12 total tunnels in the
> 
> network, the vast majority of which will never be used.
> 
> 
> 
> Instead, it seems crucial to *design* the physical and virtual
> 
> topology to match physical constraints, traffic demands and
> 
> organizational needs.
> 
> 
> 
> Which is, in fact, what the Internet's three-tier scheme of LAN
> 
> (spanning tree), IGP (OSPF, ISIS, or iBGP), and EGP (eBGP) does. It's
> 
> known to be imperfect, but as an existence proof for a network
> 
> consisting of a lot of routers acting autonomously, it's hard to beat.
> 
> 
> 
> Our QRNA (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nii.ac.jp%2Fpi%2Fn8%2F8_65.pdf&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874947901%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cwcrVcxQx6kM8HvRkry8ZWe3BokvJrww%2FxFwGqSP2MM%3D&reserved=0,
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1145%2F3610251.3610556&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874973353%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nRRKsXGNqkqT9ZX6VEeV8aMZNbsBJ8z5crnsyudKnmA%3D&reserved=0,
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F2112.07092&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874991624%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=H3TTil%2BvySBpEzbtxWMzrram5kuomz8GikNDYv2IMJ8%3D&reserved=0) attempts to provide similar
> 
> recursive isolation of topology by creating connection-based tunnels
> 
> across individual networks (ASes or equivalent).
> 
> 
> 
> And with all of this I'm once again lost as to the expected semantics
> 
> of a "packet".  Sometimes it feels like a locally-held data structure
> 
> that is guiding the development of E2E Bell pairs, sometimes it feels
> 
> like a datagram that does get transferred (teleported, most likely)
> 
> hop to hop along the path.  In either case, I'm unclear on how the
> 
> "packet" gets from the end node to the router (where our discussion
> 
> has been centered), how many qubits of payload it contains, and lots
> 
> of details about the supporting classical signalling (which still
> seems to be necessary).

I think the first part is already largely covered by the clarification above, but let me make the construction in [5] explicit. An e-neighborhood is not formed by taking all nodes below a cost threshold and then adding randomly selected nodes. For each ESP v_i, N(v_i) contains the  k ESPs closest to v_i according to the selected entangling-cost metric w. As you noted, the specific metric is deliberately left open, so that it can reflect generation time, fidelity, physical constraints, or other specific criteria.

The randomized component concerns instead the covering strategy, not the selection of low-cost e-neighbors. In the partial-anchor scheme, the anchor set is constructed using the randomized distributed covering algorithm of Awerbuch, Bar-Noy, Linial, and Peleg, “Compact Distributed Data Structures for Adaptive Routing,” STOC 1989. As discussed in Remark 7, this construction requires no a priori knowledge of the complete topology and guarantees Property 1 with high probability. In the full-anchor scheme, the tier-2 nodes are partitioned into tracked sets and each ESP randomly selects one of those sets, yielding Property 2 with high probability. As we state in [5], these are deliberately unoptimized baseline constructions. Our purpose was to isolate what quantum addressing can enable and to derive worst-case guarantees without assuming a topology-tailored construction. A clustering or covering strategy optimized for the physical topology, traffic, or administrative structure could provide better practical performance

There is, however, a fair implementation question here. [5] does not prescribe the discovery protocol through which an ESP identifies its k lowest-cost candidates. A naive centralized implementation could certainly use extensive topology knowledge, but complete topology knowledge is not a requirement of the construction: the paper explicitly allows neighborhoods to be formed independently and potentially from partial network views. So I would formulate the open question as how to implement scalable e-neighbor discovery — especially across administrative domains — rather than as an intrinsic requirement for every node to know the complete topology.

On the aggregate size, your qualitative concern about the cost to create and maintain the entanglement graph is fair, and we didn't address this cost in [5]. This brings us back to the distinction we have been making throughout the discussion. Your concern concerns the resource cost of one concrete realization, whereas our analysis asked what becomes possible when quantum-native abstractions are extended to the control plane. [5] proves sublinear routing-table size per ESP and bounded entangling stretch. Conversely, saying that the vast majority of the links would never be used would require a traffic model that is not part of the analysis. Did you have a particular traffic model or workload distribution in mind for that conclusion?
Saying differently, the aggregate scaling you point out is a legitimate consideration when assessing this baseline construction as a practical realization. It does not invalidate the result per se (scaling quantumness to the control plane), but it clearly motivates asking whether the same quantum-native capabilities can be exploited with more resource-efficient, topology- and traffic-aware constructions.

I also agree that a deployed physical and entanglement connectivity graph should reflect physical constraints, expected traffic, and organizational boundaries. The entangling-cost metric can incorporate some of these factors, but jointly optimizing e-neighborhoods, anchors or tracked sets, resource provisioning, and traffic demand is left open in [5]. This is also one reason why the I-D deliberately defines architectural principles without prescribing these mechanisms.

Thanks also for pointing us back to the QRNA work. It is clearly relevant to recursive topology abstraction, administrative isolation, and inter-domain organization, and we should cite it explicitly in the revised discussion. I see it as complementary rather than as addressing the same question: recursion can limit how much of a domain’s internal topology must be exposed, whereas our quantum-native control abstractions address how the control plane represents and operates on dynamically evolving entanglement resources. A recursive or federated organization would still need to define how resource representations are associated and reconciled across domain boundaries.

Finally, I think the packet-semantics questions in your last paragraph are the same ones addressed above, so I will not repeat the full explanation here. In [5], a tier-1 node is associated with a serving ESP and may delegate the richer inter-ESP forwarding decisions to it. However, the routing analysis in [5] focuses on the tier-2 ESP overlay. It does not prescribe the tier-1 access protocol, a fixed payload size, or the detailed classical-signaling procedures. Classical signaling remains necessary, we are not claiming otherwise. [6] provides a more concrete realization of how physical transfer, local packet transformations, and classical signaling interact. These are valid protocol-design questions, but they concern specific mechanisms that the I-D deliberately does not prescribe.

Anyway, the questions you raise are genuinely interesting. Several of them go beyond what we analyzed in [5] and require further investigation by the community—including us.

> 
> 
> 
> The 1G, 2G, 3G taxonomy (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nature.com%2Farticles%2Fsrep20463&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367875025533%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PExozkOD2EWfoGn1l6uJdnU13xrxTKV7SYU%2Fmte5hZ0%3D&reserved=0) is
> 
> about increasingly demanding management of errors (photon loss, state
> 
> & gate errors, decoherence).  The Napoli architecture assumes:
> 
> 
> 
> * high entanglement rate
> 
> * high fidelity entanglement
> 
> * high availability of quantum memory at routers
> 
> * low-latency, high-speed quantum computation
> 
> 
> 
> So while it's not fully accurate to classify this architecture in the
> 
> same way, I think it's fair to call it a post-3G network.  I'll just
> 
> settle for 4G for the moment.
> 
> 
> 
> ...and the next extension to the architecture actually *DOES* deal
> 
> with both errors and with classical messaging.  The newest paper,
> 
> "Beyond Layering" [6], introduces "stamps" attached to packets. Each
> 
> stamp represents a requested piece of functionality, such as
> 
> purification.  These stamps seem to be about halfway in between our
> 
> RuleSets and David Tennenhouse's IP Capsules from the 1990s (predating
> 
> and in some ways heralding SDN), 
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.acm.org%2Fdoi%2Fabs%2F10.1145%2F231699.231701&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367875048930%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EIVbZvy2sA%2FxHoifJQpppuy8UHb6a%2BHRAjLgvnl%2BseE%3D&reserved=0.
> 
> 
> 
> This one is such a departure from the others that it doesn't even
> 
> mention virtual links or address superposition or routing, though its
> 
> main example does talk about teleporting over a two-hop overlay. It's
> 
> much more focused on the concrete tasks necessary for processing a
> 
> single request.  It still doesn't really take up the issue of a
> 
> connection, and doesn't discuss multiplexed use of entanglement
> 
> resources.
> 
> 
> 
> See [6] Fig. 4.  This is an incredibly helpful figure for
> 
> understanding the lower-level architecture they propose.  The
> 
> Initiator (I'm very happy to see the use of this term rather than
> 
> "source") creates a Plan of Action (PoA) for the packet.  The PoA is
> 
> only held locally, and is generated separately at each node for each
> 
> packet, but its core is translated into a set of Stamps are requests
> 
> for specific actions.  Stamps are carried in the packet itself, and
> 
> can include things like:
> 
> 
> 
> * LINK_PR
> 
> (purification request? not sure)
> 
> * ACT_FORWARD
> 
> * ACT_HOLD
> 
> * (local SWAP at the intermediate node isn't part of the plan decided
> 
> by the Initiator?)
> 
> * CONSUME_TP
> 
> (complete the teleportation?)
> 
> 
> 
> Classical messages can be emitted, and can trigger further actions at
> 
> the receiving ends.
> 
> 
> 
> There are some details here that can be quibbled about, but the basic
> 
> structure of the PoA is good.  However, as noted above, I think this
> 
> should be done using (classical) state at routers along the path,
> 
> rather than being incorporated into the quantum packet.
> 
> 
> 
> I still don't fully understand the packet format, including how many
> 
> qubits are in the header and in the payload.  The payload seems to be
> 
> intended to carry halves of Bell pairs from the Initiator, or possibly
> 
> an intermediate node in the path, to the destination (what we would
> 
> call "Responder" in connection setup, but they don't have that
> 
> notion).
> 
> 
> 
> One issue is that the Stamps are to be carried in the quantum packet,
> 
> which means they are likely to consume a lot of quantum bandwidth and
> 
> demand high-fidelity carriage, otherwise the Stamps will become
> 
> corrupted.
> 
> 
> 
> I would like this design a lot better if the quantum header were
> 
> simply turned into a classical header.  Then we would have a simple
> 
> argument about the locus of state, whether it should be distributed or
> 
> localized to a single node.  I think this argument will come down to
> 
> how much work turns out to be absolutely necessary in the middle of a
> 
> path as the technology develops.  If we do wind up really needing
> 
> purification and anything other than straight-up entanglement swapping
> 
> in more than one or two places in the path, I think we will wind up
> 
> with the distributed connection.  That's the way I think of our
> architecture.

Thanks, Rod. I am very glad that Fig. 4 helped clarify the Dynamic-Kernel structure and that you find the basic PoA organization convincing. 

On the 1G–3G taxonomy and the technological assumptions that you attribute to the architecture, I think we have already explained our position above, so I will not repeat it here. The same applies to the general packet abstraction and the distinction between the I-D, [5], and [6].

There is, however, one important clarification concerning Fig. 4. Stamps are not requests for actions, and the Initiator does not translate its PoA into a set of stamps for downstream execution. Each node independently constructs its own local PoA from the service intent, the accumulated stamps, and its current local state and capabilities. A stamp is appended only after an action has reached a terminal outcome. Thus, LINK_PREP, SWAP, CONSUME_TP, and ACT_FORWARD in the stamp trace certify actions that have already committed; they are not instructions for future execution. In the specific Fig.4 trace, ACT_HOLD, instead, is local soft state and deliberately produces no stamp. The SWAP in the example is planned and executed locally by the intermediate node Y, and its successful completion is then recorded in the meta-header.

I would describe [6] as a different architectural dimension. [5] develops one specific quantum-routing mechanism, whereas [6] proposes a protocol-suite organization that replaces fixed layering with the dynamic composition of network functionalities. For that reason, [6] deliberately does not prescribe one particular realization of routing for example. The wanted functionalities can be realized by suitable micro-protocols or meta-protocols and composed at runtime according to the service intent, the available node capabilities, and the current resource state. Quantum Addressing can likewise be used within the service intent and by the composed control and forwarding functions. The teleportation scenario is therefore an example of how the composition model operates, not a proposal that every service must use that particular overlay or sequence of mechanisms. The point of [6] is to avoid fixing their interaction through permanent layer boundaries before those mechanisms and technologies have matured.

On replacing the quantum meta-header with a classical header, this is probably still where we disagree most. I agree that a classical realization of part of the Dynamic-Kernel execution model is possible in a controlled environment. In fact, we have now experimentally realized the dynamic-composition principle through classical orchestration in NeQOS (https://github.com/QuantumInternet-it/NeQOS) and deployed it on the QuantumInternet.it multi-vendor testbed, coordinating up to 23 quantum-classical devices from four vendors over deployed fiber. That work is currently under review and is therefore not yet publicly available.

This implementation deliberately uses a controlled setting in which the participating devices, resource identifiers, topology, workflows, and coordination channels are known and bounded. It demonstrates that the Dynamic-Kernel principle can be realized with current technology.  It should be noted that the implementation is limited to the Executor and part of the Engine. In particular, a physical quantum meta-header is not implemented. Therefore it does not validate the complete suite proposed in [6]. 

In that more general setting, a classical header can certainly describe the requested operations, but an explicit mechanism is still needed to bind that header to the corresponding quantum resource and to keep the two aligned as the resource is generated, purified, swapped, forwarded, consumed, or lost. That association is not impossible, but it introduces an additional reconciliation problem. Our concern is that — as said above — beyond controlled environments, continuously maintaining that alignment across independently operated nodes and domains could become a scalability bottleneck.

The in-band quantum meta-header is intended to reduce the scope of this separation: it keeps the a service-scoped, append-only, single-writer procedural state—the service intent and immutable commit history— operationally coupled to the evolution of the quantum packet and its resources. This localizes the context required by the next Dynamic Kernel and reduces reliance on separately replicated procedural history, It also preserves quantum-native control information, such as Quantum Addressing.

Your concern about quantum bandwidth and corruption is nevertheless completely fair. Quantum header fields consume physical resources and require suitable protection; [6] does not yet provide a quantitative comparison of that cost. But the corresponding cost of a classical solution is not zero either: it includes association, signaling, state replication, and reconciliation. So I do not think we can conclude a priori that turning the quantum header into a classical one is the better general solution. The comparison has to account for both costs under the same network, hardware, failure, and traffic assumptions.

So, in short: yes, classical control alone can work—and we have demonstrated a classical realization of the dynamic-composition principle on a real testbed. I just do not agree that this removes the architectural motivation for quantum-native in-band control outside controlled environments (which will augment classical control). The stronger motivation for quantum-native control concerns coherent control variables whose semantics cannot be preserved by an ordinary classical field. Our claim should therefore not be that classical control cannot operate a quantum network, but that it cannot be the only control representation.

> 
> 
> 
> To extend the comparison a little more with our QRNA/RuleSet
> 
> architecture (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F2112.07092&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367875071475%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IDxA6Pjh4ArAorPGC0bP%2BxplM%2BzJCAffiLRv9QXwoY8%3D&reserved=0
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F2112.07093&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367875098972%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Bkeu6zL6jOtpVoLXsLOBHNSuXsCLsJjFtKnPyhjH00I%3D&reserved=0 https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farxiv.org%2Fabs%2F1904.08605&data=05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367875126357%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yHH21ID4fYODRomddK9HWNALgfWeMb9eS77eEH9klLM%3D&reserved=0)
> 
> 
> 
> * Plan of Action (PoA): like our RuleSet, describes a sequence of
> 
> things that should happen.  Our RuleSets are stateful, defined by
> 
> the Responder during connection setup, and live through the
> 
> connection.  Napoli PoA is ephemeral, defined locally for a packet
> 
> and lives only until that packet processing at the local node is
> 
> complete (which could actually be until the E2E transaction is
> 
> complete).
> 
> * Dynamic Kernel: like our RuleSet Engine.
> 
> * Stamps: like our Rules.  Each Rule of ours contains a Condition
> 
> Clause and an Action Clause.  Stamps likewise wait for some
> 
> condition to be fulfilled before they can be "committed".
> 
> * The biggest difference is our full-path, fully distributed but
> 
> asynchronous *computation* which results in creation of E2E
> 
> entanglement, versus their emphasis on trying to be closer to
> 
> hop-by-hop and to carry less state at intermediate nodes.  Given
> 
> that an entire PoA can't be retired until the local resources can be
> 
> reclaimed, this is maybe not as big a difference as it first seems.
> 
> 
> 
> Overall, except for the need for high-fidelity bandwidth to carry the
> 
> Stamps in-band, this is a 1G architecture, I think, and much more
> 
> implementable than the 4G stuff in the first half of this message.
> 
> One open agenda item, from my point of view, is improving the
> 
> integration of those two sets, assuming that is indeed the Napoli
> 
> plan.
> 

Rod, I agree that there is certainly a family resemblance at the very general level of distributed local execution. However, I think the proposed one-to-one mapping obscures the distinctive contribution of [6]. Let me try to spell out the differences as I see them.
This is not a judgment that one model is universally better than the other. They make different architectural choices about where execution authority resides, when protocol logic is constructed, how long that logic persists, and how globally consistent progress is established. Precisely for these reasons, however, I would distinguish [6] quite clearly from QRNA/RuleSets.

In QRNA, recursion is organized through scoped connection layers: connection requests move between recursive levels, RuleSets may be rewritten at domain boundaries, and a two-pass setup installs connection-scoped programs at the nodes along the path. Indeed, in QRNA, connection establishment follows a two-pass procedure. First, a request travels from the Initiator to the Responder and collects information about the path and available resources. The Responder then constructs the RuleSets, which are distributed on the return path and installed at the participating nodes as state associated with that specific connection.

This is precisely where [6] takes a different architectural direction. It does not establish an end-to-end connection by constructing and distributing a path-wide program. No Initiator, Responder, controller, or intermediate domain determines the complete execution logic in advance. Instead, every node constructs a new local PoA at runtime from the service intent, the commit history, and its current state and capabilities. The network-wide execution structure emerges progressively from those local decisions.

The PoA is therefore not a short-lived RuleSet. A RuleSet is a program installed for a specific connection that prescribes which actions should be executed when the corresponding conditions are met, even when those actions occur asynchronously.
A PoA is a locally synthesized, speculative DAG that exists only to determine what can be executed in the current context of the node. Once the selected local actions have terminated and meta-header authority has been transferred, that PoA can be discarded. The PoA remains entirely local to the node that constructs it: it is never announced, transmitted, or installed at another node.

Likewise, the Dynamic Kernel is not simply another RuleSet Engine. A RuleSet Engine evaluates the conditions and executes the actions of a program installed during connection setup. A Dynamic Kernel runs at each node and constructs the local program itself: it plans candidate actions, evaluates resource and capability constraints, binds the selected actions to the micro-protocols currently available, dynamically composes those micro-protocols into meta-protocols, and executes the resulting schedule.

Stamps are also not analogous to Rules. A Rule is a conditional instruction waiting to be executed. A stamp is an immutable record generated only after an action has reached a terminal outcome. It contains no Action Clause for future execution and never waits for a Condition Clause to become true. It tells the next Dynamic Kernel what has already committed, thereby constraining—but not prescribing—the next locally generated PoA. Their temporal and operational semantics are therefore almost opposite.

The computation in [6] is also fully distributed, but it is distributed in a different sense. QRNA distributes a program across the connection path before execution. In [6], no global program is distributed: the network-wide service-fulfillment DAG emerges from independently generated local PoAs and their committed outcomes. Moreover, micro-protocols and dynamically composed meta-protocols may themselves coordinate operations across multiple nodes, using classical signaling whenever required, without relying on network-wide synchronization. This should therefore not be reduced to classical hop-by-hop processing.

The distinctive—and, to the best of our knowledge, unique—combination explored in [6] is the runtime construction of local PoAs, the dynamic composition of reusable micro-protocols as the organizational logic that replaces fixed layering while preserving modularity, commit-only in-band stamps, and the emergence of a network-wide execution DAG without distributing or maintaining a path-wide program.

Finally, I do not think that there are two Napoli architectural “sets” waiting to be integrated. [5] instantiates a particular routing mechanism enabled by Quantum Addressing. [6] defines a protocol-organization model within which routing and other functions can be dynamically composed. A routing mechanism such as the one in [5] can therefore be instantiated within this organization, but it is not required by it.

This separation is not only conceptual. In NeQOS—our experimental implementation —we realized the dynamic-composition principle, specifically the Executor and part of the Engine of the Dynamic Kernel, without implementing the routing mechanism proposed in [5]. We used it to operate entanglement-based network services and applications on a deployed, multi-vendor quantum-network testbed, including sustained polarization-drift characterization across quantum links. This provides concrete evidence that the protocol-organization model of [6] is not tied to the particular routing mechanism developed in [5]. At the same time, there is no incompatibility in the opposite direction: the mechanism proposed in [5] can be expressed within the compositional logic of [6], by realizing its routing and generalized-forwarding operations through dynamically composed micro-protocols.

> 
> -----
> 
> 
> 
> Okay, that's more than enough for now.  Just a few minor notes to
> 
> close things out:
> 
> 
> 
> * The "orthogonal subspace" of the address encoding seems to be
> 
> unnecessary, and might even rest on some misunderstanding of
> 
> encoding data in quantum states?
> 
> * The term "ebit" is already defined with a different meaning, long
> 
> ago.  See early Bennett papers.  Let's not run around redefining
> 
> terms unless necessary.
> 
> * As anybody hanging around QIRG can tell you, I dislike the use of
> 
> the term "forwarding" unless you're really literally forwarding a
> 
> packet to another node.
> 
> * In Sec. 4 of the I-D, we have "This section extends Section 5 of
> 
> [RFC9340].</par> The Quantum Internet is an entanglement-packet
> 
> switching network,..." that wording gives the impression that 9340
> 
> defines the Quantum Internet as a packet-based network, which it
> 
> does not. I recommend you reword it to be clear that packet-based is
> your proposal (though I think not completely original).

On the “orthogonal subspace,” I am not sure which passage you are referring to, since this does not appear in the I-D. This concept appears in both [5] and [6], but in different senses. In [5], orthogonal computational-basis states encode perfectly distinguishable node addresses. In [6], orthogonality is used for meta-header/payload separation. What we actually require in [6] are independently addressable subsystems—or degrees of freedom—with header operations acting trivially on the payload. Orthogonality is one possible realization, but is not generally sufficient to guarantee non-perturbing access. So, fair point.

On “ebit,” agreed. We used the term to denote one locally held member of an EPR pair. This creates ambiguity with its alternative meaning as a unit of bipartite entanglement associated with the pair rather than with either constituent qubit.

On “forwarding,” I know we disagree on the terminology :-) We use “generalized” deliberately because the function includes operations such as swapping and purification, as well as physical transfer when required. We will make that broader meaning explicit and we will also revisit whether another term would avoid confusion.

Finally, agreed on the wording concerning RFC 9340. We will make it explicit that the entanglement-packet-switching model is our proposal, not something defined by RFC 9340. And yes, we are not claiming that the general idea of packet-based quantum networking originated with us. Our contribution concerns the particular architectural role and structure assigned to the quantum packet and its integration with quantum-native control and generalized forwarding.

> Whew!


Whew indeed—and thank you again for investing so much time in this. Your comments have made very clear where our wording allows the architectural principles of the I-D to become confused with the specific mechanisms explored in [5] and [6]. We have quite a bit to fix and clarify in the next revision.

> 
> I think I now have a moderate understanding of the overall Napoli
> 
> architecture.  I'm not sure yet how they overall want to move forward,
> 
> but it's great to see the architectural ideas becoming more concrete.

We are revising the draft accordingly to the replies and your comments! Thanks a lot
> 
> 
> 
> I'm off to West Virginia to see family, then Korea for a workshop,
> 
> Indonesia for work, then back home, then I'll see Sara, Joaquin and
> 
> others in Toronto!  So I'll likely be even worse than usual about
> 
> responding to email, but I'll try to keep up.
> 
> 
> 
> Happy August, y'all,
> 
> 
> --Rod

Sara 

> 
>> 
>> 
>> _______________________________________________
>> Qirg mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>> 
>