[Qirg] Discrete/Continuous variable encodings

Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Tue, 09 June 2020 15:15 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 7443C3A07FC for <qirg@ietfa.amsl.com>; Tue, 9 Jun 2020 08:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 TaDJGpAVxQgl for <qirg@ietfa.amsl.com>; Tue, 9 Jun 2020 08:15:05 -0700 (PDT)
Received: from mailservice.tudelft.nl (mailservice.tudelft.nl [130.161.131.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48A23A07F8 for <Qirg@irtf.org>; Tue, 9 Jun 2020 08:15:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id B3B2B2400B2 for <Qirg@irtf.org>; Tue, 9 Jun 2020 17:15:03 +0200 (CEST)
X-Virus-Scanned: amavisd-new at tudelft.nl
Received: from mailservice.tudelft.nl ([130.161.131.71]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xN622ryaCTSg for <Qirg@irtf.org>; Tue, 9 Jun 2020 17:15:02 +0200 (CEST)
Received: from SRV219.tudelft.net (srv219.tudelft.net [131.180.6.19]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by mx4.tudelft.nl (Postfix) with ESMTPS id EF4122400B9 for <Qirg@irtf.org>; Tue, 9 Jun 2020 17:15:02 +0200 (CEST)
Received: from SRV220.tudelft.net (131.180.6.20) by SRV219.tudelft.net (131.180.6.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.1913.5; Tue, 9 Jun 2020 17:14:55 +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.1913.007; Tue, 9 Jun 2020 17:14:55 +0200
From: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
To: "Qirg@irtf.org" <Qirg@irtf.org>
Thread-Topic: Discrete/Continuous variable encodings
Thread-Index: AQHWPnC7mmy7EfyJAEybkKsbrMI2Ew==
Date: Tue, 09 Jun 2020 15:14:55 +0000
Message-ID: <d4b221412d3a779c162ff54519fadea5aa66fe2d.camel@tudelft.nl>
Accept-Language: en-GB, nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-ID: <9EAEB6FB17D9774C96934E7295E932D8@forest.intra>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/o3GUJfWDcy4xx4Y5tp4GdxJn4SU>
Subject: [Qirg] Discrete/Continuous variable encodings
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: Tue, 09 Jun 2020 15:15:09 -0000

Dear QIRG,

One point that was raised on the call today was whether it's a goal to support
continuous variable qubits as well as discrete variable qubits.

The consensus appeared to be that something should be included, but that it's
quite a heavy topic on its own.

Last year, Patrick Gelard, did submit a PR for the draft in which he proposed
that such encoding diversity be a goal so I think that's the best point to
start a discussion from (look for lines 1111-1127): 
https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/1/files

I was initially reluctant to include this section (and I haven't so far) as it
appeared to me that it goes too deep into the physical layer. If CV vs DV can
be kept entirely within the hardware and there is no reason to expose it beyond
that, it might be best to keep it out of the draft. If it does somehow affect
the protocol design landscape then I think it's a point worth mentioning.

Question to the community:
1. Is it worth having something about CV vs DV? Does it have an impact on the
protocol design landscape?
2. If it is, does the contribution above cover the subject?

Cheers,
Wojtek