Subject: Re: [Qirg] arch I-D: pull request & comments

From: Wojciech Kozlowski <[email-masked]>
Date: Sun, 12 Jul 2020 21:33:40 +0000

Hi Rodney

So finally got around to addressing your comments. See in-inline.

Note that I actually had two e-mails from you in the pipeline. Since some
points were raised in both e-mails I simply appended the older e-mail at the
bottom and also addressed the comments in-line.

Cheers,
Wojtek

On Tue, 2020-05-19 at 15:09 +0900, Rodney Van Meter wrote:
> <chair hat off>
> <individual contributor hat on>
> 
> Wojtek et al.,
> 
> A pull request for the architecture I-D awaits you at
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_7&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=uAPhFtt4Jag1SImLOB-xdnvE4wqgUKfhwulYKnRNffI&e=
>  
> (I didn't generate the .txt from it, I figure it's generally better
> for such generated files that are stored in git to be managed at one
> node.)
> 
> I went through the I-D and made a number of small changes; I doubt
> anything will need discussion but please check.  Almost all edits are
> for clarity, spelling or grammar.  I modified the Muralidharan
> reference to the right "generations" paper, and I added Sutor as a
> reference for beginners.  (I really do think that's an excellent
> beginner's book on quantum computing, with the dead-minimum
> assumptions of background in CS, math and physics, as opposed to Mike
> & Ike, which can be a steep climb.)

PR was accepted

> 
> A number of things occured to me while reading, some of which we've
> probably covered before:
> 
> 1. My memory fails me -- in the section on network boundaries, we
> previously had a discussion of how much to cover the different types
> of logical networks (1G, 2G, 3G), didn't we?  What did we decide?
> Personally, I think it's _critical_ in a document like this, intended
> to be long-lived and set the direction for the network architecture,
> to acknowledge that not only are there physical differences and
> administrative boundaries, but there are important distinctions in how
> errors will be managed, which affects the content and semantics of
> messages that must cross those boundaries, as well -- both for
> connection setup and real-time operation.

This has been included through w PRs from Shota. See latest doc version now.

> 
> 2. Assessment of fidelity is a statistical thing, requiring constant
> monitoring and the sacrifice of generated Bell pairs for tomography or
> other methods.  Should we clarify this?  At the moment, fidelity is
> mentioned but where it comes from is not.

Added the clarification.

> 
> 3. Mentions QKD as depending on Bell pairs, which is not exactly true for
> BB84.  Also, E91 and BBM92 are probably worth citing as better
> instances of entanglement-based QKD.

Good point. Cited Ekert paper, but didn't explain it in words as I'm worried it
might detract from the main point of the text.

> 
> 4. This (and some of the surrounding paragraphs) needs work:
> 
>            It turns out that as long as the underlying implementation
>            corresponds to (or sufficiently approximates) theoretical models
> of
>            quantum cryptography, quantum cryptographic protocols do not need
>            the network to provide any guarantees about the authenticity,
>            confidentiality, or integrity of the transmitted qubits or the
>            generated entanglement. Instead, applications, such as QKD,
>            establish such guarantees using the classical network in
> conjunction
>            with he quantum one. This is much easier than demanding that the
>            network deliver secure entanglement in the first place.
>            <vspace blankLines="1" />
> 
> This could cite Satoh on quantum network security; AFAIK, our work on
> the security of repeater network operation remains the world's only
> work on the topic.  One or both of
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1701.04587&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=LVu3oWfp0WCPG46t-AAs2zgGy6PC0bBYt8ACKAlYI_U&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_2005.04617&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=8Fs-dOf5B_umAIwmL81kWTqHlgTVOc7-MUva1m7T2LA&e=

Done, both refs included.

> 5. We have discussed Bell pairs as the primary service provided by the
> network, but it may be worth mentioning that multi-party states are
> useful, and may be generated either by applications operating
> end-to-end or by the network itself as a service.  There are a number
> of uses of multi-party states documented in the literature, but only
> Clement, Damian and Frederic Grosshans on how to create them, I
> think.
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__link.aps.org_doi_10.1103_PhysRevA.100.052333&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=P3uNxsyWPSV-AyvZllHG0VcKmtDmxpLzOuLqLrKrs-8&e=

Done

> 6. "shortest path" is undefined here.  Again, work of ours is
> relevant: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1206.5655&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=5CZHrVvCzrqIE5WlMt53hX0WAA0H7gTARE-g4zWoR3Y&e=
>  
> 

In what sense is "shortest path" undefined. Could you elaborate?

> 7. In discussion of rule-based operation, again, work of ours is
> relevant: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1904.08605&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=RZE6ErezqKuvt7bPhzr6A7xV3ilHq0krX0EcYpQyadA&e=
>  
> (I _know_ it sounds like I'm citing "cite me" a lot, but this _is_ the
> field we have been working for over a decade to establish, and we've
> covered a lot of ground in that time, and my students and postdocs
> deserve some recognition for the work they have done that is, or
> should be, influencing these documents and designs.)
> 

Not sure where to insert the ref though. If you could point out a location or
submit a PR that would be great.

> 8. The use of "control plane" and "data plane" here might differ a bit
> from standard networking use.  "Control plane" usual refers to routing
> and management traffic, path setup for MPLS, etc. but here it refers
> to soft real-time messages that are part of the entangled state
> creation process, essentially the equivalent of packet headers and
> SYNs and ACKs in TCP/IP.  I'd argue that's closer to data plane than
> control plane.

I 100% agree with this point, but I'm not sure if this point needs clarifying
in this doc. We actually do not define a control/data plane split in this doc.

> 
> I don't think the document is close to ready for last call yet, but it
> has made a lot of progress.  I think we can put serious discussion of
> the document onto the agenda for July, with the hopes of publishing
> soon after.
> 
> —Rod
> 
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies
> Keio University, Japan
> [email-masked]
> 
> 
> 
> _______________________________________________
> Qirg mailing list
> [email-masked]
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=wxv8uRZVSeFyskfYTA2SKnUDIBhmcXehDoaOqFQKLh0&e=

On Fri, 2020-03-06 at 09:17 +0900, Rodney Van Meter wrote:
> Wojtek,
> 
> About two weeks ago, I started working on a list of things I’d like to see in
> the draft, but I’m afraid I’m not going to be able to turn them into text and
> an actual pull request by Monday. My apologies.  A few are absolute nits, a
> few are rather big.
> 
> Put these on your TODO list, and maybe we can find time to work on them
> together F2F sometime during the week in Vancouver?
> 
> Comments for Wojtek on QIRG architecture I-D:
> 
> * overall, the flow and structure are much better than -00. I
>   particularly like 6.2 now, though I'm not sure it's finished yet.
> * additional refs:
>   - Dur group (Pirker, Zwerger)
>   - (more stuff from us, e.g. my book?)
>   - Kimble
>   - Mark Wilde
>   - Jones on links?
>   - all-optical?
>   - triangle inequality for routing
>   - Riefel
>   - Simon on QEC
>   - Dur review of purification
>   - distributed algorithm zoo
>   - something from Pan?
>   - Broadbent
>   - Gottesman
>   - Wootters, Park, Ortigoso on no-cloning

References are still TODO. Hopefully the last TODO.

> * needs a little wordsmithing here and there at some point

Generally addressed through all the fixes since this e-mail.

> * security needs work

Language slightly improved, but let me know if you would like to see some more
substantial changes.

> * needs to talk about logical differences at network boundaries
>   (differences in error management parallels the other two very well)
> * should cover 1G, 2G, 3G

Both points are now addressed under "Error management" and in network
boundaries section thanks to Shota's PR.

> * "support tomorrow's dist q apps" is time-sensitive, and why
>   is it different from the apps just above it?

This point is addressed as goal/principles have been rewritten.

> * does doc accommodate all-optical links or paths?

Not at the moment. Do you think it should? What would you propose?

> * does doc describe 1G as a distributed computation?
>   - important corollary: state along the path v. stateless forwarding
>   - equally important corollary: resource reservation/multiplexing

The "Comparison to classical networks" section does mention "stateful
distributed task". This section does cover your two corollaries as well.

> * just a shade more on apps, as parallel I-D is developing

This will be in use-case doc which is now cited.

> * describe time-skewed Bell pairs

I don't know what this is. Could you elaborate?

> * "Therefore, we cannot use the same methods known from
>    classical computing for the purposes of error detection and
>    correction." ==> without modification, though both codes derived
>    from classical and wholy unique to quantum are known (cite Simon?)
>   Overall, this paragraph needs work to be both more accurate and
>   clearer.
>   reconcile w/ later ACK that QEC exists

Done

> * "through a variety of checksums" -- not entirely accurate.
>   how about "through both error detection and error correction mechanisms"?

Done

> * section on direct transmission needs work
>   --> make it a subsection of 4.1, titled "inadequacy of direct
>       transmission"?

Done

> * "challenges" v. "new challenges" is awkward

Fixed, by just having "challenges". Though admittedly some creativity in section titles would not hurt.

> * use the name "Dirac's ket notation"
>   (makes it easier for neophytes to find)

Done

> * expand CNOT first time it's used

Done (in your PR I believe)

> * connection architecture v. network architecture

I've though about this, but I don't think this is material for this draft.
Connection architecture is getting close to specific protocols.

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 15 Jul 2020 08:03:29 +0900

Rodney Van Meter

(trimmed to just open questions)

> On Jul 13, 2020, at 6:33, Wojciech Kozlowski <[email-masked]> wrote:
> 

OSPF deliberately treats link cost as a unitless scalar, allowing any network operator to use the cost to establish policy as they choose. However, a common goal is minimization of the workload of the entire network, so that resources are used efficiently. This can be achieved, at least approximately, by setting the link cost relative to the bandwidth — using a high-bandwidth link is “cheaper”.  (Note that even though we call it “shortest path”, it’s not shortest in distance or even in the latency you would see on an otherwise idle network, though it may come close to minimizing latency on a heavily loaded network.)

Without some discussion, we have no concept of what “shortest” or “cheapest” means in a quantum network.  We defined a goal of the network to be maximizing the throughhput, measured in Bell pairs per second *of a particular fidelity*, then chose a meaning for the link metric (seconds per Bell pair of a particular fidelity) and evaluated how good a job simple summation of per-hop metrics does in maximizing that E2E throughput.  (Pretty good, as it turns out.)

So of course SPF continues to function as an abstract mathematical thing, but operationally what are the goals of _using_ SPF and how do we achieve it?

Maybe that’s a separate or secondary document in terms of analysis, but I think it’s an open question that needs to be addressed.

> submit a PR that would be great.

Mmm, back when I wrote this, I had somewhere in mind, but that’s long gone from my mind now…

> in this doc. We actually do not define a control/data plane split in this doc.

“control” or “control information” and “the two planes” are used a *lot* in this document, but I’m worried that the usage here differs enough from e.g. SDF control plane or routing and management traffic that it will confuse people. You wouldn’t call a TCP ACK “control plane information”, so is it right to call entanglement success/failure messages “control plane”?  Is there another term we can use?  I don’t have a good suggestion this morning…

> Language slightly improved, but let me know if you would like to see some more

Will check.

> I don't know what this is. Could you elaborate?

Some people (e.g. Bill Munro — Bill, are you lurking on this mailing list?) worry about the philosophical implications of *when* the two halves of the Bell pair arrive at the destination.  If the network is building a Bell pair between you and me, and my half arrives 10msec before yours, and I measure my half before yours even arrives, did we ever really have entanglement between the two of us?  Mostly it’s a philosophical point, I think, but it can affect loophole proofs.

Keep this one on your list for later; I’m not ready to discard it but don’t think it needs to be done right away.  May decide to discard att some point, though.

Oops, there was a question about all-optical here that I deleted in editing…

Keep “review for whether all-optical is excluded by the language” on your TODO list before we finalize things.

This email is written before I’ve completely read the -04 draft, so I may have more comments by the time of the meeting.

—Rod