Re: [Qirg] Suggestions for architecture-04

[Joseph D Touch <[e-mail]>]

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 <[e-mail]> on behalf of Wojciech Kozlowski <[e-mail]>
Date: Wednesday, August 19, 2020 at 1:25 AM
To: "[e-mail]" <[e-mail]>
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.


     *

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

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.

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

[e-mail]<mailto:[e-mail]>

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=