Re: [Qirg] Suggestions for architecture-04

Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Fri, 21 August 2020 16:21 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 744653A0C1F for <qirg@ietfa.amsl.com>; Fri, 21 Aug 2020 09:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=no 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 lEgLmH124rXY for <qirg@ietfa.amsl.com>; Fri, 21 Aug 2020 09:21:24 -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 C171E3A0C0B for <qirg@irtf.org>; Fri, 21 Aug 2020 09:21:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id 96546CC00D3; Fri, 21 Aug 2020 18:21:22 +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 O-E0Ci1Kl33v; Fri, 21 Aug 2020 18:21:20 +0200 (CEST)
Received: from SRV217.tudelft.net (mailboxcluster.tudelft.net [131.180.6.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx3.tudelft.nl (Postfix) with ESMTPS id 9D3EACC00D8; Fri, 21 Aug 2020 18:21:20 +0200 (CEST)
Received: from SRV220.tudelft.net (131.180.6.20) by SRV217.tudelft.net (131.180.6.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2044.4; Fri, 21 Aug 2020 18:21:13 +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.2044.004; Fri, 21 Aug 2020 18:21:13 +0200
From: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
To: "qirg@irtf.org" <qirg@irtf.org>, "joseph.d.touch@aero.org" <joseph.d.touch@aero.org>
Thread-Topic: [Qirg] Suggestions for architecture-04
Thread-Index: AQHWdOEnDy3e74jKgUCrhm/btMR4XKk++MAAgAB3LwCAAzLzAA==
Date: Fri, 21 Aug 2020 16:21:13 +0000
Message-ID: <fca3f649579a261ab009845ca264b4a326841784.camel@tudelft.nl>
References: <919E0F9F-F295-4F30-B0DB-231DDD10D81F@aero.org> <c75b36d943ae65d4c4a7924ef8483df9f63abe67.camel@tudelft.nl> <97C38F9E-02F4-4512-9ED2-1B4AB2F36042@aero.org>
In-Reply-To: <97C38F9E-02F4-4512-9ED2-1B4AB2F36042@aero.org>
Accept-Language: en-GB, nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_fca3f649579a261ab009845ca264b4a326841784cameltudelftnl_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/Pg6CKaloDiemJ7len9pOCSDptw8>
Subject: Re: [Qirg] Suggestions for architecture-04
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: Fri, 21 Aug 2020 16:21:27 -0000

Inline

On Wed, 2020-08-19 at 20:30 +0000, Joseph D Touch wrote:
Hi, Wojtek,

See below [jt]…

Thanks,
Joe

--
Dr. Joseph Touch
Sr Distributed Systems Data Architect
Information Systems and Cyber Division
The Aerospace Corporation
424-254-4357 cell


From: Qirg <qirg-bounces@irtf.org> on behalf of Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
Date: Wednesday, August 19, 2020 at 1:25 AM
To: "qirg@irtf.org" <qirg@irtf.org>
Subject: Re: [Qirg] Suggestions for architecture-04

Hi Joe,

Thanks for the comments! See my replies inline.

Cheers,
Wojtek

On Mon, 2020-08-17 at 21:55 +0000, Joseph D Touch wrote:
Hi, all,

Jumping in on the discussion (let me know if these would be easier to separate out), some thoughts below:


  *   Sec 5.3.1 could omit the “automated quantum nodes”

     *   They’re just degenerate cases of quantum routers with two quantum channels.

[WK] Agreed, but I find that experimentalists (at least those I interact with) use this term regularly and thus I used this term to make a connection to their terminology.

[jt] it is certainly useful to keep the term in that case, but it might be useful to describe it as a special case of a quantum router (under that entry), rather than as a implying it is distinct.

[WK] They are slightly distinct as one will use automated quantum nodes to build long-distance repeater chains that on a network level function may appear as a single logical link. They are slightly different from a quantum router in that they won't be running a control plane and thus won't be routing.



     *

  *   Sec 5.3.2 should distinguish between quantum channels and classical as follows

     *   The quantum channels, at least as described, are direct (though, see below)
     *   The classical channels can be multihop classical paths

[WK] Good point. Will add that in the next iteration.


Finally, in classical architecture, I like to find equivalences within the architecture (e.g., see https://www.strayalpha.com/pubs/isi-tr-711.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.strayalpha.com_pubs_isi-2Dtr-2D711.pdf&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=84H0o9QVcWkrnBhBpSpT2P-_swIvZg5HoGx2t-kVrnw&s=1xG_RcY47VZqwfpoC3yX4pn6LNHfG-OXB67pWZ3wHAI&e=>)NHfG-OXB67pWZ3wHAI&e=>). Here, in particular:

  *   That a multiparty link and a router are equivalent

     *   Where a multiparty link uses a MAC to determine forwarding, but a router determines it in-band

  *   That a link and a tunnel are equivalent

     *   Where a tunnel is an encapsulation-based link that can be applied recursively, and a physical link is just the base case of that recursion

In quantum nets, I think the multiparty link and router equivalence holds, e.g., a single fiber could have multiple taps at different wavelengths or that are switched based on control info where frequency and timing can determine destination (same as FDMA and TDMA classical links). Granted that some other classical multiparty link and MAC examples may not have quantum corollaries.

[WK] If I follow your train of thought correctly, I think I would also add cases where the link has the mid-point in the middle and you can then connect multiple quantum routers to the same mid-point (and perhaps optical switches) achieving something similar to an L2 LAN (which is what I assume you mean by multiparty link) in classical network.

[jt] I’m thinking of a link where a single transmitter goes into a classical optical switch under classical control. E.g., consider fibers all going into a controllable patch-panel. That looks a lot like a multi-drop optical channel – but doesn’t rely on optical interaction to make the decision. That way a single endpoint can reach other endpoints via classical control. This is distinct from a quantum router, which (IMO) basically terminates every optical link and runs as an endpoint for teleportation protocols.

[WK] Sounds reasonable and good to keep in mind. I'll think about adding a note that the links don't have to be point-to-point and can connect multiple nodes.


I’m still thinking about the tunnel example; in some sense, it could be just what quantum teleportation achieves (I think this is likely, given previous work Rod and I did on QRNA). We’d need to make sure the control protocols were similarly recursive, though.

[WK] That sounds plausible, but I think a discussion of tunnels and recursive architectures is beyond the scope of this particular document as I tried to stay far away from concrete architecture proposals and discussions. However, the idea is interesting. If there is enough material to develop this thought it would be nice to develop in a discussion on the mailing list.

[jt] agreed that recursion is not useful in this doc per se, but I want to try to make sure the descriptions in this doc don’t get in the way of future recursive considerations. I.e., it informs my architectural thinking for this doc.


[WK] I don't think it does. If there is something that does get in the way let me know as I'm in favour of making sure this solution isn't precluded by this document.


It might be useful to add a section discussing these issues.

Joe

--
Dr. Joseph Touch
Sr Distributed Systems Data Architect
Information Systems and Cyber Division
The Aerospace Corporation
424-254-4357 cell


_______________________________________________

Qirg mailing list

Qirg@irtf.org<mailto:Qirg@irtf.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=84H0o9QVcWkrnBhBpSpT2P-_swIvZg5HoGx2t-kVrnw&s=J38fDOoCV3fDMV5umtCTV0tLOhI3kU8bkH16krmLPi8&e=