Re: [Qirg] GitHub PR Patch 1

Gelard Patrick <Patrick.Gelard@cnes.fr> Wed, 12 February 2020 10:40 UTC

Return-Path: <Patrick.Gelard@cnes.fr>
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 D668C120077 for <qirg@ietfa.amsl.com>; Wed, 12 Feb 2020 02:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.332
X-Spam-Level:
X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TO_EQ_FM_DIRECT_MX=2.12, T_KAM_HTML_FONT_INVALID=0.01, 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 OkdJyiB9_V-I for <qirg@ietfa.amsl.com>; Wed, 12 Feb 2020 02:40:45 -0800 (PST)
Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) (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 1D681120045 for <Qirg@irtf.org>; Wed, 12 Feb 2020 02:40:44 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.70,428,1574121600"; d="scan'208,217"; a="14210533"
X-IPAS-Result: A2E8BQCz1UNe/wYBeAplHAEBAQEBBwEBEQEEBAEBgXuBJVMxWRNQJRIXEwqECpErmVKBYwQJAQEBAQEBAQEBIAEJBwMBAgEBhEACF4IzJDgTAhABAQEEAQEBAQEFAgEBAgJphGtMDIY7AQEBAQIBAQEYCQo6BAMCDgsCAQUDDRUWAQYDAgICJQsUEQIEAQkJCBODDIF9XiAPqip1gTIahBsBCwGGDYE4gWWHIYMAgjiBEUeCTD6CZAEBAQEagQtABQcoAoJYMoIsBI1fgniFZooAjkN2B4FBfIJOhH6PH3iBUHqLTwOMAY5mgUuHI5RNI4FYMxonTIJsCQo9GI4GMBeDUIUUhT9EMAIBAQERgQsIjXUHgSwBgQ8BAQ
X-URL-LookUp-ScanningError: 1
From: Gelard Patrick <Patrick.Gelard@cnes.fr>
To: Gelard Patrick <Patrick.Gelard@cnes.fr>, Wojciech Kozlowski <W.Kozlowski@tudelft.nl>, "Qirg@irtf.org" <Qirg@irtf.org>
Thread-Topic: GitHub PR Patch 1
Thread-Index: AQHV2u5mOAbDqf0lLku7JVAzQGDFgagMy5NAgAlW5ACAATKyQIAAFi4A
Date: Wed, 12 Feb 2020 10:40:41 +0000
Message-ID: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BECC8@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <d755e4fc670c04bffdf1c6b61f060d2c4e26d7dd.camel@tudelft.nl> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BC6BE@TW-MBX-P03.cnesnet.ad.cnes.fr> <cc778539e618e872fbfc50f3d3aef6c41073942b.camel@tudelft.nl> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BECB3@TW-MBX-P03.cnesnet.ad.cnes.fr>
In-Reply-To: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BECB3@TW-MBX-P03.cnesnet.ad.cnes.fr>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-25226.006
x-tm-as-result: No--29.992100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BECC8TWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/EYp6_3sEmyEl1KnrFtBZAHDvPIs>
Subject: Re: [Qirg] GitHub PR Patch 1
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, 12 Feb 2020 10:40:49 -0000

Correction of an error in red

De : Qirg <qirg-bounces@irtf.org> De la part de Gelard Patrick
Envoyé : mercredi 12 février 2020 11:36
À : Wojciech Kozlowski <W.Kozlowski@tudelft.nl>; Qirg@irtf.org
Objet : Re: [Qirg] GitHub PR Patch 1

Responses inline


De : Wojciech Kozlowski <W.Kozlowski@tudelft.nl<mailto:W.Kozlowski@tudelft.nl>>
Envoyé : mardi 11 février 2020 17:02
À : Qirg@irtf.org<mailto:Qirg@irtf.org>; Gelard Patrick <Patrick.Gelard@cnes.fr<mailto:Patrick.Gelard@cnes.fr>>
Objet : Re: GitHub PR Patch 1

Responses inline

On Wed, 2020-02-05 at 16:51 +0000, Gelard Patrick wrote:

Hi Wojtek



Thank you for taking the time to respond to my request.



Bests regard

Patrick

-----Message d'origine-----
De : Qirg <qirg-bounces@irtf.org<mailto:qirg-bounces@irtf.org>> De la part de Wojciech Kozlowski
Envoyé : mardi 4 février 2020 01:03
À : Qirg@irtf.org<mailto:Qirg@irtf.org>
Objet : Re: [Qirg] GitHub PR Patch 1



Re: https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/1<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_1&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=Y-L5ux1nx2cE4n0_44-DYxXLvMwwm6j-ig1CPFAEAL4&e=>



Hi Patrick,



Thanks for the pull request!



I've finally had some time to look at it now that I'm back to working on the draft and before I include your changes I have some questions:



> Bell's pair-generating sources are part of the link.



[WK] I'm not sure I'd say the that the sources are part of the link, but the link is crucial part of the generation process. I think it's worth returning to this point once I sort out Sara's contribution about elementary link generation.

[PG]

My request is linking to the answer of Rodney :
De : Rodney Van Meter <rdv@sfc.wide.ad.jp<mailto:rdv@sfc.wide.ad.jp>>
Envoyé : vendredi 15 mars 2019 13:24
À : Gelard Patrick <Patrick.Gelard@cnes.fr<mailto:Patrick.Gelard@cnes.fr>>
Cc : Rodney Van Meter <rdv@sfc.wide.ad.jp<mailto:rdv@sfc.wide.ad.jp>>; Wojciech Kozlowski <w.kozlowski@tudelft.nl<mailto:w.kozlowski@tudelft.nl>>; qirg@irtf.org<mailto:qirg@irtf.org>
Objet : Re: [Qirg] agenda

An interesting question we have waffled about in our design is whether the satellite (or any entangled photon pair source, which we call an EPPS) is part of the link, or a node visible at the network level.  Our current stance is that it’s only part of the link, and can’t be addressed in (e.g.) our connection setup process.  It’s handled instead by a link-layer protocol. Why? Because nodes farther away than the ones receiving those photons never need to send a message to the EPPS.

There are three major link timing regimes:
* meet-in-the-middle, which we call M—>I<—M, memory—>interference<—memory or MIM
* sender-receiver, which we call memory—>memory or MM
* midpoint source, which we call memory<—source—>memory or MSM

Cody Jones et al. (at least one of “al.” is on this list, I believe) did some great analysis on MSM links.
https://arxiv.org/abs/1505.01536<https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1505.01536&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=LlizVuEvLLRZ5oMajpGlgWVy0hziruxRChFw7sdfC8I&e=>

—Rod

[WK] Good point. I am currently finalising the elementary-link generation section with Sara and it will mention this. I agree with you that it would be worth making it clear that the entangled pair source is part of the link even if it is a physically separate entity in the section that defines the elements of the network. I take it for granted, but it's not obvious especially if the mid-point/source is a satellite which is a scenario I keep forgetting about. In that case, I would suggest you wait until I send that update to the mailing list and then you can expand on this point (including the points mentioned in the e-mail above) and refer to that text on the elementary link generation.


> Quantum internet must support the diversity of encoding schemes.



[WK] I'm not enough of an expert to make a judgement on whether this should or should not be part of the draft. I've heard of other encoding schemes before, but not in the context of networks before. Can you explain a bit more about this and if this will be practical in a quantum network context?

[PG]
Quantum states can be implemented by different physical media with different degrees of freedom (DoF) to encode quantum information. A quantum systems can be classified into two categories, depending on the dimensionality of the parameter space that is needed to describe their features accurately. On the one hand, there are quantum features that require a finite dimension.

Light is the most widely used physical medium for communications. It is exploited its different properties (polarization, frequency, angular momentum) and states (Gaussian like coherent state; non-Gaussian like Fock state) to encode quantum information for :


-          entanglement of different states of quantum information.

-          error correction

-          classic information transport

Thus, a quantum state which is represented in a Hilbert Space and can be of finite dimension we will speak of Qubit (Hilbert space of dimension 2) or more generally Qudit (Hilbert space of dimension d), but also of infinite dimension, in this case we will speak of Qumode.

Here it seems that, in a first time, we are rather interested in the notion of Qubit and entanglement of different states of quantum information.

Two-state systems called quantum bits (qubits) can be encoded on the basis of a discrete state (i.e discrete variable) exploiting different degrees of freedom of like spatial, temporal, and polarization (Angular Momentum, Time-bin, Polarization, …). For example with polarization DoF : |ψ> = c0 |H> + c1 |V>

The Qubit can also be encoded on the base of continue state (i.e continue variable). For example, In the domain of continuous variables, a Qubit can be coded as superposition of coherent field: coherent state of light: |ψ> = cα |α> + c-α |-α> or of compressed opposite phases (E.g "Schrödinger cat" states).


As the quantum internet will be a heterogeneous network interconnection all these modes of encoding quantum information must be able to be used

[WK] This is getting too close to physical hardware for this draft in my opinion. Obviously, physical realisation aspects are important, but I would remain wary about how much of that is necessary in this document. Unless other people feel strongly about this, I'm not sure this should be included.
[PG-2] It is no more close to physical hardware than entangled pair source. This concerns the heterogeneity of the communication quantum plan (i.e The counterpart of the data plane of classical networks )  that will make up the quantum internet.  The different form of heterogeneity which in my opinion is not emphasized enough in the document.  The quantum internet will be based on the interconnection of heterogeneous networks.  The heterogeneity will concern different technical facets (support of communication : fiber/free space optics/… , Encoding flying qubit for entanglement  often relies on polarization, energy-time, or time-bin coding,  Harnessing different degrees of freedom to encoding quantum information to form a qudit or a qmode, ….).

In addition it should be noted that the most appropriate carrier and associated encoding observable depend on the specific task you want to do. Photons have been proved suitable to transmit quantum information, and atoms or ions to store and process it. Quantum networks, will contain elementary quantum processors and memories, connected by communication channels, and thus will require quantum interfaces capable of transferring qubit states from one type of carrier to another.







> Need an interconnection protocol to distribute Bell peer between

> autonomous

systems



[WK] Agreed, a brief addition like yours is good. Will include it. Would it be worth adding some mention of potential challenges? Such as one AS having one qubit of the pair and the other AS the other? Without too much detail though.



> Do not prematurely close the door to super dense coding that can be

> used for

example to transport control plane of classical and quantum Network. In this use case the control plane can be seen as a quantum application that consumes quantum bits to realize its functions.



[WK] I'm not sure why you would ever send control information over a quantum channel. In general classical channels will be cheaper and more practical and it would be wasteful to use qubits to send control information (where you need 10s of bits for each qubit you transmit). Could you explain a bit more?

[PG] My resquest is about : quid of the high-dimensional encoding of quantum information (Qudit, Qumode). There are many study on this topic. https://onlinelibrary.wiley.com/doi/full/10.1002/qute.201900038<https://urldefense.proofpoint.com/v2/url?u=https-3A__onlinelibrary.wiley.com_doi_full_10.1002_qute.201900038&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=1dwFov1-yBjn6et2bo8Jy5-QTTO14ZKu0shK4bxNcLE&e=>    Why don’t use it to carrier classical information ? if you were to deploy a quantum network for the first time why don’t use quantum canal to carrier control plan (which does not require a lot of traffic) of quantum Network ?

[WK] I'm still not sure why use the quantum channel to carry classical data. Installing a separate classical channel would be much cheaper and more efficient. If security was a concern, why not just encrypt/authenticate? And I disagree, classical control traffic will not be negligible. Every generated pair will need some amount of metadata sent back and forth to keep track of it and its swaps.
[PG] The research on High‐Dimensional Quantum Communication could also be benefic to increased classical information capacity. For example NEC plans to use wireless Orbital Angular Momentum (OAM) for the fronthaul of 5G cellular networks : https://www.nec.com/en/press/201812/global_20181219_02.html  If it proves relevant, it will be done anyway.

Note that If the cost of a quantum infrastructure will not decrease then, for QKD, this will rather encourage post-quantum solutions to replace the algorithm Diffie-Hellman for  hybrid systems incorporating asymmetric and symmetric algorithms (Key exchange and digital signatures are performed with  post-quantum algorithms and encryption of dat is done using symmetric cipher (e.g block ciphers or stream ciphers).


> Bell pairs are also the basic fundamental unit for building complex

> multi-

partite entanglement state shared among several nodes of the network.



[WK] Agreed, will be included.



Cheers,

Wojtek

_______________________________________________

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=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=Bha1cNqIDcir2fDm_rrOdRjjly2a1vVtqgr4F97Px4I&e=>