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

Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Mon, 29 March 2021 18:36 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 352893A1DF6 for <qirg@ietfa.amsl.com>; Mon, 29 Mar 2021 11:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level:
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 jw65yGEh-6ca for <qirg@ietfa.amsl.com>; Mon, 29 Mar 2021 11:36:49 -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 3DC1D3A1DF2 for <qirg@irtf.org>; Mon, 29 Mar 2021 11:36:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id 7D5F964013F for <qirg@irtf.org>; Mon, 29 Mar 2021 20:36:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at tudelft.nl
Received: from mailservice.tudelft.nl ([130.161.131.73]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qWGG9jQC98CC for <qirg@irtf.org>; Mon, 29 Mar 2021 20:36:43 +0200 (CEST)
Received: from SRV126.tudelft.net (srv126.tudelft.net [131.180.6.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.tudelft.nl (Postfix) with ESMTPS id CEA6164013D for <qirg@irtf.org>; Mon, 29 Mar 2021 20:36:43 +0200 (CEST)
Received: from SRV217.tudelft.net (131.180.6.17) by SRV126.tudelft.net (131.180.6.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Mon, 29 Mar 2021 20:36:43 +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; Mon, 29 Mar 2021 20:36:43 +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: AdciUzvNryOIrj6QSrKgZHTSDWFtiQACSW8gAJtajXA=
Date: Mon, 29 Mar 2021 18:36:43 +0000
Message-ID: <820de72b162349749efee3934ca72f91@tudelft.nl>
References: <b209cf81a6a64c4e8df88306baa4065a@tudelft.nl> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA3EE4932@TW-MBX-P03.cnesnet.ad.cnes.fr>
In-Reply-To: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA3EE4932@TW-MBX-P03.cnesnet.ad.cnes.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_820de72b162349749efee3934ca72f91tudelftnl_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/zkb2eGILTqWaX6-M-SmDdW3zQ0s>
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: Mon, 29 Mar 2021 18:36:54 -0000

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>
Sent: 26 March 2021 17:42
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 , 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