Re: [Qirg] Comments about stages in draft-irtf-qirg-quantum-internet-use-cases

Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Wed, 31 March 2021 12:50 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 7CE843A277D for <qirg@ietfa.amsl.com>; Wed, 31 Mar 2021 05:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.817
X-Spam-Level:
X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 deZ7xCyHHN8W for <qirg@ietfa.amsl.com>; Wed, 31 Mar 2021 05:50:53 -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 ADF793A2781 for <qirg@irtf.org>; Wed, 31 Mar 2021 05:50:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id D09DBCC012F for <qirg@irtf.org>; Wed, 31 Mar 2021 14:50:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at tudelft.nl
Received: from mailservice.tudelft.nl ([130.161.131.74]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0DuQ2siLAOKl for <qirg@irtf.org>; Wed, 31 Mar 2021 14:50:47 +0200 (CEST)
Received: from SRV216.tudelft.net (mailboxcluster.tudelft.net [131.180.6.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx3.tudelft.nl (Postfix) with ESMTPS id 358E2CC012C for <qirg@irtf.org>; Wed, 31 Mar 2021 14:50:46 +0200 (CEST)
Received: from SRV217.tudelft.net (131.180.6.17) by SRV216.tudelft.net (131.180.6.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Wed, 31 Mar 2021 14:50:45 +0200
Received: from SRV217.tudelft.net ([fe80::1f9:fdaf:2ae6:2ebe]) by SRV217.tudelft.net ([fe80::1f9:fdaf:2ae6:2ebe%2]) with mapi id 15.01.2242.004; Wed, 31 Mar 2021 14:50:45 +0200
From: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
To: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: Comments about stages in draft-irtf-qirg-quantum-internet-use-cases
Thread-Index: AdciUzvNryOIrj6QSrKgZHTSDWFtiQACSW8gAJtajXAAGK8BYAAcjeYQABbfeGAADH74EA==
Date: Wed, 31 Mar 2021 12:50:45 +0000
Message-ID: <5c599f60f57949eaa303e80065762052@tudelft.nl>
References: <b209cf81a6a64c4e8df88306baa4065a@tudelft.nl> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA3EE4932@TW-MBX-P03.cnesnet.ad.cnes.fr> <820de72b162349749efee3934ca72f91@tudelft.nl> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA3EE4D76@TW-MBX-P03.cnesnet.ad.cnes.fr> <2bedf40681fa4fa99249b1c6866cf251@tudelft.nl> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA3EE51B6@TW-MBX-P03.cnesnet.ad.cnes.fr>
In-Reply-To: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA3EE51B6@TW-MBX-P03.cnesnet.ad.cnes.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/related; boundary="_004_5c599f60f57949eaa303e80065762052tudelftnl_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/MPCOjgiMM3bU4RjblRwWGB6lBX0>
Subject: Re: [Qirg] Comments about stages in draft-irtf-qirg-quantum-internet-use-cases
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Quantum Internet 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: Wed, 31 Mar 2021 12:50:59 -0000

Hi Patrick,

Those questions are exactly the ones the stages paper aims to answer so I would refer you to the paper for details. Most of it is summarized in Table 1 which I include below

[cid:image001.png@01D7263D.3A5F65B0]

Wojtek

From: Gelard Patrick <Patrick.Gelard@cnes.fr>
Sent: 31 March 2021 11:56
To: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>; qirg@irtf.org
Subject: RE: Comments about stages in draft-irtf-qirg-quantum-internet-use-cases

Hi Wojtek


"as my end-node capabilities increase what can I achieve",  I suppose what can I achieve for quantum communication rather than for quantum computation.
What could be a quantum end-node  ? Quantum sensors, quantum computer, ...

At the end-node, capabilities need to increase in what  for quantum communication ? number of Qubit, quantum circuit size, quantum circuit depth, quantum memory   capacity,  error resilience at the level of the quantum memory,  ...


Patrick
De : Qirg <qirg-bounces@irtf.org<mailto:qirg-bounces@irtf.org>> De la part de Wojciech Kozlowski
Envoyé : mardi 30 mars 2021 22:02
À : qirg@irtf.org<mailto:qirg@irtf.org>
Objet : Re: [Qirg] Comments about stages in draft-irtf-qirg-quantum-internet-use-cases

Hi Patrick,

Quantum repeaters are simply not a concern for the quantum internet stages paper. It's a tangential concern. They are not scaffolding. Quantum repeaters do not help one answer the question of "what can one do with an end-node". The paper is written with the idea of "as my end-node capabilities increase what can I achieve". Achievable distance is a separate concern. Quantum repeaters serve as a means to extend the network distance for any stage above trusted repeater networks. But in themselves, they do not allow new functionality.

Wojtek

From: Gelard Patrick <Patrick.Gelard@cnes.fr<mailto:Patrick.Gelard@cnes.fr>>
Sent: 30 March 2021 08:57
To: Wojciech Kozlowski <W.Kozlowski@tudelft.nl<mailto:W.Kozlowski@tudelft.nl>>; qirg@irtf.org<mailto:qirg@irtf.org>
Subject: RE: Comments about stages in draft-irtf-qirg-quantum-internet-use-cases

Hi Wojtek

If space and time (e.g latency)  are not take in account in Quantum Internet stages paper, what application functionality justifies quantum repeaters ?  For Artur Ekert information is physical : https://www.youtube.com/watch?v=XrKl38ZVofo<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DXrKl38ZVofo&d=DwMFAw&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=QZjDzR7P6KBXpTLAl0Ro4PSxKs8LEUaSB9sTLKyDsQo&s=3UrInx8LaHgZqjStO6n1Qi6YWV_mW7f6UDzevuJqEJQ&e=>

Are there maybe scaffolding that was used to define the various stages and then they were removed (or forgotten) ?

What can be the meaning of network itself for quantum "data plan" which is exclusively physical (i.e not encapsulation possible) ?

Patrick

De : Qirg <qirg-bounces@irtf.org<mailto:qirg-bounces@irtf.org>> De la part de Wojciech Kozlowski
Envoyé : lundi 29 mars 2021 20:37
À : qirg@irtf.org<mailto:qirg@irtf.org>
Objet : Re: [Qirg] Comments about stages in draft-irtf-qirg-quantum-internet-use-cases

Hi Patrick,

Yes, you are correct. But that is not what that paper was about. The Quantum Internet stages paper, and thus the definitions of the stages, was purely about application functionality - not length scales of quantum networks.

I agree that based on those definitions, the "prepare and measure" stage is most likely bound to short distances (think optical network with switches, but no amplifiers). What places it above trusted repeater networks is that it can do more than QKD even though distance-wise it seems like a step back (though once again - the stages are defined independently of distances).

That is what made me raise the point that perhaps in the QIRG, where we're more interested in the network itself we may want to use different stages (such as the three generations).

Wojtek

From: Gelard Patrick <Patrick.Gelard@cnes.fr<mailto:Patrick.Gelard@cnes.fr>>
Sent: 26 March 2021 17:42
To: Wojciech Kozlowski <W.Kozlowski@tudelft.nl<mailto:W.Kozlowski@tudelft.nl>>; qirg@irtf.org<mailto:qirg@irtf.org>
Subject: RE: Comments about stages in draft-irtf-qirg-quantum-internet-use-cases

Hi Wojtek , hi all,

Can we implement step 2 "prepare and measure" whatever the distance between the two end points which separate the preparation of the qubit (e.g by Alice) and its measurement (e.g by Bob) ? Attenuation caused by distance may prevent the application from functioning.

Best regards,
Patrick
De : Qirg <qirg-bounces@irtf.org<mailto:qirg-bounces@irtf.org>> De la part de Wojciech Kozlowski
Envoyé : vendredi 26 mars 2021 16:33
À : qirg@irtf.org<mailto:qirg@irtf.org>
Objet : [Qirg] Comments about stages in draft-irtf-qirg-quantum-internet-use-cases

Hi QIRG,

At the IETF meeting on 10 March, I raised some concerns about how the stages were expressed in this draft. I have read through carefully now and discussed it with some people and I have the following comments:

The network stages are defined based on application capabilities and NOT based on distance. Therefore, when summarising the network stages from the paper, the draft should not be mentioning distances. Currently there's a lot of focus put on distance. This means that stage-1: "trusted repeater stage" means basically QKD-only. Stage-2: "prepare-and-measure" means we can do QKD *and* other applications that only require prepare-and-measure functionality. Note that there is no statement about achievable distances - only about the end-node capabilities. Stage-3 allows end-to-end entanglement creation and so on.

Therefore, my practical feedback to the I-D authors is to forget about distances and rephrase in terms of application capabilities.

However, this raises an interesting point that perhaps the QIRG/I-D authors may want to consider is whether one may want to put some further thought as how distance capabilities affect the use cases as that is not covered by these aforementioned stages. I think it would be valuable if the community has any thoughts on this point.

Best,
Wojtek