Subject: Re: [Qirg] comments on the principles draft

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 3 Feb 2020 23:58:05 +0000

Hi Rod,

I've addressed most of your comments up to the goals/principles section since
that still needs reworking.

Apart from the small additional remarks from me below inline, there is the
question of quantum repeater generations.

I wrote the draft with only first generation quantum repeaters in mind, but you
make a good point that three generations have been defined in academic
literature. I've given this some thought and I think that in this document
it's best to just focus on the first generation networks, because they're the
ones being currently built. I prefer to do this, because whilst this draft is
obviously a bit ahead of what is currently achievable, it's not _too far_ ahead
(2021 according to current plans for the Dutch network). Including the other
two generations will put this document further into the future than I would
like it to be. 

It is, however, a very good point - perhaps we should schedule a specific 10-15 
minute slot at the next meeting to introduce this concept (I'm working on the
assumption most people don't remember details from your general intro in
Prague) and ask for opinions on how to deal with it (wait for them to happen or
already start including them in working documents).

Cheers,
Wojtek

On Tue, 2019-10-29 at 15:27 +0900, Rodney Van Meter wrote:
> Sec. 1:
> 
> Last sentence mentions "forwarding".  We should probably move to cut
> off any thought of store-and-forward as early as possible.

[WK] Good point - changed to transmitting

> 
> Sec. 2:
> 
> This is mostly good background material on quantum.  I think maybe the
> title is wrong.
> 
> I think I would move the discussion of Bell pairs and no-cloning to
> this section, and possibly even teleportation.
> 
> I'm not sure yet whether distilation/purification and QEC belong here
> or later...
> 

[WK] Renamed to "Quantum information", but open to other suggestions. I kept
the other material (disitallation/swapping etc.) where it was as I like the
current flow of information, but as usual open to moving things around if
others feel it would help.

> Sec. 3:
> 
> The statement
> "It is impossible to entangle two qubits without ever having them
>    directly interact with each other (e.g. by performing a local two-
>    qubit gate, such as the CNOT)."
> is misleading.
> 
> Entanglement swapping, in fact, creates entanglement between two
> qubits that have never been anywhere near each other; that's kind of
> the point.  It's mentioned explicitly somewhere, either in the
> original entanglement swapping paper or one of the early repeater
> papers.
> 
> How about:
> 
> Entanglement is created via certain quantum effects when two qubits
> are brought together (or, in the case of some entangled photon pairs,
> when the photon pair is created).  Distributed entangled states can be
> made larger or extended over a distance by interacting two qubits that
> are each part of an entangled state.

[WK] Very good point - I used some of your words and added mine to the mix.

> 
> Sec. 4:
> 
> This section seems to back into the challenges of quantum and
> differences from classical.  Maybe there should be more at the front
> of this section?
> 
> The outline of this section doesn't seem well balanced:
> 
>    4.  Achieving quantum connectivity  . . . . . . . . . . . . . . .   7
>      4.1.  No-cloning theorem  . . . . . . . . . . . . . . . . . . .   7
>      4.2.  Direct transmission . . . . . . . . . . . . . . . . . . .   7
>      4.3.  Bell pairs and entanglement swapping  . . . . . . . . . .   8
>        4.3.1.  Bell Pairs  . . . . . . . . . . . . . . . . . . . . .   8
>        4.3.2.  Teleportation . . . . . . . . . . . . . . . . . . . .   8
>        4.3.3.  Bell Pair links and entanglement swapping . . . . . .   9
>        4.3.4.  Distillation  . . . . . . . . . . . . . . . . . . . .  10
>      4.4.  Direct transmission vs. swapping  . . . . . . . . . . . .  10
> 
> 
> I think I'd recommend something more like:
> 
> 4. Achieving quantum connectivity
> 4.1 Challenges
>     (loss, gate errors, decoherence; no-cloning as a limitation)
> 4.2 Entanglement swapping
>     (I think I'd make direct v. swapping a subsection here)
> 4.3 Managing state errors
>     (purification/distillation, QEC)

[WK] I have restructured this section based on your feedback - not exactly as
you suggested, but it is closer to it than it was before.

> 
> Distillation:  I revised this paragraph.  Let me know what you think.
> It might have gotten too long:
> 
> Error Detection and Correction
> 
> Neither the generation of Bell Pairs nor the swapping operations are
> noiseless operations.  Therefore, with each link and each swap the
> fidelity (quality) of the state degrades.  However, it is possible to
> create higher quality Bell Pair states from two or more lower quality
> Bell Pair states through a process called distillation or
> purification, or via quantum error correction.
> 
> To purify a quantum state, a second (and sometimes third) quantum
> state is used as a "test tool" to test a proposition about the first
> state, e.g., "the parity of the first state is even."  When the test
> succeeds, confidence in the state is improved, and software records
> improved fidelity.  The test tool states are destroyed in the process,
> so resource demands increase substantially when purification is used.
> When the test fails, the tested state must also be discarded.  [Dur,
> Briegel, RPP 2007] Purification makes low demands on fidelity and
> resources, but distributed protocols incur round-trip delays, hence
> are known as two-way entanglement purification protocols (2-EPP)
> [https://arxiv.org/abs/quant-ph/9604024]
> 
> Quantum error correction (QEC) makes very high demands on both
> resources (Bell pairs consumed) and their initial fidelity [Devitt,
> QEC for beginners].  Schemes may be derived either from classical
> codes, or purely quantum ideas.  They allow one-way entanglement
> purification (1-EPP), hence are well suited to store-and-forward
> operation, but implementation is very challenging and QEC is not
> expected to be used until later generations of quantum networks.

[WK] I split QEC and distillation apart (see my comments on quantum network
generations), but included what you said.

> 
> Sec. 5:
> 
> I don't think quantum repeater is well defined here, and I think it
> should be.  I always use the following four roles to describe what a
> repeater's responsibilities are:
> 
> 1. Making base-level entanglement with neighboring nodes
> 2. Managing errors (over both links and longer paths)
> 3. Extending entanglement from single hops to reach end-to-end
> 4. Participating in management of the network (routing, etc.)
> 
> Perhaps we should add something like that?
> 

[WK] Done

> Since this is IRTF, we need to be careful here about the distinction
> between a network and an internetwork.
> 

[WK] Done

> Principle #8: This is fairly inflexible language, saying that
> "pre-allocation" of resources will be necessary.  I think it's likely
> that some sort of reservation system will be required in the earliest
> networks, but I don't think it is inevitable that all networks for all
> time will use them.  One of our early papers
> (https://spie.org/Publications/Proceedings/Paper/10.1117/12.893272?SSO=1)
> investigated various multiplexing regimes assuming tens of qubits per
> interface, and we found that statistical muxing (like IP packets)
> actually works pretty well.  (I believe that paper to represent the
> first simulation of a quantum repeater *network*, as opposed to a
> linear chain of repeaters.)  However, that was in a few limited
> settings.
> 
> Circuit/connection setup I think is necessary because of the need to
> coordinate the distributed computation of swapping and purification.
> I think it's likely that something like RSVP will be used to reserve
> those resources, as well, but I don't think we should specifically
> exclude systems without reservations.
> 
> In short, I think the language here should be more flexible.
> 
> Sec. 6:
> 
> This focuses only on security of a connection, in terms of
> authenticity, confidentiality and integrity.  Another key concern is
> availability and correction operation of the network itself; indeed,
> it could be argued that this is more important for network operations
> than what amounts to end-to-end application concerns.
> 
> [I don't want to get into pushing, "We did this, we did that," for
> everything; it's not healthy for the group.  But my group has done
> work recently on this exact topic:
> https://iopscience.iop.org/article/10.1088/2058-9565/aac11f/meta
> ]
> 
> It's probably also a good idea to note that anything we write about
> security is preliminary and is not intended to be comprehensive.  Or
> is that adequately implied in the status of this memo altogether?

[WK] These later sections, I'm leaving for now as they need reworking anyway.

> 
> 
> 
> -----------------------
> 
> Other general comments:
> 
> * although the Muralidharan-Jiang taxonomy is cited, the three
>   proposed generations and the stages of development from Stephanie's
>   Science article.  Both are definitely relevant to a document on
>   architectural principles; should we invest effort in recapping
>   those, or not?

[WK] See comments at the beginning of e-mail

> 
> * latency is mentioned only once in the document; seems like it should
>   probably receive more attention, though I'm not yet sure where.

[WK] This is a good point. Having thought about it, this is essentially a
consequence of memory lifetimes so I added a small mention there. Given that
memory lifetime is the key factor I think this should be enough, but I can
incorporate more latency material if needed.

> * although there are good arguments about whether or not they are
>   viable, all-optical repeaters aren't mentioned and I'm not sure how
>   they fit into this framework.
> 

[WK] See comments at beginning of e-mail.

> --------------------------
> 

Minor wordsmithing:
> 
> 5.3.2:
> 
> List of principles:
> 
> 1-3 are statements
> 4 isn't a statement
> 5-8 are commandments
> 
> they should be regularized
> 

[WK] Also haven't touched these since it's in the sections that still need
reworking.

> 
> references:
> 
> [11] Should be "Van Meter, R.", not "Meter, R."

[WK] Fixed

---

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 4 Feb 2020 00:00:13 +0000

Sorry for spam, forgot to add links:

Diff for this changeset: 
https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/8a454629f85ab6e9eb71f123d0d31eb6569be534

Latest version: 
https://github.com/Wojtek242/draft-irtf-qirg-principles/blob/master/draft-irtf-qirg-principles-03.txt

On Mon, 2020-02-03 at 23:58 +0000, Wojciech Kozlowski wrote:
> > [
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_quant-2Dph_9604024&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=KdshCgd8PfY1tn-8vmTnifJHB5uHynGijureLwG8Ap4&s=bAdnMqgczo36zmmUPh5ohqFN4TmHksRQzaAGIsHdsws&e=
> >  ]
> > 
> > (
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__spie.org_Publications_Proceedings_Paper_10.1117_12.893272-3FSSO-3D1&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=KdshCgd8PfY1tn-8vmTnifJHB5uHynGijureLwG8Ap4&s=te8gS90Ie3Ynk9-yukj20xnobFy8WNu0nVZkY8_JWQc&e=
> >  )
https://urldefense.proofpoint.com/v2/url?u=https-3A__iopscience.iop.org_article_10.1088_2058-2D9565_aac11f_meta&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=KdshCgd8PfY1tn-8vmTnifJHB5uHynGijureLwG8Ap4&s=U-xlbVb2bu9EaE5Q3Wtuwaj8clPSEQIt1TSs4zUVe3A&e=
> _______________________________________________
> Qirg mailing list
> [email-masked]
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=KdshCgd8PfY1tn-8vmTnifJHB5uHynGijureLwG8Ap4&s=RhCc-kmY8SDYI04t2jjtPlkbpZv0CqKi7It0LkVVrxw&e=