Re: [Qirg] Review of draft-irtf-qirg-principles-02

[Rodney Van Meter <[e-mail]>]

Mathias, thanks for the feedback!  Much appreciated.  We’ll make sure the comments get addressed.

We definitely want to keep all-photonic implementations in the loop.

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[e-mail]



> On Dec 12, 2019, at 22:39, Gelard Patrick <[e-mail]> wrote:
> 
> Hello Mathias,
>  
> Proposal/Question: 
>  
> The title could be _4.4.1 _Elementary link generation_ instead.
>  
> The expected contribution should include at least 3 main parts
> * Create the BPS
> * Store the entangled members of non-local BPS
> * Monitor the entanglement resource level on each link
>  
> Explanation
> The other aspects of entanglement life cycle are well described
> in the subsequent sections, it looks like this one is dedicated
> to elementary links, right?
> Everyone will have in mind the function to create BPS across the
> elementary links, but we should first not forget the fact that
> they need be stored (esp. in the light of the asynchronous use
> mentioned further in the document). And then this stored entanglement
> will be the resource to be monitored on each elementary link,
> because it will be consumed and it will expire (by decoherence).
> Monitoring will detect low levels and trigger regeneration.
>  
> Can we agree on that before developing further?
>  
> Discussion:
>  
> Doesn't that close the door of all-photonic quantum “repeater” : https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201907sr3.html <https://www.ntt-review.jp/archive/ntttechnical.php?contents=ntr201907sr3.html> - Experimental quantum repeater without quantum memory : https://www.nature.com/articles/s41566-019-0468-5 <https://www.nature.com/articles/s41566-019-0468-5>?
> Quantum repeaters—important components of a scalable quantum internet—enable entanglement to be distributed over long distances. The standard paradigm for a quantum repeater relies on the necessary, demanding requirement of quantum memory. Despite significant progress, the limited performance of quantum memory means that making practical quantum repeaters remains a challenge. Remarkably, a proposed all-photonic quantum repeater avoids the need for quantum memory by harnessing the graph states in the repeater nodes. Here we perform an experimental demonstration of an all-photonic quantum repeater.
>  
> Rodney Van Meter wrote : An interesting question is whether nodes can be transmit-only, without memory.
>  
> A+
> /Patrick
>  
> De : Qirg <[e-mail]> De la part de VAN DEN BOSSCHE Mathias
> Envoyé : lundi 9 décembre 2019 10:49
> À : [e-mail]
> Objet : [Qirg] Review of draft-irtf-qirg-principles-02
>  
> Dear all, 
>  
> I did some review work of draft-irtf-qirg-principles-02. The document is really well done, and the effort to
> non quantum readers is visible (and appreciated, even by a QFT-background guy like me).
>  
> I introduce below (in basic ascii mode) a number of proposed changes/comments/questions to be discussed.
> Some are typos, some a clarifications, few are more fundamental.
> The idea is to fill the ‘Discussion’ and ‘Decision’ fields for each point.
>  
> I let you go through it. We could maybe set a date to close this.
>  
> All the best !
>  
> Mathias
>  
>  
> ====
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 01
>  
> Page/section: p 6/ § 3
>  
> Proposal/Question: 
> I would change the title of §3 to _Entanglement as the
> fundamental resource_
>  
> Explanation: 
> The fact is that a service is an action, while a resource
> is something you can create, quantify and manage. There is
> a targeted service is to "distribute entanglement". BTW
> the document mentions entanglement as a resource §§ 4.4.2.1
> and 5.6.1, so that would improve consistency.
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 02
>  
> Page/section: p 7/ § 3
>  
> Proposal/Question: 
> than -> then line 9 of p 7
>  
> Explanation: 
> typo
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 03
>  
> Page/section: p 9/ § 4.2
>  
> Proposal/Question: 
> change
> Any of the four Bell pair state above will do as it is
> possible ....
> to
> Any of the four Bell-pair states above will do, as it
> is possible ....
>  
> Explanation: 
> typo + some clarity
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 04
>  
> Page/section: p 10 / § 4.3 (last 3 lines)
>  
>  
> Proposal/Question: 
>  
> change
> The unknown quantum state that was transmitted never entered the
> network itself. Therefore, the network needs to only be able to
> reliably produce Bell pairs between any two nodes in the network.
>  
> to
> change
> The unknown quantum state that was transmitted was never fed into
> network itself. Therefore, the network needs to only be able to
> reliably produce Bell pairs between any two nodes in the network,
> and perform BSM with external qbits to be transmitted.
>  
> Explanation: 
> * It is a delicate concept to explain that the network is here only
> to create a direct end-to-end link, which is then used directly
> by the end nodes without having the intermediate nodes to handle it.
> * The interface function (the BSM with external qbits) I think is
> still part of the network and should not be forgotten
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 05
>  
> Page/section: p 10 / § 4.4.1 
>  
> Proposal/Question:  
>  
> The title could be _4.4.1 _Elementary link generation_ instead.
>  
> The expected contribution should include at least 3 main parts
> * Create the BPS
> * Store the entangled members of non-local BPS
> * Monitor the entanglement resource level on each link
>  
> Explanation
> The other aspects of entanglement life cycle are well described
> in the subsequent sections, it looks like this one is dedicated
> to elementary links, right?
> Everyone will have in mind the function to create BPS across the
> elementary links, but we should first not forget the fact that
> they need be stored (esp. in the light of the asynchronous use
> mentioned further in the document). And then this stored entanglement
> will be the resource to be monitored on each elementary link,
> because it will be consumed and it will expire (by decoherence).
> Monitoring will detect low levels and trigger regeneration.
>  
> Can we agree on that before developing further?
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 07
>  
> Page/section: p 11 / § 4.4.2 
>  
> Proposal/Question: 
>  
> Augment 
>  
> The problem with generating entangled pairs directly across a link is
> that its efficiency decreases with its length. Beyond a few 10s of
> kms the rate is effectively zero and due to the no-cloning theorem we
> cannot simply amplify the signal. The solution is entanglement
> swapping.
>  
> with 
>  
> The problem with generating entangled pairs directly across a link is
> that its efficiency decreases with its length. Beyond a few 10s of
> kms in optical fibre or 1000s of kms in free space [ESA, Micius], the
> rate is effectively zero and due to the no-cloning theorem we cannot
> simply amplify the signal. The solution to propagate entanglement at
> large distances is entanglement swapping.
>  
> Explanation:
>  
> The two kinds of links (fibre & free space) shall be mentioned for
> completeness. They are not competing, rather complementary, and both
> will require swapping and routing devices anyway. Free-space to satellites
> will allow having fewer nodes on the path, the goal being to improve
> capacity. 
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 08
>  
> Page/section: p 12 / § 4.4.2 
>  
> Proposal/Question: 
>  
> Add at the end of the section:
> << 
> Entanglement swapping allows entanglement to exist at larger distances
> than what the entangled degrees of freedom can propagate. Yet one should
> keep in mind that the capacity of the network still decreases with the
> number of swapping nodes (all other parameters being kept fixed). So
> entanglement swapping solves the problem of existence of long distance
> entanglement, but not that of performance of the end-to-end link.
> >> 
>  
> Explanation:
> This 
> - clarifies the role of entanglement swapping in the network as a system
> - allows identifying different way of attacking the problem of performance.
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 09
>  
> Page/section: p 12 / § 4.4.2.2 
>  
> Proposal/Question: 
>  
> Change 
>  
> 2. An identifier that allows the application to unambiguously
> determine which qubits at the two end-points belong to which
> entangled pair.
>  
> to
>  
> 2. An identifier that allows the applicatqion to unambiguously
> determine which qubits at the two end-points belong to which
> entangled pair (including end-point identification).
>  
>  
> Explanation:
> For more clarity
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 10
>  
> Page/section: p 12 / § 4.4.2.2 
>  
> Proposal/Question: 
>  
> Add
>  
> 4. An estimate of the expiry date of the BSP.
>  
> Explanation:
>  
> It might not be relevant in the first networks where decoherence
> will require fast consumption of the created entanglement resource,
> but we hope that this constraint will be relaxed, and that this
> will become a relevant network management information.
>  
> Alternatively create a §4.4.2...3 on entanglement storage
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 11
>  
> Page/section: p 13ff / § 5 
>  
> Proposal/Question: 
>  
> From that point on, the document mentions abundantly the term of
> 'repeaters'. I recommend to give it up and use a more accurate term
> such as swapper or router (that are introduced in the document) or
> propagator (that's my QFT background).
>  
> Explanation
>  
> I know the term is pretty much used already, but here is my argument.
>  
> Although it is a convenient term for those who have a classical
> network background (where it is fairly transparent), it is abusive
> in the case of entanglement networks. The fact is that nothing is
> repeated, it is just blank entanglement that is forwarded, swapped,
> propagated commuted (as in the old telephone systems where an operator
> had to plug a wire between two lines nodes to connect two network
> segments and allow an end-to-end line to exist). It repeats no data
> (as the considerations at the end of the document insist on).
>  
> Using the term of repeater is confusing, and leads to wrong understanding
> and then inadequate decisions. 
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 12
>  
> Page/section: p 14 / § 5.1 (3.) 
>  
> Proposal/Question: 
>  
> Change 
>  
> This implies ... store temporary state as the ...
>  
> to 
>  
> This implies ... store the received temporary state as the ...
>  
> Explanation:
>  
> If I understand the sentence right.
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 14
>  
> Page/section: p 18 / § 5.5.1  
>  
> Proposal/Question: 
>  
> Change
>  
> "The memory lifetime depends on the particular physical setup, but the
> highest achievable values currently are on the order of seconds."
>  
> to
>  
> "The memory lifetime depends on the particular physical setup. This
> is object of intense research. Current setups achieve lifetime
> up to the order of seconds, but promising approaches should allow a
> significant expansion of this value"
>  
> Explanation:
>  
> I came across a paper [Nature _517_, 177 (2015)]  that claimed
> 6h coherence time with Europium ion spins that are "optically addressable".
> Since I am no experimentalist, I do not know what intricacies this
> setup might require. I do not know either whether this result is
> object of controversy. But if this is not the case, I would suggest
> changing the text to something less hard on memory lifetimes.
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 15
>  
> Page/section: p 18 (and 19) / § 5.5.1 (and 5.5.2) 
>  
> Proposal/Question: 
>  
> Explain why it might be more cost efficient to use short lifetimes.
>  
> Explanation:
>  
> It might be a valid choice, but it deserves motivation. Do not
> forget that anything expensive produced in mass figures becomes
> inexpensive. 
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 16
>  
> Page/section: p 18 / § 5.5.2
>  
> Proposal/Question: 
>  
> It is not clear what the mentioned success rate of 1e-3 addresses.
> I understand it is the rate of success to create a BPS by pumping
> a non-linear crystal with a suitable pump. Is it this? Or is it
> the probability that BSM effectively entangles 2 BPS? Or is it
> something else? 
>  
> It is tempting with this figure to compute the capacity of an
> n-hop path. But is they the correct needed information?
>  
> Explanation:
>  
> See above
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 17
>  
> Page/section: p 21 / § 5.6.1 (5.) 
>  
> Proposal/Question: 
>  
> I propose to remove the considerations on QKD, or at least
> to reduce them drastically.
>  
> Explanation:
>  
> There might be other solutions to secure the control plane other
> than QKD. It is true that once optical links are available, it
> is tempting to implement QKD protocols, but is it the right moment
> to highlight a particular solution? 
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 18
>  
> Page/section: p 22 / § 5.6.2 (3.) 
>  
> Proposal/Question:
>  
> Change  
>  
> "This point is crucial in enabling the reuse of resources of a
> network and (...)"
>  
> to 
>  
> "This point is crucial in optimising the use of entanglement
> resources of a network and (...)"
>  
> Explanation:
>  
> If I understand right, this is clearer.
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 19
>  
> Page/section: p 24 / § 5.6.2 (6.) 
>  
> Proposal/Question:
>  
> Question : do you consider parallelising over the same path with
> e.g. multiplexed optical channels, or do you consider also
> parallelising over different paths? In which case it could be
> mentioned.
>  
> Explanation:
>  
> N/A
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 20
>  
> Page/section: p 24 / § 5.6.2 (7.) 
>  
> Proposal/Question:
>  
> I would suggest giving synchronisation accuracy needs here.
> Not necessarily the figure but a least the relationship
> with the source rate etc. 
>  
> Explanation:
>  
> This would allow assessing what is feasible and what is not.
> At some point, synchronisation may be much more demanding than
> what you can do with GNSS (~ 0.1 ns). As a matter of fact, the
> network its might become itself a big machine to measure the
> metric of space time on Earth.....
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> ---
>  
> Doc: draft-irtf-qirg-principles-02
>  
> ID : MVDB 21
> Page/section: p 24 / § 6  
>  
> Proposal/Question:
>  
> Change 
>  
> "Even though no user data enters a quantum network security is listed
> as an explicit goal (...)"
>  
> to 
>  
>  
> "Even though no user data enters a quantum network, security is listed
> as an explicit goal (...)"
>  
> Explanation:
>  
> Typo
>  
> Discussion: 
>  
> TBD
>  
> Decision: 
>  
> TBD
>  
> [@@ THALES ALENIA SPACE INTERNAL @@]
>  
> _______________________________________________
> Qirg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/qirg