Re: [Qirg] Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."

Gelard Patrick <Patrick.Gelard@cnes.fr> Mon, 17 February 2020 09:01 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 6ADDE120271 for <qirg@ietfa.amsl.com>; Mon, 17 Feb 2020 01:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 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] 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 5UmggFyc9kRg for <qirg@ietfa.amsl.com>; Mon, 17 Feb 2020 01:01:43 -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 C103412025D for <Qirg@irtf.org>; Mon, 17 Feb 2020 01:01:39 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.70,451,1574121600"; d="scan'208,217"; a="14303746"
X-IPAS-Result: A2GFAAD/VUpe/wUBeApcChkBAQEBAQEBAQEBAQEBAQEBAREBAQEBAQEBAQEBAYF7gSVTMVkTVCESKgqECpEgiWKRWAkBAQEBAQEBAQEqBwMBAgQBAYRAAheBayQ4EwIQAQEBBQEBAQEBBQIBAQICaYRrTAyGOwEBAQECASMKTBACAQUDDRUWAQYDAgICHxEUEQIEAQkEBQgTgwyBfU0DDiAPqkR1gTIUBoQbAQMEg2gNghoGgTiBZYchhTiBEUeCTD5rGQGBFkkBAQIBGYETCS8MCR8CglgygiwEkFmFaZhGMkQHgUF8gk+EfopVhE14gVGMTQMQi3GOaYhwgiqSKCOBWDMaJ0yCbFAYjgYwFxWDO4UUhT9EMAIUgQsIjQcBgQ8BAQ
X-URL-LookUp-ScanningError: 1
From: Gelard Patrick <Patrick.Gelard@cnes.fr>
To: Bruno Rijsman <brunorijsman@gmail.com>, "Qirg@irtf.org" <Qirg@irtf.org>
CC: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
Thread-Topic: Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."
Thread-Index: AQHV27dqo3+VlqWcEEehOQGuC0sc96gWGzQAgALVgMCAAFvogIAF1QoQ
Date: Mon, 17 Feb 2020 09:01:36 +0000
Message-ID: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BF6A6@TW-MBX-P03.cnesnet.ad.cnes.fr>
References: <d755e4fc670c04bffdf1c6b61f060d2c4e26d7dd.camel@tudelft.nl> <0FB02454-AAE3-4084-BBD9-473FE552906F@gmail.com> <0ee348aa0d8f20ae53bc9db5d16de526d7539694.camel@tudelft.nl> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BF016@TW-MBX-P03.cnesnet.ad.cnes.fr> <02570C31-BEC2-4DB4-9F88-252F0D559E70@gmail.com>
In-Reply-To: <02570C31-BEC2-4DB4-9F88-252F0D559E70@gmail.com>
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-25236.005
x-tm-as-result: No--21.867600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BF6A6TWMBXP03cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/p8Jlf2oVsEyg6u2DVMgTHM3rEwo>
Subject: Re: [Qirg] Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."
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: Mon, 17 Feb 2020 09:01:46 -0000

Hi Bruno,

Responses inline

Best Regards
Patrick

De : Bruno Rijsman <brunorijsman@gmail.com>
Envoyé : jeudi 13 février 2020 17:27
À : Gelard Patrick <Patrick.Gelard@cnes.fr>
Cc : Qirg@irtf.org; Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
Objet : Re: Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."

Hi Galard,

Responses inline >>> below.

— Bruno


On Feb 13, 2020, at 5:01 AM, Gelard Patrick <Patrick.Gelard@cnes.fr<mailto:Patrick.Gelard@cnes.fr>> wrote:

Hi Bruno,

Thank you for this clear and interesting presentation which, among other things, highlights the notion of virtual circuit<https://en.wikipedia.org/wiki/Virtual_circuit> to apply it to quantum networks.

Now, to complete the remarks of Wojtek

-          is this notion generic enough to make it a principle applicable to all quantum network architectures solutions (Autonomous System)   that will constitute the quantum internet ?

>>> Yes, I believe so. The core of the discussion is whether we should use a connection-oriented approach (similar to MPLS) or a connection-less approach (similar to IP) for quantum networks.  Both are very general concepts, general enough to cover any type of network, including quantum networks.

>>> I am making an argument that a connection-oriented approach makes more sense for quantum networks. My motivation is that creating end-to-end Bell Pairs at a given rate between two remote end-points is a very stateful distributed computation that requires a lot of a-priori coordination. Quantum networks are *not* in the business of stateless hop-by-hop forwarding of packets. Although I conceded in my response to Woj that it is far too early to preclude a connection-less approach.

>>> For the short term, we will have our hands full with intra-domain routing for quantum networks. That said, regardless of whether we choose a connection-oriented approach or a connection-less approach, we will have to look ahead to inter-domain quantum routing (where we have multiple autonomous systems) at some point in time. So, at some point we will need inter-domain quantum routing protocols, and in the case of a connection-oriented approach, inter-domain quantum virtual circuit signaling protocols.


-          Shouldn't we extend its definition to take the characteristics of quantum networks ?

>>> Absolutely!


o   No label header to identify the quantum virtual circuit.

>>> Indeed, this is one of the most important differences between classical MPLS networks and quantum networks. You cannot push an MPLS label onto a qubit (or any other header for that matter, not even a destination address).

>>> I just realized that I forget to mention the analogy with Generalized MPLS (GMPLS).  In GMPLS we also have a control-plane network that controls a data-plane network that is missing the ability to carry explicit MPLS labels (e.g. wavelengths in a DWDM network or time slots in a SONET/SDH network). I will add a short sentence to this effect in the updated pull request.

>>> In GMPLS networks, we use some implicit “label” (e.g. the DWDM wavelength or the TDM time slot) in lieu of explicit MPLS labels. Similarly, in quantum networks we will need to use some implicit qubit information (e.g. the time slot or the wavelength or the polarization or the which-path information) in lieu of explicit headers.
[PG] Be careful, the degree of indistinguishability of photons<https://www.nature.com/articles/ncomms15506> ( same spatial mode, same temporal mode, same frequency and polarization ) is a crucial parameter for entanglement.

o   The notion of virtual circuit rather identifies an unordered list of quantum nodes (repeater) participating in the generation of Bell pairs (executes the purification and swapping algorithms) than a path to transfers entangled Qubits.

>>> Again agreed. My analogy with MPLS is intended to be rather loose (i.e. not literal). I did not intend to imply that quantum networks will literally do an ordered sequence of MPLS label swaps.  I only intended to imply that some amount of a-priori signaling is needed to install the generalized “rules” (as Rodney calls them) that “control” the distributed computation (the state machines for local Bell pair generations, the swaps, the distillations, etc.) and potentially also to allocate resources.


-          The notion of multipoint to create an entangled graph should also be clarified.

>>> Good point. There is a (very loosely) analogous concept of point-to-multi-point LSPs in MPLS (they are used for multicast)

-          If we can “open” a quantum virtual circuit, we must also be able to close the circuit.

>>> Agreed, both establishment and tear-down are needed (and potentially pre-emption as well).



if the notion of quantum virtual circuit cannot be raised to the rank of general principle then it may be relevant to write a specific draft to  specify this possible solution.

Best regards
Patrick



De : Qirg <qirg-bounces@irtf.org<mailto:qirg-bounces@irtf.org>> De la part de Wojciech Kozlowski
Envoyé : mardi 11 février 2020 16:41
À : brunorijsman@gmail.com<mailto:brunorijsman@gmail.com>
Cc : Qirg@irtf.org<mailto:Qirg@irtf.org>
Objet : Re: [Qirg] Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."

Hi Bruno,

Thanks for your contribution! It's written quite clearly so I have no questions or need clarifications. However, it is quite long and verbose which doesn't fit with concise character of the rest of the draft. The material is good though so worth keeping it around somewhere, but I'm hoping to cut it down a bit for this draft. At the moment it's about 3 pages making it about 10% of the entire content. I suggest we draw out the key points from this analogy for this draft.

Having read the section many times I think it can be split into two separate concepts - signalling + match-action rules, and resource reservation + traffic engineering. I think the latter can be left out from this draft. Variations of the match-action rules concept is pretty present in literature come to think of it (even it it's not called that) and given that the pairs don't carry headers it is the natural approach. Resource reservation + traffic engineering is I think a broader and deeper area.

One thing that would be worth mentioning in this section is to simply answer the question "why are we making this analogy"? My take on it is that the undirected nature of entangled pairs (they don't proceed in a line from source to destination, but rather the whole circuit can work on it at the same time) very much lends itself to some form of a circuit approach with match-action rules closely mimicking label swaps.

At the same time it's also worth pointing out that circuits aren't the only way to go around quantum networking with entangled pairs. For example, in https://www.nature.com/articles/s41534-019-0139-xthe authors do not consider individual circuits, but instead with a correct local strategy, the two nodes will end up with an entangled pair. Of course, this may well have other complications (e.g. how to install these rules if not using circuits), but my point is only that there may well be a variety of approaches so it's worth avoiding language implying that this is the one and only correct way of doing things. If memory lifetimes were good enough and performance was not a concern, hop-by-hop would be entirely possible so it's worth avoiding language implying this is a MUST rather than a very plausible candidate.

I'd probably also skip point 9 about fully centralised vs distributed. It is correct, but I feel like the text doesn't lose anything if you remove it.

Anyway, all of the above is up for discussion though conciseness would very much be welcome either way :)

Thanks,
Wojtek

On Tue, 2020-02-04 at 18:01 -0600, Bruno Rijsman wrote:
I finally got around to generating the pull request for the long-promised new section "Comparison with multi-protocol label switched (MPLS) networks.” for the "Architectural Principles for a Quantum Internet” draft (draft-irtf-qirg-principles-03).

https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_3&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=HG745pqKDMrOuvEGoaOzZ8E5Zcz6AQe7iFqbW3KHBvU&s=16hS14fH5Dg8j-XMAdSPQuHiuTKymyP6Ox-GffCMcgE&e=>

— Bruno