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

Bruno Rijsman <brunorijsman@gmail.com> Thu, 13 February 2020 16:27 UTC

Return-Path: <brunorijsman@gmail.com>
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 2F861120147 for <qirg@ietfa.amsl.com>; Thu, 13 Feb 2020 08:27:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.437
X-Spam-Level: *
X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 KNra_BPec72H for <qirg@ietfa.amsl.com>; Thu, 13 Feb 2020 08:26:59 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC8B1200C4 for <Qirg@irtf.org>; Thu, 13 Feb 2020 08:26:59 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id g6so2536777plt.2 for <Qirg@irtf.org>; Thu, 13 Feb 2020 08:26:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o0Za7TqRc8Dd93jZQFGtc8yU3+ec41hZmllSFDMRzy0=; b=RcvzpCMpE2z6+3S0YVv6GiMsF/trtoyxZ5thoP/nSeYJVO9AZjtsCwLRhj7f3MUIgG 3Z0NxaHKq2m+rP/mHarzvsXR5YAZxsiYIHvji6ofCc4v8HEGr3glm8BTr/K6M2LDShwh bdt4lFG2V0APc8+kHoQf/DQ1kBLpaPJHU98XtkNORRFpxFsrr/JL9NuOqJw+d0j98L1v WiHrjkIuTlZu5hdtFCHg6fSwS+j+IlhT84W3YT5LrTD28pMF1TiymIDor3fB+EzhgJ3c EMeh/wDWCmfJsxhM9VPFLZY9EFaZ4H7qSBpMiBvU0scuKoghP3i6PKI2mojCggzWZgz5 ZP1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o0Za7TqRc8Dd93jZQFGtc8yU3+ec41hZmllSFDMRzy0=; b=W/ufs9/VZqetMOdQ2frJ8J5HnNeFBtau6QOl2P2x8brkjuUhmS+cl4U/We5bQkoDmA se8Jeb0C+OyGNouB5A66L69oEWPsP2+wkOK0OjC+RLY6KqvGdddMUp7x101w2MJMs14F mX2P+TJ256pbeCTLBmA0wIYQ0qrJ9cbqEdWRnO/xjNQ1BSJGzcvP9YaPHHLFYcYnLAML KBTM4vuMWbAwDJu+xgo0gDXIVa0v3AFKgBk+5aL1xB+TpYz3OKG5SiZxKlcj+M9e/Xww fST+5aO5lCgqOV+xwx+u1Q4wh5+EJD5PGutz3K8/B7HyUTM8t+GAntRq4ntfBLkW6m88 bNzg==
X-Gm-Message-State: APjAAAU67pxKWXqivnt4dZ998d+vuU9WEoWSfQZSS68wFIzxa9cDvtVS 0G9q0L4t5/XsSaurc7ClgIGkRGtq
X-Google-Smtp-Source: APXvYqzGosWer02NgaFM6w5LFkp0Gykl51X8m9wlx9ylA/LiXVGFWAcgqDX0S2u3v+HgCyfO69KLNg==
X-Received: by 2002:a05:6122:48c:: with SMTP id o12mr2495068vkn.35.1581611217746; Thu, 13 Feb 2020 08:26:57 -0800 (PST)
Received: from brunos-macbook.domain.name ([138.94.252.66]) by smtp.gmail.com with ESMTPSA id l21sm932123vsi.1.2020.02.13.08.26.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 08:26:57 -0800 (PST)
From: Bruno Rijsman <brunorijsman@gmail.com>
Message-Id: <02570C31-BEC2-4DB4-9F88-252F0D559E70@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AC6FDAF1-A18B-47BA-8A72-62D030856635"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 13 Feb 2020 10:26:55 -0600
In-Reply-To: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA05BF016@TW-MBX-P03.cnesnet.ad.cnes.fr>
Cc: "Qirg@irtf.org" <Qirg@irtf.org>, Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
To: Gelard Patrick <Patrick.Gelard@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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/LRW2MCGT4MAI3TiDuh0gMta8F_Y>
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: Thu, 13 Feb 2020 16:27:01 -0000

Hi Galard,

Responses inline >>> below.

— Bruno

> On Feb 13, 2020, at 5:01 AM, Gelard Patrick <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.

> 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> De la part de Wojciech Kozlowski
> Envoyé : mardi 11 février 2020 16:41
> À : brunorijsman@gmail.com
> Cc : 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-x <https://www.nature.com/articles/s41534-019-0139-x>the 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