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

Fred Baker <fredbaker.ietf@gmail.com> Tue, 30 March 2021 22:11 UTC

Return-Path: <fredbaker.ietf@gmail.com>
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 8C6313A1115 for <qirg@ietfa.amsl.com>; Tue, 30 Mar 2021 15:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 L8udfpbQRssr for <qirg@ietfa.amsl.com>; Tue, 30 Mar 2021 15:11:30 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5353B3A10E9 for <qirg@irtf.org>; Tue, 30 Mar 2021 15:11:30 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id t18so8471004pjs.3 for <qirg@irtf.org>; Tue, 30 Mar 2021 15:11:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ovJU9Yaumu0EcrwnO1ysEU4KvXop0I1WlzHLqM8VPfE=; b=Q5daHkQnMJHFZAX76eZPKsziEcAW6rUslaDwWL1BJSS/k3rRCawmJVmmey/2ly8fLD n3yi9IE3B4g/GhcP9gZN0idskh+QkEhtB8T4PuVyPQpfS/otqUM5yRRA6/S0K41uR2/a QwqMxGTKqxj1b7Xs52N1WANYHaXu1ejeKEAOpXekYoqcRDF7unXt69ZPKvwDuzoiypvH h6MxeKIs5FZIjS1/Xsk3nJA7tG4VqCjXpQbDPgpFntfsAYhAdNnOHNVhQOcXTk6NuiKk de71Jnf5UhZ+YL+/oEtpvOo5wjwJHlDV6+6w3WW1IYgn4pI2U+AG4tI2EKhpjCz8ylBy gKgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ovJU9Yaumu0EcrwnO1ysEU4KvXop0I1WlzHLqM8VPfE=; b=uHM4gwJrjVaxpbbHsUmPqM4FvScsBHXjK4rZiV5XBpdwJkjQzJT5+ULF4+5E3d+xsl HXhsVrGFTGmLU5dbb7YCLFXty60DAVAvQXEReHfgxONbOHv0eOZKEvDAHKZAFppw1XcW etcRoZHfZdYcQMsDNQNlwes/2J96Eafq54uxJqu5wM1FtOkHb4mkYb13FA2BUdqY5kgL b+J1aZZDTiGL2VTsxRdzlNFvE/hNzOAxH9tcSVSh25ac9dWdZ75PZrBGU2kwHzp6WFJQ 8QEu4pHL7B2zZ6PKCnScWC2UWR74gvW2DzZVhabKIjMJu+gfAxYUGyYT5o9IlCFQnGv6 J9Wg==
X-Gm-Message-State: AOAM533lMOQtPfBC6jag+jPo4OXL7ljq72IXaiAg7+PlNAqdBBMPF2Gk VgPEJZoM4KtCSBpmiHhWLYU=
X-Google-Smtp-Source: ABdhPJynTph0QJTqNC6cA8BTmCD0kfOVCBgfbJvTUwn9a89n0wLXANmuw+hzUV9M3xz3ZT7i1K1EVQ==
X-Received: by 2002:a17:90a:bf0a:: with SMTP id c10mr398655pjs.195.1617142288974; Tue, 30 Mar 2021 15:11:28 -0700 (PDT)
Received: from smtpclient.apple ([2600:8801:d008:2c00:7d5a:aafb:4f88:fc96]) by smtp.gmail.com with ESMTPSA id f65sm202728pgc.19.2021.03.30.15.11.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Mar 2021 15:11:28 -0700 (PDT)
From: Fred Baker <fredbaker.ietf@gmail.com>
X-Google-Original-From: Fred Baker <FredBaker.IETF@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-92FD64B4-4E31-41D4-A070-CF95152CA998"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Tue, 30 Mar 2021 15:11:27 -0700
Message-Id: <8EF0850E-E776-4771-A2C7-BAB8337F5CCF@gmail.com>
References: <61CB2AB6-21A8-4A55-9EBB-42DE5EB4D2ED@sfc.wide.ad.jp>
Cc: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>, Rodney Van Meter <rdv@sfc.wide.ad.jp>, qirg@irtf.org
In-Reply-To: <61CB2AB6-21A8-4A55-9EBB-42DE5EB4D2ED@sfc.wide.ad.jp>
To: Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>
X-Mailer: iPad Mail (18E5140k)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/s_aLWA3K5iGWdMoS5ujMzh8nd_o>
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: Tue, 30 Mar 2021 22:11:42 -0000

I would ask about the set of nodes comprising the “path”, however. The way you say this suggests that there is exactly one route, and the capability is the AND of the individual capabilities of those nodes on the path chosen. The most common path may contain an incapable node, but selecting a different route will identify a set of nodes that are capable of whatever is chosen. 

That concept is basic to anycast, at least as used in DNS. My request will go to the nearest node advertising the indicated destination address for which I have a viable route or path, but the choice of node may not be as predictable as I would like. If the path fails, that may change the node my packet goes to. As a result, DNS on UDP to a root server has a very high probability of working (it gets somewhere, and whoever it gets to responds), but DNS/TCP might not. I might do the SYN/SYN-ACK exchange only to have the path change, so that the request in the first data packet goes to a system that has no idea of the session state and responds RST.

Sent from my iPad

> On Mar 30, 2021, at 2:54 PM, Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org> wrote:
> 
> 
> <list member hat on>
> I agree with Wojtek’s point here that distance is a separate axis from capability. Capability, in fact, is essentially the AND of the capabilities of nodes along the path — if any node doesn’t support the operation, then it won’t be possible end-to-end.  Without some sort of discovery protocol that might, in fact, be hard to determine, but the most likely minimum-capability node is the end node, anyway.  (You know, this is a point I hadn’t really thought of in these terms until now.  Might be worth writing down in one draft or the other…)
> 
> Actually, I guess that’s not *exactly* true; the Qunnect nodes discussed at last week’s excellent seminar can store qubits, but not do anything sophisticated with them.  If you want purification, QEC or any sort of computation, that can be done at further nodes that have more capabilities, e.g. memory and a general gate set.
> 
> Hmm, so what’s the right way to express that…good question.
> 
> BUT:
> 
> Latency figures in as a *practical* constraint.  If you are trying to execute an application that requires end-to-end communication while storing qubits, as in some true distributed quantum applications, then you have to have long-lived memories. How long is probably expressed as a multiple of RTT.
> 
> So, the Wehner roadmap’s talk of stages of development is important, and plenty complex and nuanced as it is, but the reality is that networks and internetworks will likely be deployed in incremental, heterogeneous fashion and what a path is capable of might be different from the nominal stage of development of the network itself.
> 
> In short, the existing stages taxonomy is a guideline, and might help network operators define requirements as they consider deploying networks, but it’s not an exact spec.
> 
> —Rod
> 
> Rodney Van Meter
> rdv@sfc.wide.ad.jp
> Professor, Faculty of Environment and Information Studies, Keio University, Japan
> 
>> On Mar 31, 2021, at 5:01, Wojciech Kozlowski <W.Kozlowski@tudelft.nl> wrote:
>> 
>> 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> 
>> Sent: 30 March 2021 08:57
>> 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
>>  
>> 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
>>  
>> 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> De la part de Wojciech Kozlowski
>> Envoyé : lundi 29 mars 2021 20:37
>> À : 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> 
>> 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> De la part de Wojciech Kozlowski
>> Envoyé : vendredi 26 mars 2021 16:33
>> À : 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 
>> _______________________________________________
>> Qirg mailing list
>> Qirg@irtf.org
>> https://www.irtf.org/mailman/listinfo/qirg
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg