Re: [Qirg] Suggestions for architecture-04

Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Wed, 19 August 2020 08:23 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 C1CDF3A10B6 for <qirg@ietfa.amsl.com>; Wed, 19 Aug 2020 01:23:42 -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 lFvlewbXbBuh for <qirg@ietfa.amsl.com>; Wed, 19 Aug 2020 01:23:41 -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 86BA33A0F3E for <qirg@irtf.org>; Wed, 19 Aug 2020 01:23:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id 2326ACC00D1 for <qirg@irtf.org>; Wed, 19 Aug 2020 10:23:39 +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 DIafzgxWGkHy for <qirg@irtf.org>; Wed, 19 Aug 2020 10:23:37 +0200 (CEST)
Received: from SRV220.tudelft.net (mailboxcluster.tudelft.net [131.180.6.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx3.tudelft.nl (Postfix) with ESMTPS id B8325CC00B8 for <qirg@irtf.org>; Wed, 19 Aug 2020 10:23:37 +0200 (CEST)
Received: from SRV220.tudelft.net (131.180.6.20) by SRV220.tudelft.net (131.180.6.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2044.4; Wed, 19 Aug 2020 10:23:30 +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; Wed, 19 Aug 2020 10:23:30 +0200
From: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
To: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: [Qirg] Suggestions for architecture-04
Thread-Index: AQHWdOEnDy3e74jKgUCrhm/btMR4XKk++MAA
Date: Wed, 19 Aug 2020 08:23:30 +0000
Message-ID: <c75b36d943ae65d4c4a7924ef8483df9f63abe67.camel@tudelft.nl>
References: <919E0F9F-F295-4F30-B0DB-231DDD10D81F@aero.org>
In-Reply-To: <919E0F9F-F295-4F30-B0DB-231DDD10D81F@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_c75b36d943ae65d4c4a7924ef8483df9f63abe67cameltudelftnl_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/BEBPTA_3gr-VsGtTCWp3t-NCAkY>
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: Wed, 19 Aug 2020 08:23:43 -0000

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.


     *
  *   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.


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.


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=