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

[Akbar Rahman <[e-mail]>]

Hi Rodney/Wojtek,


I have one question:

- In section 5.3.2 and section 8 of the current draft-irtf-qirg-principles-03 it states that "no user data enters a quantum network" or a similar phrase.   I believe this statement also requires clarification in terms of the data plane vs control plane comment number (8) in your email chain below.  Specifically, data plane in telecom usually refers to carrying user data as well as protocol overhead such as ACKs and SYNs.  So it seems confusing to state that "no user data enters a quantum network" and then talk about a data plane.  I recommend removing the references to "no user data enters a quantum network" from the draft or else clarifying the basic definition of what you mean by quantum networks.



Best Regards,


Akbar


-----Original Message-----
From: Qirg <[e-mail]> On Behalf Of Wojciech Kozlowski
Sent: Tuesday, May 19, 2020 9:29 AM
To: [e-mail]
Subject: Re: [Qirg] arch I-D: pull request & comments

Responses in-line. I am going to put items that require action from me on top of the TODO items from your 6 March e-mail to handle after updating section 6 which will hopefully be next month.

More details in-line. No comment means I fully agree with your point and have nothing to add.

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.)

Thanks! Pretty straightforward. Merged.

>
> 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.

Shota has submitted a PR about generations which I've been currently withholding until it becomes clearer what is expected from this section and we had a bit of a discussion on the mailing list. In general, I agree. We should add something about generations and what defines them to the draft. The current state of this PR is here:
https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6/files

I have not reviewed that PR yet, but I have already mentioned what I would like to see in this section (see
https://mailarchive.ietf.org/arch/msg/qirg/b87SUszyuj5sXI1twDiEuX3F9oY/)

Feel free to add your thoughts either in the PR or on the mailing list.

>
> 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.
>

I think clarifying the difficulties around fidelity would be valuable. Will add something once I sort out section 6.

> 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.
>
> 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=
>
>
> 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=
>
>
> 6. "shortest path" is undefined here.  Again, work of ours is
> relevant:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_120
> 6.5655&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8
> UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaK
> T0byF8SKqSzWE&s=5CZHrVvCzrqIE5WlMt53hX0WAA0H7gTARE-g4zWoR3Y&e=
>
>
> 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_190
> 4.08605&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k
> 8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFa
> KT0byF8SKqSzWE&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.)
>
> 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.

This is a good point and I've been pondering many times about where do the soft real-time messages belong to. Lately I've been lumping them into the data plane which sounds in line with your thinking. Will look into clarifying this.

>
> 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.
>

Yes agreed. To me, the following items need work:

1. Section 6 needs an update (currently in the process of setting up online meeting - email coming soon) 2. Add a section on generations (work can start with Shota's PR) 3. Implement your feedback from 6 March e-mail and this e-mail 4. Final editing pass

To me, only items 1 and 2 are what I'd call "major" items which need careful thought. For item 3, in general I will just implement your feedback. I haven't done so yet since it covers the entire draft top to bottom so I wanted to have the core text finalised first in case some of that feedback can be incorporated with these changes.

> —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=
>
_______________________________________________
Qirg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/qirg
[Banner]

[Banner]<https://www.interdigital.com/white_papers/streaming-media-report->

ABI - Streaming Media Report<https://www.interdigital.com/white_papers/streaming-media-report->
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.