Subject: [Qirg] draft-irtf-qirg-principles: life cycle of entangled pairs

From: Wojciech Kozlowski <[email-masked]>
Date: Wed, 16 Oct 2019 08:25:23 +0000

Dear QIRG,

Following our call on Monday (minutes<https://mailarchive.ietf.org/arch/msg/qirg/HaYRpAp_z8JFjC--gaiUOFI_jSE>, recording<https://www.dropbox.com/s/wnwkade2ofagug0/qirgdraftprinciples%20on%202019-10-14%2011%3A46.mp4?dl=0>), there is consensus that I proceed writing up the updated section on how quantum networks relate to classical networks. In addition to what I wrote in the previous e-mail I will also add some notes on the inter-networking boundaries. Bruno has also volunteered to draw up a brief section on the analogy with MPLS.

GitHub

One point mentioned on the call was that we will try to make better use of GitHub. I was going to enable issues, but if people need a GitHub account to participate that might go against the goal of making sure that participation is always possible through the mailing list so just receiving notifications from GitHub might not be sufficient. Stephen is investigating.

In the meantime the GitHub repo is still live: https://github.com/Wojtek242/draft-irtf-qirg-principles
And thanks to Stephen there is now a more convenient overview of the work items: https://github.com/Wojtek242/draft-irtf-qirg-principles/projects/1

Next Work item: Life cycle of entangled pairs

Another point raised by Rana on the call was related to the process of receiving the entangled pairs at the end nodes. This has inspired me to choose as the next work item, the life cycle of entangled pairs.

This should cover high level overviews of:

  *   How entangled pairs are generated on a link (i.e. heralding).
  *   Entanglement swapping
  *   Distillation
  *   Delivery to application

From their generation on a link (including how this is done, receive/send and all) up to the receipt by an application. This text would be an update to section 4 "Achieving quantum connectivity" which precedes the section on the relation of classical networks to quantum networks.

What feedback am I looking for:

  *   Is the entire process clear enough for people who have not quantum physics knowledge to understand the process - if you are a person without a quantum background and something is not clear to you - please raise this issue on the mailing list
  *   By trying to be concise and writing only at a high-level, have I covered the important physical details
  *   There are better experts than me on the topic of heralding and distillation so I would very much welcome contributions from people who understand this better than me

Important dates for this discussion:

  *   2019-10-16: discussion opened on QIRG mailing list.
  *   2019-10-23: please send all initial comments by this date to allow some discussion before the call.
  *   2019-10-28: next call.

Proposed content

Links to current version for convenience:
Datatracker version: https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
GitHub version: https://github.com/Wojtek242/draft-irtf-qirg-principles

  *   Bell pairs

     *   Already exists in draft in section 4.3.1 - these are the entangled pairs we consider.
     *   Section 4.3.2 justifies using entangled pairs by explaining teleportation. Add point that teleportation is only one possible use case for entangled pairs. Some applications may not need teleportation and work directly on the entangled pairs. There is an analogy to be made here with TCP/UDP - teleportation is likely to be the mechanism for reliable quantum data transmission (TCP), but sometimes we just want direct access to the network's most basic service - the entangled pairs (just like UDP gives direct access to the IP datagram service).
  *   Link generation (link experts, please chip in)
     *   Entanglement is generated on a link through coordinated action of the two nodes at the two ends of the link.
     *   The key idea is that each node sends a qubit (photon over a fibre) that is entangled with a local qubit (e.g. electron in an NV centre)
     *   These photons must coincide (as closely as possible) at a detector somewhere in between the nodes (can be in the middle, or can sit at one of the two nodes)
     *   This detector station will know if entanglement succeeded or not and send a suitable response to the two end nodes (this is the heralding)
     *   The end nodes will know that their local qubit is entangled with the qubit at the other node upon receipt of a confirmation from this detector station
  *   Entanglement swapping
     *   This is already in section 4
     *   Basically longer entangled pairs are created through combining shorter pairs - key observation is that this does not rquire any additional transmission the quantum channels (i.e. no qubits are sent in this step).
     *   Add brief mention of possible similarities and difference with classical forwarding.
        *   Similarities: swapping can be thought of as the equivalent of forwarding. Entanglement swapping just like forwarding will most likely depend on some table lookup which tells the device which qubits to swap.
        *   Differences: in classical device forwarding is unidirectional process. A packet arrives on one port and is forwarded on another port. Entanglement swapping has entangled pairs being generated on two links and then performs a swap on them.
  *   Distillation
     *   Very much not an expert here - would welcome contributions from others.
     *   Each entangled pair comes with a quality metric - fidelity. This is a quantity between 0 and 1 and it expresses the "closeness" of the state we have to the state we want. Entangled pairs produced on a link will, in general, not have fidelity of 1 and each entanglement swap decreases the fidelity further.
     *   Distillation is a process through which multiple entangled pairs can be combined to probabilistically produce a single entangled pair of higher fidelity.
  *   Delivery to application
     *   Entanglement swapping of Bell pairs will yield Bell pairs. However, which of the four Bell pairs is not deterministic (but the node performing the swap will know what is the outcome Bell pair).
     *   If the entangled pair is to be delivered to the application we need to pieces of information:
        *   Which of the four Bell pairs is delivered - the network can figure out the final Bell pair from all the intermediate entanglement swap outcomes and wither notify the application or perform a correction such that the same Bell pair is always delivered (this correction can be done locally at one of the end-nodes)
        *   The two end-nodes must have enough information to be able to correlate which qubit at their end is part of the delivered entangled pair. If this information is lost, we effectively don't have an entangled pair.
        *   Is the fidelity good enough for it? The application will have some minimum fidelity requirements and the network should be able to deliver (or notify that it is impossible).

Thanks,
Wojtek

---

From: Angela Sara Cacciapuoti <[email-masked]>
Date: Wed, 16 Oct 2019 12:00:47 +0200

Dear Wojtek,

thanks for your efforts.

Regarding the "Link generation", the described process is one of the possible ones.

In a recent paper 

https://arxiv.org/abs/1907.06197 <https://arxiv.org/abs/1907.06197> 

we tried to explain some important concepts by adopting a communications engineering perspective to allow a person with no physics background to grasp the idea.

In particular in sec. III.C we described - from a practical perspective - the entanglement generation and distribution process by then highlighting in Tab II and in the associated section the needed communication blocks.

I hope that this can help the discussion.

Best Regards
Sara

Angela Sara Cacciapuoti, Ph.D., IEEE Senior Member
Co-Director - FLY: Future Communications Lab    
http://www.quantuminternet.it
Tenure-Track Assistant Professor, University of Naples Federico II
Area Editor:
	IEEE Communications Letters
Editor/Associate Editor:
	IEEE Trans. on Communications
	IEEE Trans. on Wireless Communications
	IEEE Open Journal of the Communications Society
IEEE Boards: 
	IEEE ComSoc WICE Standing Committee
	IEEE ComSoc YPs Standing Committee
Email: [email-masked]
http://wpage.unina.it/angelasara.cacciapuoti
Twitter: https://twitter.com/AngelaSaraCacc

> Il giorno 16 ott 2019, alle ore 10:25, Wojciech Kozlowski <[email-masked]> ha scritto:
> 
> Dear QIRG,
> 
> Following our call on Monday (minutes <https://mailarchive.ietf.org/arch/msg/qirg/HaYRpAp_z8JFjC--gaiUOFI_jSE>, recording <https://www.dropbox.com/s/wnwkade2ofagug0/qirgdraftprinciples%20on%202019-10-14%2011%3A46.mp4?dl=0>), there is consensus that I proceed writing up the updated section on how quantum networks relate to classical networks. In addition to what I wrote in the previous e-mail I will also add some notes on the inter-networking boundaries. Bruno has also volunteered to draw up a brief section on the analogy with MPLS.
> 
> GitHub
> 
> In the meantime the GitHub repo is still live: https://github.com/Wojtek242/draft-irtf-qirg-principles <https://github.com/Wojtek242/draft-irtf-qirg-principles>
> And thanks to Stephen there is now a more convenient overview of the work items: https://github.com/Wojtek242/draft-irtf-qirg-principles/projects/1 <https://github.com/Wojtek242/draft-irtf-qirg-principles/projects/1>
> 
> How entangled pairs are generated on a link (i.e. heralding).
> Entanglement swapping
> Distillation
> Delivery to application
> 
> Is the entire process clear enough for people who have not quantum physics knowledge to understand the process - if you are a person without a quantum background and something is not clear to you - please raise this issue on the mailing list
> By trying to be concise and writing only at a high-level, have I covered the important physical details
> There are better experts than me on the topic of heralding and distillation so I would very much welcome contributions from people who understand this better than me
> 
> 2019-10-16: discussion opened on QIRG mailing list.
> 2019-10-23: please send all initial comments by this date to allow some discussion before the call.
> 2019-10-28: next call.
> 
> Proposed content
> 
> Datatracker version: https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/ <https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/>
> GitHub version: https://github.com/Wojtek242/draft-irtf-qirg-principles <https://github.com/Wojtek242/draft-irtf-qirg-principles>
> 
> Bell pairs
> Already exists in draft in section 4.3.1 - these are the entangled pairs we consider.
> Section 4.3.2 justifies using entangled pairs by explaining teleportation. Add point that teleportation is only one possible use case for entangled pairs. Some applications may not need teleportation and work directly on the entangled pairs. There is an analogy to be made here with TCP/UDP - teleportation is likely to be the mechanism for reliable quantum data transmission (TCP), but sometimes we just want direct access to the network's most basic service - the entangled pairs (just like UDP gives direct access to the IP datagram service).
> Link generation (link experts, please chip in)
> Entanglement is generated on a link through coordinated action of the two nodes at the two ends of the link.
> The key idea is that each node sends a qubit (photon over a fibre) that is entangled with a local qubit (e.g. electron in an NV centre)
> These photons must coincide (as closely as possible) at a detector somewhere in between the nodes (can be in the middle, or can sit at one of the two nodes)
> This detector station will know if entanglement succeeded or not and send a suitable response to the two end nodes (this is the heralding)
> The end nodes will know that their local qubit is entangled with the qubit at the other node upon receipt of a confirmation from this detector station
> Entanglement swapping
> This is already in section 4
> Basically longer entangled pairs are created through combining shorter pairs - key observation is that this does not rquire any additional transmission the quantum channels (i.e. no qubits are sent in this step).
> Add brief mention of possible similarities and difference with classical forwarding.
> Similarities: swapping can be thought of as the equivalent of forwarding. Entanglement swapping just like forwarding will most likely depend on some table lookup which tells the device which qubits to swap.
> Differences: in classical device forwarding is unidirectional process. A packet arrives on one port and is forwarded on another port. Entanglement swapping has entangled pairs being generated on two links and then performs a swap on them.
> Distillation
> Very much not an expert here - would welcome contributions from others. 
> Each entangled pair comes with a quality metric - fidelity. This is a quantity between 0 and 1 and it expresses the "closeness" of the state we have to the state we want. Entangled pairs produced on a link will, in general, not have fidelity of 1 and each entanglement swap decreases the fidelity further.
> Distillation is a process through which multiple entangled pairs can be combined to probabilistically produce a single entangled pair of higher fidelity.
> Delivery to application
> Entanglement swapping of Bell pairs will yield Bell pairs. However, which of the four Bell pairs is not deterministic (but the node performing the swap will know what is the outcome Bell pair).
> If the entangled pair is to be delivered to the application we need to pieces of information:
> Which of the four Bell pairs is delivered - the network can figure out the final Bell pair from all the intermediate entanglement swap outcomes and wither notify the application or perform a correction such that the same Bell pair is always delivered (this correction can be done locally at one of the end-nodes)
> The two end-nodes must have enough information to be able to correlate which qubit at their end is part of the delivered entangled pair. If this information is lost, we effectively don't have an entangled pair.
> Is the fidelity good enough for it? The application will have some minimum fidelity requirements and the network should be able to deliver (or notify that it is impossible).
> 
> Thanks,
> Wojtek
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 16 Oct 2019 16:21:42 +0000

Dear Sara

Thank you for this very clear paper.

In this article https://iopscience.iop.org/article/10.1088/1367-2630/18/8/083015 the scheme "Midpoint-source" who correspond to your scheme "at mid-point", it is show that it is the more robust  to photon loss. Each repeater node has an internal BSA, allowing rapid reset of a memory qubit if latching fails.

>> The key idea is that each node sends a qubit (photon over a fibre) that is entangled with a local qubit (e.g. electron in an NV centre)

Best Regards
Patrick

De : Qirg <[email-masked]> De la part de Angela Sara Cacciapuoti
Envoyé : mercredi 16 octobre 2019 12:01
À : Wojciech Kozlowski <[email-masked]>
Cc : [email-masked]
Objet : Re: [Qirg] draft-irtf-qirg-principles: life cycle of entangled pairs

Dear Wojtek,

thanks for your efforts.

In a recent paper

https://arxiv.org/abs/1907.06197

Best Regards
Sara

Email: [email-masked]<mailto:[email-masked]>

---

From: Angela Sara Cacciapuoti <[email-masked]>
Date: Thu, 17 Oct 2019 09:50:14 +0200

Dear Patrick,
very nice to hear from you.

Yes indeed, the one mentioned by Wojtek is one of the possible scheme.

The “at mid-point” scheme seems, as you stated, more robust to photon loss but it can be deemed more reminiscent of classical centralized approaches.

The other two schemes, including the one mentioned by Wojtek, can be deemed more reminiscent of decentralized approaches. 

Hence, the choice between robustness and decentralization depends on the communications/networks requirements we are thinking about, as well as on the underlying hardware technology.

All the best
Sara

> Il giorno 16 ott 2019, alle ore 18:21, Gelard Patrick <[email-masked]> ha scritto:
> 
> Dear Sara
>  
> In this article https://iopscience.iop.org/article/10.1088/1367-2630/18/8/083015 the scheme “Midpoint-source” who correspond to your scheme “at mid-point”, it is show that it is the more robust  to photon loss. Each repeater node has an internal BSA, allowing rapid reset of a memory qubit if latching fails.
>

---

From: Gelard Patrick <[email-masked]>
Date: Mon, 21 Oct 2019 08:59:00 +0000

Thank you Sara for your answer.

>> Hence, the choice between robustness and decentralization depends on the communications/networks requirements we are thinking about, as well as on the underlying hardware technology.
Yes, 

Probably that the quantum internet, just like the classic internet, will be made up of autonomous systems not necessarily based on the same quantum network technologies and therefore architecture principle. What matters is their interoperability to provide secure end-to-end interconnections.    For the classic Internet this is based on Internet exchange point ( https://en.wikipedia.org/wiki/Internet_exchange_point ) or transit network ( https://en.wikipedia.org/wiki/Internet_transit )

Bests regard
/Patrick

-----Message d'origine-----
De : Angela Sara Cacciapuoti <[email-masked]> 
Envoyé : jeudi 17 octobre 2019 09:50
À : Gelard Patrick <[email-masked]>
Cc : [email-masked]
Objet : Re: [Qirg] draft-irtf-qirg-principles: life cycle of entangled pairs

Dear Patrick,

All the best
Sara

> >> The key idea is that each node sends a qubit (photon over a fibre) 
> >> that is entangled with a local qubit (e.g. electron in an NV 
> >> centre)
>  
>  
> Best Regards
> Patrick
>  
> De : Qirg <[email-masked]> De la part de Angela Sara 
> Cacciapuoti Envoyé : mercredi 16 octobre 2019 12:01 À : Wojciech 
> Kozlowski <[email-masked]> Cc : [email-masked] Objet : Re: 
> [Qirg] draft-irtf-qirg-principles: life cycle of entangled pairs
>  
> Dear Wojtek,
> 
> thanks for your efforts.
> 
>                 IEEE Communications Letters Editor/Associate Editor:
>                 IEEE Open Journal of the Communications Society IEEE 
> Boards:

---

From: Wojciech Kozlowski <[email-masked]>
Date: Thu, 24 Oct 2019 08:07:34 +0000

Dear QIRG,

*************
Please note that in some countries the clocks move back by an hour this weekend. The call may be at a different time in your local time zone. The call is still scheduled for 11:00 GMT/UTC on Monday. If you use the calendar event I sent out it will be set to the correct time.
*************

The next call to discuss the "Architectural Principles for a Quantum Internet" will be on 2019-10-28 Monday 11:00 GMT. We will go over the topic covered below, that is the life cycle of entangled pairs.

Bridge link: https://meet.jit.si/QirgDraftPrinciples

There was some discussion about the mid-point and link generation and the physical layer so we will go over these points.

The agenda:

  1.  Any additional feedback in addition to what was raised on the mailing list.
  2.  Discuss the issues raised
     *   Link generation details
     *   Layering (disclaimer: I'm against including layers in this draft, but a brief discussion on the call may be warranted for a better understanding)
     *   Physical layer: should this be included in this draft? And if so, how much?
  3.  I would like to pool contributions on the topic of entanglement purification/distillation
  4.  Decide if rough consensus exists

Looking forward:

After this call there will only be one more before the meeting in Singapore. Therefore, I will aim to write up the previous section and this section up by mid next week so that we can go over the actual text in the last call (instead of opening up a new topic).

Thanks,
Wojtek

On Wed, 2019-10-16 at 08:25 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

GitHub

Proposed content

  *   Bell pairs

Thanks,
Wojtek

Qirg mailing list

[email-masked]<mailto:[email-masked]>

---

From: Gelard Patrick <[email-masked]>
Date: Thu, 24 Oct 2019 13:36:01 +0000

Dear all,

I will not be available next week. Concerning the “mid-point” i would like to have some clarification :

1/ Rodney had answered :

De : Rodney Van Meter <[email-masked]>
Envoyé : vendredi 15 mars 2019 13:24
À : Gelard Patrick <[email-masked]>
Cc : Rodney Van Meter <[email-masked]>; Wojciech Kozlowski <[email-masked]>; [email-masked]
Objet : Re: [Qirg] agenda

An interesting question we have waffled about in our design is whether the satellite (or any entangled photon pair source, which we call an EPPS) is part of the link, or a node visible at the network level.  Our current stance is that it’s only part of the link, and can’t be addressed in (e.g.) our connection setup process.  It’s handled instead by a link-layer protocol. Why? Because nodes farther away than the ones receiving those photons never need to send a message to the EPPS.

There are three major link timing regimes:
* meet-in-the-middle, which we call M—>I<—M, memory—>interference<—memory or MIM
* sender-receiver, which we call memory—>memory or MM
* midpoint source, which we call memory<—source—>memory or MSM

Cody Jones et al. (at least one of “al.” is on this list, I believe) did some great analysis on MSM links.
https://arxiv.org/abs/1505.01536

—Rod

Any entangled photon pair source (Spontaneous Parametric Down-Conversion, NV center in diamond, …, https://physics.aps.org/synopsis-for/10.1103/PhysRevLett.114.220501  ), would be considered to be part of the link  and  It’s handled instead by a link-layer protocol, if I understood correctly. So does the source have to regularly generated pair of entanglement (photon-photon, Matter-photon,) since it can’t be addressed in the connection setup process (Not on demand) ?

2/ Concerning different scheme meet-in-the-middle, sender-receiver, midpoint, …

Sara had answered  : “Hence, the choice between robustness and decentralization depends on the communications/networks requirements we are thinking about, as well as on the underlying hardware technology.” I agree and I deduce that the choice of a particular scheme is not based on an general architectural principle, but rather on a tradeoff  that takes into account different requirements and constraints in connection with the application/mission need. So how should this principle be interpreted : “The key idea is that each node sends a qubit (photon over a fibre) that is entangled with a local qubit (e.g. electron in an NV centre)” ?

Bests regard
/Patrick

De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
Envoyé : jeudi 24 octobre 2019 10:08
À : [email-masked]
Objet : Re: [Qirg] draft-irtf-qirg-principles: life cycle of entangled pairs

Dear QIRG,

*************

The agenda:

Looking forward:

Thanks,
Wojtek

GitHub

Proposed content

  *   Bell pairs

  *   Entanglement swapping

  *   Distillation

Thanks,
Wojtek

Qirg mailing list

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 28 Oct 2019 08:25:12 +0000

Dear QIRG,

A brief reminder that this call is happening today at 11:00 GMT (in approximately 2.5 hours from the time of sending just to draw attention once more to clocks having moved).

Thanks,
Wojtek

On Thu, 2019-10-24 at 08:07 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

*************

The agenda:

Looking forward:

Thanks,
Wojtek

GitHub

Proposed content

  *   Bell pairs

Thanks,
Wojtek

Qirg mailing list

Qirg mailing list

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 28 Oct 2019 10:50:10 +0000

===
Call is is in 10 minutes.
===

The agenda:

  1.  Any additional feedback in addition to what was raised on the mailing list.
     *   Discuss the issues raised
     *   Link generation details
     *   Layering (disclaimer: I'm against including layers in this draft, but a brief discussion on the call may be warranted for a better understanding)
     *   Physical layer: should this be included in this draft? And if so, how much?
  2.  I would like to pool contributions on the topic of entanglement purification/distillation
  3.  Decide if rough consensus exists

"Architectural Principles for a Quantum Internet" Call
Meeting URL: https://meet.jit.si/QirgDraftPrinciples

Draft URL (datatracker): https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
Draft URL (GitHub): https://github.com/Wojtek242/draft-irtf-qirg-principles

*** Use Chrome/Chromium

Safari and Firefox may experience issues with Jitsi.

*** Please set your name once you connect

You can do this by going into the options in the bottom right of the screen and clicking on the option which will be labelled "me".

This will be used to assemble a participant list for the minutes so set whatever identifier you are comfortable with for that purpose.

*** Please do not use video

Please do not use video to minimise the risk of bandwidth issues. Jitsi can probably handle it and it has some settings to fiddle with, but I'd rather not try since it's not necessary.

*** The call will be recorded

This is just FYI.

*** If you're experiencing connectivity issues

Close the tab and reopen the link - you should be able to do this transparently to other participants.

On Mon, 2019-10-28 at 08:25 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

Thanks,
Wojtek

*************

The agenda:

Looking forward:

Thanks,
Wojtek

GitHub

Proposed content

  *   Bell pairs

Thanks,
Wojtek

Qirg mailing list

Qirg mailing list

Qirg mailing list

---

From: JW λ John Woodworth <[email-masked]>
Date: Mon, 28 Oct 2019 14:57:59 -0400

Hi Wojtek,Unfortunately, I missed this call.  Would you be able to post a recording?Thanks, /John 
-------- Original message --------From: Wojciech Kozlowski <[email-masked]>
===
Call is is in 10 minutes.
===

The agenda:

Any additional feedback in addition to what was raised on the mailing list.

Discuss the issues raisedLink generation detailsLayering (disclaimer: I'm against including layers in this draft, but a brief discussion on the call may be warranted for a better understanding)Physical layer: should this be included in this draft? And if so, how much?
I would like to pool contributions on the topic of entanglement purification/distillationDecide if rough consensus exists

*** Use Chrome/Chromium

This is just FYI.

Dear QIRG,

Thanks,
Wojtek

Dear QIRG,

*************
Please note that in some countries the clocks move back by an hour this weekend. The call may be at a different time in your local time zone. The call is still scheduled for 11:00 GMT/UTC on Monday. If you use the calendar event I sent out it will be
 set to the correct time.
*************

Bridge link: 
https://meet.jit.si/QirgDraftPrinciples 

The agenda:

Any additional feedback in addition to what was raised on the mailing list.Discuss the issues raised

Link generation detailsLayering (disclaimer: I'm against including layers in this draft, but a brief discussion on the call may be warranted for a better understanding)Physical layer: should this be included in this draft? And if so, how much?
I would like to pool contributions on the topic of entanglement purification/distillationDecide if rough consensus exists

Looking forward:

After this call there will only be one more before the meeting in Singapore. Therefore, I will aim to write up the previous section and this section up by mid next week so that we can go over the actual text in the last call (instead of opening up a new
 topic).

Thanks,
Wojtek

Dear QIRG,

Following our call on Monday (minutes,

recording), there is consensus that I proceed writing up the updated section on how quantum networks relate to classical networks. In addition to what I wrote in the previous e-mail I will also add some notes on the inter-networking boundaries. Bruno has
 also volunteered to draw up a brief section on the analogy with MPLS.

GitHub

One point mentioned on the call was that we will try to make better use of GitHub. I was going to enable issues, but if people need a GitHub account to participate that might go against the goal of making sure that participation is always possible through
 the mailing list so just receiving notifications from GitHub might not be sufficient. Stephen is investigating.

In the meantime the GitHub repo is still live: https://github.com/Wojtek242/draft-irtf-qirg-principles
And thanks to Stephen there is now a more convenient overview of the work items:
https://github.com/Wojtek242/draft-irtf-qirg-principles/projects/1

How entangled pairs are generated on a link (i.e. heralding).Entanglement swappingDistillationDelivery to application

From their generation on a link (including how this is done, receive/send and all) up to the receipt by an application. This text would be an update to section 4 "Achieving quantum connectivity" which precedes the section on the relation of classical networks
 to quantum networks.

Is the entire process clear enough for people who have not quantum physics knowledge to understand the process - if you are a person without a quantum background and something is not clear to you - please raise this issue on the mailing listBy trying to be concise and writing only at a high-level, have I covered the important physical detailsThere are better experts than me on the topic of heralding and distillation so I would very much welcome contributions from people who understand this better than me

2019-10-16: discussion opened on QIRG mailing list.
2019-10-23: please send all initial comments by this date to allow some discussion before the call.2019-10-28: next call.

Proposed content

Bell pairs

Already exists in draft in section 4.3.1 - these are the entangled pairs we consider.Section 4.3.2 justifies using entangled pairs by explaining teleportation. Add point that teleportation is only one possible use case for entangled pairs. Some applications may not need teleportation and work directly on the entangled pairs. There is an
 analogy to be made here with TCP/UDP - teleportation is likely to be the mechanism for reliable quantum data transmission (TCP), but sometimes we just want direct access to the network's most basic service - the entangled pairs (just like UDP gives direct
 access to the IP datagram service).
Link generation (link experts, please chip in)

Entanglement is generated on a link through coordinated action of the two nodes at the two ends of the link.The key idea is that each node sends a qubit (photon over a fibre) that is entangled with a local qubit (e.g. electron in an NV centre)These photons must coincide (as closely as possible) at a detector somewhere in between the nodes (can be in the middle, or can sit at one of the two nodes)This detector station will know if entanglement succeeded or not and send a suitable response to the two end nodes (this is the heralding)The end nodes will know that their local qubit is entangled with the qubit at the other node upon receipt of a confirmation from this detector station
Entanglement swapping

This is already in section 4Basically longer entangled pairs are created through combining shorter pairs - key observation is that this does not rquire any additional transmission the quantum channels (i.e. no qubits are sent in this step).Add brief mention of possible similarities and difference with classical forwarding.

Similarities: swapping can be thought of as the equivalent of forwarding. Entanglement swapping just like forwarding will most likely depend on some table lookup which tells the device which qubits to swap.Differences: in classical device forwarding is unidirectional process. A packet arrives on one port and is forwarded on another port. Entanglement swapping has entangled pairs being generated on two links and then performs a swap on them.

Distillation

Very much not an expert here - would welcome contributions from others. Each entangled pair comes with a quality metric - fidelity. This is a quantity between 0 and 1 and it expresses the "closeness" of the state we have to the state we want. Entangled pairs produced on a link will, in general, not have fidelity of 1 and each
 entanglement swap decreases the fidelity further.Distillation is a process through which multiple entangled pairs can be combined to probabilistically produce a single entangled pair of higher fidelity.
Delivery to application

Entanglement swapping of Bell pairs will yield Bell pairs. However, which of the four Bell pairs is not deterministic (but the node performing the swap will know what is the outcome Bell pair).If the entangled pair is to be delivered to the application we need to pieces of information:

Which of the four Bell pairs is delivered - the network can figure out the final Bell pair from all the intermediate entanglement swap outcomes and wither notify the application or perform a correction such that the same Bell pair is always delivered (this
 correction can be done locally at one of the end-nodes)The two end-nodes must have enough information to be able to correlate which qubit at their end is part of the delivered entangled pair. If this information is lost, we effectively don't have an entangled pair.Is the fidelity good enough for it? The application will have some minimum fidelity requirements and the network should be able to deliver (or notify that it is impossible).

Thanks,
Wojtek

---

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 29 Oct 2019 08:17:37 +0000

Yes, here is the recording: https://www.dropbox.com/s/kw5bn875poj3nks/qirgdraftprinciples%20on%202019-10-28%2011%3A55.mp4?dl=0

I forgot to switch on the recording in the first few minutes, but I think it only cuts of some recap. Most of the meeting is still recorded.

Also, I still haven't found a good place to store these recordings that is better than my dropbox. If anybody has any ideas, please let me know.

On Mon, 2019-10-28 at 14:57 -0400, JW λ John Woodworth wrote:
Hi Wojtek,

Unfortunately, I missed this call.  Would you be able to post a recording?

Thanks,
/John

-------- Original message --------
From: Wojciech Kozlowski <[email-masked]>

===

The agenda:

*** Use Chrome/Chromium

This is just FYI.

Thanks,
Wojtek

*************

The agenda:

Looking forward:

Thanks,
Wojtek

GitHub

Proposed content

  *   Bell pairs

Thanks,
Wojtek

Qirg mailing list

Qirg mailing list

Qirg mailing list

Qirg mailing list