[Qirg] Feedback draft-cacciapuoti-qirg-quantum-native-architecture-01

[Wojciech Kozlowski <[e-mail]>]

Hi QIRG,

I’m writing this feedback entirely as an individual without a co-chair hat.

First, I think the document tackles a very interesting, if rather for the long-term, topic of quantum control planes. It is an interesting topic and even I don’t expect implementations outside of simulators within the next decade it I think it is relevant to the QIRG to think about.

At the same time, I am finding it hard to process what the draft is trying to achieve. It is clear that it is proposing a quantum-native control plane, but what exactly it is proposing other than this is not clear to me. There are several diagrams and claims, but many are not sufficiently fleshed out. I would struggle to explain how a quantum-native control plane works based on this draft in its current state. Not everything needs to be spelled out and as you say you don’t want to propose protocols, but I would like to be able to intuitively explain how such a control plane would work.


  1.  I think you make a lot of claims in this document that are incredibly strong but not sufficiently evidenced/substantiated:
     *   “However, a purely classical control plane cannot maintain a consistent global view as quantum networks scale, becoming the limiting factor for performance and scalability” <- You have not presented evidence for this statement in the draft. It appears to hinge very heavily on the “amplification principle” which appears to originate from RFC 3439 so it also applies to classical networks, yet we are able to build classical control planes. Can you substantiate your impossibility claim? Though to be clear, one can still talk about quantum-native control planes. I just don’t follow the argument that classical ones are impossible.

                                                                        i.       You repeat this claim with different wording in 4.2 but still with insufficient evidence in my opinion.

     *   “Departs from the end-to-end principle” <- a few others have already objected to this statement, and I would like to throw my hat into that camp. IMO you have not really made a case that the end-to-end principle is not preserved. In what way does it go against the principle? It seems to me that your argument is based on the fact that entanglement is non-local and so state must be kept in the network to keep track of the ends. But I don’t see this as a violation of the principle because the principle states “"The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible." Entanglement generation cannot be implemented correctly with the knowledge of applications at the end points and so in-network state is needed but this is in-line with the principle.

                                                                        i.       This plus all the points raised by others earlier on the mailing list.

     *   At the end of section 4.3 you argue for the EDC but the control plane functions you list are all also performed by classical control planes. Can you elucidate what is quantum in your proposal?
  1.  It is not clear at all if your entanglement-packet is the same thing as a quantum packet <- are they the same thing or are they different?
  2.  You propose quantum addressing, the basic concept is clear enough, but I would ask that you justify it more strongly in the draft. It appears from other discussions that it is based on some formal work in one of your publications – could you at least bring an intuitive understanding of it into the draft? At the moment, I am not able to explain what benefit quantum addressing brings over classical addressing based on reading the draft.
  3.  While I understand the quantum packet format, what I don’t understand is where the packet is. In entanglement-generation networks the pairs are generated per link and then swapped. What would the header be attached to? Can you make this clear in the draft.
  4.  In Section 6 on Generalized Quantum Forwarding it is not clear to me what you are generalizing. You seem to say that because it’s not a simple header lookup and action but a quantum manipulation then it is generalized. But I don’t really follow this argument. In a quantum network you will still have some kind of lookup (like on based on your quantum address) and some corresponding action (e.g., a swap or transmission). I don’t see what is being generalized.

I hope you find this helpful! Let me know if anything is unclear.

Wojciech Kozlowski
Quantum Communication Lead | SURF | [e-mail]<mailto:[e-mail]> | M [phone]
SURF<http://www.surf.nl/> is the collaborative organisation for IT in Dutch education and research