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

From: Wojciech Kozlowski <[email-masked]>
Date: Fri, 1 Nov 2019 18:32:12 +0000

Thanks for the feedback!

I have just updated sections 4 and 5 (and just sent out an e-mail about
it). I have tried to include your feedback on those sections. I did use
your update to the distillation section. I have sort of split the QECC
to be separate from the distillation as it fit the flow I had better.
Let me know what you think of that. I can always re-add the QECC
discussion to be with the distillation again. I also filtered out some
technical terms that weren't used later in the text (but left the
reference).

I did get your e-mail after I already finished section 5 so I actually
didn't include your point for that section, but I do like it. Perhaps
on the next iteration. It relates to our layer discussion we had on the
last call so it would definitely be good to include.

For the other sections - I agree with a lot of it, but I have not
included any of that feedback yet. I'm pretty sure we should discuss
the two lists at the end separately anyway.

Thanks,
Wojtek

On Tue, 2019-10-29 at 15:27 +0900, Rodney Van Meter wrote:
> Wojciech et al.,
> 
> I finally managed to give this draft a solid dose of attention.  It's
> important, and overall it's well written, so I'm happy that it looks
> likely to be the first output of the group.
> 
> I'm unfortunately a kitchen sink kinda guy, so my inclination is
> always to throw in more than is really advisable.  Feel free to push
> back on any proposed addition.
> 
> Comments:
> 
> Sec. 1:
> 
> Last sentence mentions "forwarding".  We should probably move to cut
> off any thought of store-and-forward as early as possible.
> 
> 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...
> 
> 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.
> 
> 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)
> 
> 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.
> 
> 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?
> 
> Since this is IRTF, we need to be careful here about the distinction
> between a network and an internetwork.
> 
> 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?
> 
> 
> 
> -----------------------
> 
> 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?
> * latency is mentioned only once in the document; seems like it
> should
>   probably receive more attention, though I'm not yet sure where.
> * 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.
> 
> --------------------------
> 
> 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
> 
> 
> references:
> 
> [11] Should be "Van Meter, R.", not "Meter, R."
> 
> 
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies
> Keio University, Japan
> [email-masked]
> 
> 
> 
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg