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

[Wojciech Kozlowski <[e-mail]>]

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
> [e-mail]
> 
> 
> 
> _______________________________________________
> Qirg mailing list
> [e-mail]
> 
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.