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

Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Tue, 19 May 2020 13:29 UTC

Return-Path: <W.Kozlowski@tudelft.nl>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7033A040D for <qirg@ietfa.amsl.com>; Tue, 19 May 2020 06:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf4TWxwJfbmy for <qirg@ietfa.amsl.com>; Tue, 19 May 2020 06:28:57 -0700 (PDT)
Received: from mailservice.tudelft.nl (mailservice.tudelft.nl [130.161.131.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115E83A040B for <qirg@irtf.org>; Tue, 19 May 2020 06:28:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id 36D3E400A8 for <qirg@irtf.org>; Tue, 19 May 2020 15:28:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at tudelft.nl
Received: from mailservice.tudelft.nl ([130.161.131.69]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id etnhPHHWnxZY for <qirg@irtf.org>; Tue, 19 May 2020 15:28:53 +0200 (CEST)
Received: from SRV223.tudelft.net (srv223.tudelft.net [131.180.6.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1.tudelft.nl (Postfix) with ESMTPS id 8D6274008D for <qirg@irtf.org>; Tue, 19 May 2020 15:28:52 +0200 (CEST)
Received: from SRV220.tudelft.net (131.180.6.20) by SRV223.tudelft.net (131.180.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.1913.5; Tue, 19 May 2020 15:28:46 +0200
Received: from SRV220.tudelft.net ([fe80::dc7a:a6b8:8bb9:2210]) by SRV220.tudelft.net ([fe80::dc7a:a6b8:8bb9:2210%13]) with mapi id 15.01.1913.007; Tue, 19 May 2020 15:28:46 +0200
From: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
To: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: [Qirg] arch I-D: pull request & comments
Thread-Index: AQHWLaQyrVsKAcW+NkSdtv+Hsw5K7qivRggA
Date: Tue, 19 May 2020 13:28:46 +0000
Message-ID: <215d3c5ab429fa441f0c2713c516809748544299.camel@tudelft.nl>
References: <553672B6-E4C5-4537-8916-E2B1F200A362@sfc.wide.ad.jp>
In-Reply-To: <553672B6-E4C5-4537-8916-E2B1F200A362@sfc.wide.ad.jp>
Accept-Language: en-GB, nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-ID: <055274B89C7EB34F9F92A88F07236104@forest.intra>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/UfLLkIvElzAFAeKqwN5cZwRaW-c>
Subject: Re: [Qirg] arch I-D: pull request & comments
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2020 13:29:02 -0000

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_1206.5655&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&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_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.)
> 
> 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
> rdv@sfc.wide.ad.jp
> 
> 
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> 
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=
>