Re: [Qirg] multiplexing?

Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Wed, 28 April 2021 14:28 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 CF4E33A0CD1 for <qirg@ietfa.amsl.com>; Wed, 28 Apr 2021 07:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.817
X-Spam-Level:
X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 EkkSRBm7FgJr for <qirg@ietfa.amsl.com>; Wed, 28 Apr 2021 07:28:20 -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 364783A0CC4 for <qirg@irtf.org>; Wed, 28 Apr 2021 07:28:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id 47B7CCC00C1 for <qirg@irtf.org>; Wed, 28 Apr 2021 16:28:13 +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 gMO364G3nk4d for <qirg@irtf.org>; Wed, 28 Apr 2021 16:28:09 +0200 (CEST)
Received: from SRV128.tudelft.net (srv128.tudelft.net [131.180.6.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx3.tudelft.nl (Postfix) with ESMTPS id ADD3FCC0084 for <qirg@irtf.org>; Wed, 28 Apr 2021 16:28:09 +0200 (CEST)
Received: from SRV217.tudelft.net (131.180.6.17) by SRV128.tudelft.net (131.180.6.228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Wed, 28 Apr 2021 16:28:09 +0200
Received: from SRV217.tudelft.net ([fe80::1f9:fdaf:2ae6:2ebe]) by SRV217.tudelft.net ([fe80::1f9:fdaf:2ae6:2ebe%2]) with mapi id 15.01.2242.008; Wed, 28 Apr 2021 16:28:09 +0200
From: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
To: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: [Qirg] multiplexing?
Thread-Index: AQHXOzf4UoxOqXCzGUyF2cDCFyJ9sqrH6KGAgAABJYCAAAOzAIAABzgAgAIIpcA=
Date: Wed, 28 Apr 2021 14:28:09 +0000
Message-ID: <0b4f56d9b1e24f558c21420ef3f61474@tudelft.nl>
References: <05E19233-CE34-487B-BB1B-F37577F0954A@sfc.wide.ad.jp> <51886A1A-BE2B-4A31-BAFC-0917AE5A5C2F@gmail.com> <5A703310-DF2E-4E29-BC00-FC54E7A133A6@sfc.wide.ad.jp> <10CBC0C8-1F06-40CC-A7F6-884EE907661A@gmail.com> <73821F62-0068-478B-86E2-63045ACC7D93@gmail.com>
In-Reply-To: <73821F62-0068-478B-86E2-63045ACC7D93@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_0b4f56d9b1e24f558c21420ef3f61474tudelftnl_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/AU8mgG_2koXGcMNMZuxXbHeq-pw>
Subject: Re: [Qirg] multiplexing?
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: Wed, 28 Apr 2021 14:28:25 -0000

Hi all,



I myself don't see much point in adding anything about multiplexing.



As Bruno pointed out there are two meanings of multiplexing to cover:



1)      Resource sharing – I’m not sure what benefit we will gain in the draft from saying that multiplexing will be one particular way for resource sharing, be it TDM/WDM/etc. Furthermore, even in the description below the discussion descends to quite a low level at the physical layer which is an area that this draft is explicitly trying not to cover.

2)      Multiple entanglement attempts – this is a very low-level physical detail and for the same reason as above I wouldn’t say it fits in the draft.



Both concepts are important, but I’m not convinced that a mention of multiplexing would bring much to the draft that’s not already there. Having said that, if somebody submits a pull request on GitHub, I can happily help in editing it into the draft.



Thanks,

Wojtek


From: Qirg <qirg-bounces@irtf.org> On Behalf Of Bruno Rijsman
Sent: 27 April 2021 11:19
To: Rodney Van Meter <rdv@sfc.wide.ad.jp>
Cc: qirg@irtf.org; Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>
Subject: Re: [Qirg] multiplexing?

Would you like me to propose some specific language for the draft in a pull request?  (Not much, just one or two paragraphs mentioning the different kinds of multiplexing and why they are relevant.)

— Bruno


On Apr 27, 2021, at 10:52 AM, Bruno Rijsman <brunorijsman@gmail.com<mailto:brunorijsman@gmail.com>> wrote:

Ah, yes, I was thinking of a more quantum-specific flavor of multiplexing: having multiple entanglements attempts going in parallel.

If you need to do attempts sequentially (waiting for a round-trip time to receive the heralding result before starting the next attempt) entanglement generation is going to be very slow for reasonable distances.

For example, this paper https://arxiv.org/abs/1309.3202<https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1309.3202&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=rHseDIvPhlc-tZ1QRgND-UyfLPX4lVD9A1L-MGoQQEc&s=ugMseTdfsAultDmBJm4h1VnpFhlv8X7X3UqFJIJPUU4&e=> discusses spectral multiplexing where parallelism is achieved spectrally.

Or in NV centers parallelism (multiplexing) can be achieved by moving the communication qubit to a storage qubit to free up the communication qubit for the next entanglement attempt before the previous attempt was finished, i.e. before the heralding result was received (there is a paper on this, but I can’t locate it just right now).

But you are right, statistical muxing vs TDM muxing vs WDM muxing are also important considerations in quantum networks.

You need some TDM-ish clock synchronization to achieve indistinguishable photon arrivals at the heralding midpoint.  If you are also doing “parallelism” multiplexing in the sense of the start of this e-mail, then this almost inevitably leads to some sort of “time slot” concept.

And it is also often highly desirable (but not always practical) to WDM-mux the classical control channel onto the same fiber as the quantum data channel (and possibly even other classical data channels) to avoid having to use multiple fibers.

— Bruno


On Apr 27, 2021, at 10:39 AM, Rodney Van Meter <rdv@sfc.wide.ad.jp<mailto:rdv@sfc.wide.ad.jp>> wrote:

Mmm, one problem is that it is used at many levels, and perhaps you and I are using it in different ways here.  I’m thinking of stat mux v. circuit switching, a very networky thing, but it’s also used to refer to frequency allocation in WDM and the quantum folks also use it to mean being able to connect multiple qubit memories to a single optical channel.

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 Apr 27, 2021, at 17:35, Bruno Rijsman <brunorijsman@gmail.com<mailto:brunorijsman@gmail.com>> wrote:

I vote for updating the draft to mention multiplexing.

It is too important of a concept for achieving practically usable entanglement rates.

— Bruno


On Apr 27, 2021, at 9:35 AM, Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org<mailto:rdv=40sfc.wide.ad.jp@dmarc.ietf.org>> wrote:

Wojtek,

Just dinking around I noticed that we never use the word “multiplexing” in our I-D.
https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dirtf-2Dqirg-2Dprinciples_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=rHseDIvPhlc-tZ1QRgND-UyfLPX4lVD9A1L-MGoQQEc&s=TNZB2jajBPA7N0aAWrUc3DEMyshSR0UPpQp3ImDn0Kw&e=>
We do refer to “resource management”.

QIRGers, what do y’all think?  Should we use muxing in some form in this to discuss the problem of managing access to resources along the path?

—Rod

P.S. Yes, we said in IETF a few weeks ago that this would be sent to IRSG by now, but we haven’t gotten it sent. I do think it’s ready.

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

_______________________________________________
Qirg mailing list
Qirg@irtf.org<mailto:Qirg@irtf.org>
https://www.irtf.org/mailman/listinfo/qirg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwQFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=rHseDIvPhlc-tZ1QRgND-UyfLPX4lVD9A1L-MGoQQEc&s=3YrvPDa7iO9bNQ53zT3sBLXdnvX2G7aG-CYTKqWYlck&e=>