Subject: [Qirg] Call-Minutes : draft-irtf-qirg-principles

From: gyananjay rai <[email-masked]>
Date: Wed, 30 Oct 2019 01:03:01 +0530

---------- Forwarded message ---------
From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 28 Oct 2019, 21:23
Subject: [Fwd: MOM:Today's call]
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>

Thanks for the minutes Gyananjay!

I've added one section for the part before you started taking minutes since
I forgot to ask sooner. Other than that I just added a few clarifications
here and there. I also added the participant list

Thanks a lot for this!

===

Attendees:

Wojciech Kozlowski
Bruno Rijsman
Daniam Henriques
Rod van Meter
Chung-Hung Kuo
Stephen Diadamo
Scott Fluhrer
Gyananjay Rai
Sothy Shan
Piotr Rydlichowski
Eduardo Maschio
+ 2 anonymous

Intro:

WK:Network delivers entangled pairs - can be any of the 4 Bell pairs

BR(Bruno):What about communication qubits?
SF(Scott):Would be good to make note of limitations like that
WK:Will add brief section on physical details with impact on architecture

1.Link generation

BR:Capability discovery function will be important at the physical layer
for quantum networks
RDV:Link generation time factor distinguishes link architectures

2.Entanglement Swapping (Connecting End to End Bell pairs)

WK:
* Anology - Forwarding and Swapping
Forwarding - unidirectional
BR: Swapping - out of order,random

WK:After the swap entangled pair will be in one of 4 of the possible Bell
pairs
RDV:entanglement distribution is like distributed computation

3.Distillation and purification

WK:Fidelity - is a Quality metric
- You cannot run certain security protocols without certain fidelity (they
will just abort)

*entanglement swapping results in inferior entanglement (fidelity gets
worse)

RDV: Work on the section
WK: looking for a better insight
*Will add implication of fidelity on security to draft

BR:How is teleportation affected by imperfect pairs
RDV:Entanglement swapping is a form of teleportation so you just get a
lower fidelity transmission

4.Delivery to Application

WK:
- One of the 4 Bell pairs
#Either network tells which one
#Or always be one of the 4.
-Network delivery of qubit: give them an identifier for Bell pair they
belong to
-Fidelity should be good enough for application

BR:Request Rate or number of Bell pairs vs Circuit switching
RDV:Connection set up Resource allocation
BR:Resource reservation will be unavoidable

WK:To be decided (TBD)
Physical layer - avoid when possible to keep draft accessible

WK:Layer definitions to be avoided
BR:Distinguish P2P &routing
SF:Summed into 3 layers

1.Class of task under P2P
2.Class of task for end to end communication
3.Class of task for coordinating identifiers and other information

Regards
Gyananjay Rai

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, 28 Oct 2019, 16:20
Subject: Qirg Digest, Vol 18, Issue 38
To: <[email-masked]>

Send Qirg mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.irtf.org/mailman/listinfo/qirg
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Qirg digest..."
Today's Topics:

   1. Call in 10 minutes: draft-irtf-qirg-principles
      (Wojciech Kozlowski)

---------- Forwarded message ----------
From: Wojciech Kozlowski <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc:
Bcc:
Date: Mon, 28 Oct 2019 10:50:10 +0000
Subject: [Qirg] Call in 10 minutes: draft-irtf-qirg-principles
*===*
*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

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

"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,

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).

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

Thanks,
Wojtek

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

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,

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

_______________________________________________

Qirg mailing list

[email-masked]

https://www.irtf.org/mailman/listinfo/qirg

_______________________________________________

Qirg mailing list

[email-masked]

https://www.irtf.org/mailman/listinfo/qirg

_______________________________________________

Qirg mailing list

[email-masked]

https://www.irtf.org/mailman/listinfo/qirg

_______________________________________________
Qirg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/qirg