Subject: [Qirg] Minutes for the Quantum Internet Research Group (QIRG) meeting on 22 March 2022

From: Bruno Rijsman <[email-masked]>
Date: Tue, 22 Mar 2022 09:25:47 -0600

Minutes for the Quantum Internet Research Group (QIRG) meeting on 22 March 2022

Chairs: Wojciech Kozlowski and Rodney van Meter

Approximately 90 attendees (remote and in person)

Agenda:

1. Administrivia + group update + resolving any online issues (5 min)

2. draft-irtf-qirg-quantum-internet-use-cases (10 min)

3. Quantum Network Explorer: application programming for the quantum internet (20 min)

4. Discussion (15 min)

Note: links to the presented slides are provided below; information in the slides is not repeated in the meeting minutes.

[Wojciech Kozlowski] Opens the session. Reminder: IRTF is a research organization, not a standards development organization. Chair slides: https://datatracker.ietf.org/meeting/113/materials/slides-113-qirg-chair-slides-00 <https://datatracker.ietf.org/meeting/113/materials/slides-113-qirg-chair-slides-00>
[Wojciech Kozlowski] On 2 Feb 2022, there was a QIRG seminar Marc Kaplan from VeriQloud on the topic of "Building quantum networks at the local area scale". The slides are here: https://datatracker.ietf.org/meeting/interim-2022-qirg-01/materials/slides-interim-2022-qirg-01-sessa-qline-presentation-00.pdf <https://datatracker.ietf.org/meeting/interim-2022-qirg-01/materials/slides-interim-2022-qirg-01-sessa-qline-presentation-00.pdf>  The recording is on YouTube: https://www.youtube.com/watch?v=D_Nb43-uicY <https://www.youtube.com/watch?v=D_Nb43-uicY>
[Wojciech Kozlowski] The next QIRG seminar is to be announced, we are aiming for Sept/Oct.

[Wojciech Kozlowski] QIRG is mentioned in an Arxiv pre-print publication on quantum technologies standardization: https://arxiv.org/abs/2203.01622 <https://arxiv.org/abs/2203.01622>
[Colin Perkins] (Chair of IRTF) Have all of Marie-Jose Montpetit's comments on the principles draft been addressed? [Wojciech Kozlowski] Yes, that is my understanding.

[Kaushik Chakraborty] Gives a presentation describing the progress on the use cases draft. The current version is version 10: https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/10/ <https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/10/> The title has been changed to " Application Scenarios for the Quantum Internet"  The presented slides that Kaushik presented are here: https://datatracker.ietf.org/meeting/113/materials/slides-113-qirg-draft-irtf-qirg-quantum-internet-use-cases-00 <https://datatracker.ietf.org/meeting/113/materials/slides-113-qirg-draft-irtf-qirg-quantum-internet-use-cases-00>
[Kaushik Chakraborty] Is the document ready for last call?

[Rodney van Meter] Rodney sent comments on the use cases draft on the QIRG mailing list 13 March 2022, and Chonggang Wang sent responses on 18 March 2022. Some comments still need further discussion on the mailing list and need to be reflected in the draft. We are getting close, but there will need to be at least one more revision of the draft before last call.

[Rodney van Meter] We also need one final round of word smithing and editing; who is responsible for that? [Colin Perkins] It is the responsibility of the authors to get it in as good a shape as they can, and there will be a final round of editing by the RFC editor at the end of the process (after last call).

[Bart van der Vecht] (PhD student at QuTech, Delft) gives a presentation on the topic of "Application programming for the quantum Internet" including "NetQASM" and the "Quantum Network Explorer (QNE)". The Powerpoint slides that Bart presented are here: https://datatracker.ietf.org/meeting/113/materials/slides-113-qirg-quantum-network-explorer-application-programming-for-the-quantum-internet-00 <https://datatracker.ietf.org/meeting/113/materials/slides-113-qirg-quantum-network-explorer-application-programming-for-the-quantum-internet-00>
[Kireeti Kompella] (CTO Engineering, Juniper Networks) Question: Are you assuming only two nodes in the network, or are you assuming multiple nodes in the network? So, does a node ask for entanglement with "the other node" or with "a specific remote node X"? [Bart van der Vecht] All nodes have a node ID, and when a node requests entanglement it has to specify the node ID of the remote node.

[Kireeti Kompella] When you create an entangled pair, do you also take fidelity into account, and do you consider distillation? [Bart van der Vecht] The application specifies the minimum fidelity when it requests an entanglement, and then it is up to the quantum network stack to provide the requested fidelity (which may involve some sort of filtering or distillation, but it is up to the lower layer how to achieve it).

[Rodney van Meter] Slide 6 shows the interaction between classical control software and the actual quantum device on the same node. What about coordination between nodes? How are synchronization and events between different nodes handled? [Bart van der Vecht] This is handled by exchanging classical messages between nodes.

[Shigeya Suzuki] Are you sending the NetQASM routine every time the application layer calls the QPU? [Bart van der Vecht] Yes, we do. The reason for this is that the next NetQASM routine may depend on some run-time event, e.g., the receipt of a classical message from another node telling the local node what to do next.

[Rodney van Meter] One of the topics brought up on the mailing list when discussing the use cases draft was the use of the word "transmit". I'd like to move away from using this word because it is often interpreted as encoding some information into some photons and sending those photons from one place to another place. In reality, the network layer is responsible for end-to-end entanglement generation (which is a symmetric process). The entanglement may be used for teleportation or for direct measurement. Is there a better word than "transmit"? [Wojciech Kozlowski] The term "creating entanglement" or "generating entanglement" is often used. [David Oran] State synchronization? Another subtlety is whether the data at A persists once it "gets" to B. [?] We are talking about moving data (quantum state) from one node to another. That can be done either by encoding and transmitting it or by teleporting it.

[Kireeti Kompella] Is there any research on how to do distributed quantum computing? For example, if I need 100 qubits for some quantum computation, how can I distribute the computation across two nodes or five nodes? How many qubits do I end up needing on each node? What is the required rate of entanglement between the nodes? Is there actually a gain? If we need only 10 qubits on each node, we will be in a better place, because it will effectively allow us to build a big quantum computer by interconnecting multiple nodes. [Wojciech Kozlowski] Yes, there is research on distributed quantum computing. The group within QuTech that I am part of is called "quantum Internet and network computing" where the latter specifically addresses this topic. This is a work in progress. At this stage, distributed quantum computing is a very different line of research from the quantum Internet and deals with, for example, how to globally orchestrate the distributed quantum computation. It is not immediately obvious how to distribute a quantum computation, and this is not trivial. For example, can you parallelize? Is there a gain? Where do you create entanglement? There are several papers on this topic. [Rodney van Meter] (on chat) We have done a lot in the past on how to split one large computation into parts. https://arxiv.org/abs/quant-ph/0607160 <https://arxiv.org/abs/quant-ph/0607160> Also Simon Benjamin's group at Oxford. Splitting one computation into pieces in order to achieve scalability is a different thing than trying to write actual distributed computations.

[Diego Lopez] (Telefonica) The topic of how to do distributed quantum computations and whether there is any gain is connected to the use cases of a quantum Internet (i.e., the use cases draft) 

[Diego Lopez] We talked about abstracting away how quantum state is transferred to some remote node ID (using encoding and transmission or teleportation). This is exactly the job of the transport layer. [Wojciech Kozlowski] The fact that the quantum transport layer was crossed out in the slide deck was not intended to imply that we don't need a transport layer, only that we (at QuTech) have not yet gotten around to implementing or thinking about the transport layer. This layer was originally labeled "qubit teleportation" but many applications don't need to teleport data, they use the entanglement qubits directly as a resource. It will not be a trivial translation from a classical transport layer. [Diego Lopez] We need to start thinking of "quantum sockets". There may be different flavors (like TCP and UDP in the classical world)

[Bruno Rijsman] I have seen the pre-canned demos on the quantum network explorer; is it also possible to submit our own NetQASM programs for execution on QNE? [Bart van der Vecht] It will be possible in the future, but the feature is still in development right now.