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

Rodney Van Meter <rdv@sfc.wide.ad.jp> Tue, 30 March 2021 22:17 UTC

Return-Path: <rdv@sfc.wide.ad.jp>
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 69B913A1133 for <qirg@ietfa.amsl.com>; Tue, 30 Mar 2021 15:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=sfc.wide.ad.jp
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 7WlvassYHVlm for <qirg@ietfa.amsl.com>; Tue, 30 Mar 2021 15:17:14 -0700 (PDT)
Received: from mail1.sfc.wide.ad.jp (mail1.sfc.wide.ad.jp [203.178.142.133]) (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 7534F3A1126 for <qirg@irtf.org>; Tue, 30 Mar 2021 15:17:14 -0700 (PDT)
Received: from [192.168.3.2] (softbank126077194248.bbtec.net [126.77.194.248]) (Authenticated sender: rdv) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4EBE06A; Wed, 31 Mar 2021 07:17:12 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1617142632; bh=cnwcHB1NKpLj0tejjO8EtiymNjEy0sE8xDtX9jSQkS4=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=JhZfn0aD9nZ2EM1qe5+xXhxHG8/YGIooMEXXEAUcIWy2D8CI8rRUjhGNIBOTlx7py ZFFY9wW9z79gGWTL4OyhP+f2XfjQ4NflsajzaBsDFZAms1usOuVrc8L3mGrfBkhxbs g/KHt6Bly/PI/rXP9X35MTv4hvLuLUzr3aWaHJLjB5ranW6/nyN+3qderarw7K/CrY Kcw4sSRsONw5DuUS//lEN7JsnvS66590JbWQ1Hb9xmN955xQJKJwN+ZrZgKNkjaIcX iS4xQYk2G03iTbInH1A/NSYK7KNnh9oRk8stcTLY9Qae0F+MOo5o63tRgPTU4cb32O pi2stGwDGRK4g==
From: Rodney Van Meter <rdv@sfc.wide.ad.jp>
Message-Id: <91B5820C-488F-4D32-B3D0-BA0DE417845D@sfc.wide.ad.jp>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B647CF93-085E-4B02-BED2-E25CDBED75E7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 31 Mar 2021 07:17:11 +0900
In-Reply-To: <8EF0850E-E776-4771-A2C7-BAB8337F5CCF@gmail.com>
Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp>, Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>, Wojciech Kozlowski <W.Kozlowski@tudelft.nl>, qirg@irtf.org
To: Fred Baker <fredbaker.ietf@gmail.com>
References: <61CB2AB6-21A8-4A55-9EBB-42DE5EB4D2ED@sfc.wide.ad.jp> <8EF0850E-E776-4771-A2C7-BAB8337F5CCF@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/7w7Y50jev1mZ3lWXpixiMAhEvxc>
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:17:20 -0000

Yeah, that’s exactly the kind of issue we are going to face as the engineering gets concrete.

At the moment, though, for 1G networks, I can only imagine this working with substantial amounts of connection state held in every node on the path.  That means that any change to routing mid-connection will involve renegotiating at least part of the path and connection setup.

We’re going to end up with something closer to circuit switched than packet switched, but the exact form is TBD. Many of you here are much more up to date than I am on the reality of router implementation; the semantics are (close to?) statistical muxing with fully independent switching/routing decisions packet by packet, and that’s not going to be feasible when you are managing E2E entanglement swapping and purification.

Rodney Van Meter
rdv@sfc.wide.ad.jp
Professor, Faculty of Environment and Information Studies, Keio University, Japan

> On Mar 31, 2021, at 7:11, Fred Baker <fredbaker.ietf@gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <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 
>>> _______________________________________________
>>> Qirg mailing list
>>> Qirg@irtf.org <mailto:Qirg@irtf.org>
>>> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>
>> _______________________________________________
>> Qirg mailing list
>> Qirg@irtf.org
>> https://www.irtf.org/mailman/listinfo/qirg