Re: [Qirg] multi-partite entanglement

Bruno Rijsman <brunorijsman@gmail.com> Thu, 21 November 2019 08:38 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 5AF0D12094E for <qirg@ietfa.amsl.com>; Thu, 21 Nov 2019 00:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 58fb_Fk_5PZp for <qirg@ietfa.amsl.com>; Thu, 21 Nov 2019 00:38:07 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 3CBDB120801 for <qirg@irtf.org>; Thu, 21 Nov 2019 00:38:07 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id n188so745572wme.1 for <qirg@irtf.org>; Thu, 21 Nov 2019 00:38:07 -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=t98ysYHo5jQ3WrdmPKfkLWfldhOz02tQD7dzWLWVvFQ=; b=Cd99XdOhT/jyVu3i6/OEwGQuw+SszvJ/l20EJPvsXv6VfUunq5TBEBWGTEdYA3ohK6 /fyNITnYcs+j6VntQuJqoN4680GPTCaEUhrg1fg52NKr1CdI0o5D9VKoF8unMMfNfu+7 PEcczbK0g31OSbJNst01NFWBScBln83U9cVraye4MFqVta5rQZQEku9sFxz41zVskO5g KbIiRUazxnMjiknCwH+Vdml2spV/zVuuzkiaroOqHdLVEiMZ6X55ynU01Ppefopv4HFr DwYImPcNDLrBXetxaBvyyiPr7APQbiN1vz7AWAmff1DH0BpS6OFDMzYx6ft1GUJDEdN1 /zoQ==
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=t98ysYHo5jQ3WrdmPKfkLWfldhOz02tQD7dzWLWVvFQ=; b=LsTW8rWJJqq/OtRPdfz8x9oZ8WsWli3+Ccd5uMFSQYLLvN7qj70k6/9+611kgEokgV ssl67CiHDBphuv9RQs7qbJK6DDrn0ZfN/q18EPCEO4pIM7VW+hQSxV94rlTy7dg+ut9R VKdK6bnII+m5WEteemPrESsKshusLOyvEcEOhcjfCviYLkaD0J+gR3PTX1MZ5FRm8pEY 5JhBkqTPfk0JvWxQR424SA8JYPeAdeM0skLA1Yy37dO1Y26jgvX90JK61DIhYVHvGqux zjvo9YDvHSJ4Mhce8/FUT3KtnrnmklCGbIxgSGg8pfG0fwJmnKQ9Wx9Wvj7biaJNCgBN SF4A==
X-Gm-Message-State: APjAAAWOqHHLcL80d65R6AwSX5A/uGUeO+HmOgTNPsTyAIz+ehoFrPAE /Hny9fYiOpqM6NqPxfVEUCU=
X-Google-Smtp-Source: APXvYqwoRHbjt8INWWvjXorplPF/huvz9hybR+SMsPKEmyecckuS7GUJSuAHhUCyeC6AOKy05dAzXw==
X-Received: by 2002:a7b:c747:: with SMTP id w7mr8742802wmk.62.1574325485565; Thu, 21 Nov 2019 00:38:05 -0800 (PST)
Received: from brunos-macbook.ws.tudelft.net (x032197.tudelft.net. [131.180.32.197]) by smtp.gmail.com with ESMTPSA id l16sm2018928wme.43.2019.11.21.00.38.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 00:38:04 -0800 (PST)
From: Bruno Rijsman <brunorijsman@gmail.com>
Message-Id: <D5C2E51D-6672-4606-85CA-CCFE6A7FE5A9@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_865D2FB7-3FD7-4C76-9B79-0B26565E1DFB"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 21 Nov 2019 09:38:03 +0100
In-Reply-To: <DA2DF71A-26D8-45EB-BD46-FF536DC77F9D@sfc.wide.ad.jp>
Cc: qirg@irtf.org, Rodney Van Meter <rdv@sfc.wide.ad.jp>
To: Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>
References: <DA2DF71A-26D8-45EB-BD46-FF536DC77F9D@sfc.wide.ad.jp>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/SjD5i_vBrLiLFQZp8mpEw99HZWY>
Subject: Re: [Qirg] multi-partite entanglement
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, 21 Nov 2019 08:38:09 -0000

The classical equivalent to quantum multi-partite entanglement signaling is point-to-multipoint (P2MP) label switched paths.See, for example, slide 15 in this presentation: https://archive.nanog.org/meetings/nanog49/presentations/Sunday/P2MP.pdf <https://archive.nanog.org/meetings/nanog49/presentations/Sunday/P2MP.pdf>  In the classical case, the head-end or a centralized controller computes the path.  The middle and tail nodes don’t have to do anything more complicated than allocating resources (in-labels), programming the data plane (MPLS swaps), and signaling. They don’t have to do anything remotely similar to rule-set computation.

You are correct to say that in a quantum network it is unlikely that the end-points of the P2MP graph have enough global information or computational power to compute the optimal rule-set for the entire graph. This indeed feels like a case where a logically centralized controller would have to compute the rule-set as well as the path of the spanning tree P2MP graph (this would be “quantumgoodduckduckgfogle.com in your example, although in practice the controller would more likely be run by the same organization as the one that runs the network itself.)

— Bruno

> On Nov 20, 2019, at 9:13 AM, Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org> wrote:
> 
> I did some thinking about this last night and tonight.  I realized that the approach we’ve proposed for bipartite won’t work.  We propose that the information for planning be accumulated on the outbound leg from the initiator to the responder, then the RuleSets constructed at the responder, and the RuleSets distributed on the return leg.  One of the nice things about this is e.g. if you’re a user and you want to connect to quantumgooduckduckgogle.com, then one of quantumgooduckduckgogle.com’s potential value adds business-wise is the ability to do a better job of connection planning than you as an individual can, or better than duckgooduckquantum.com can, and they can upgrade that ability autonomously.
> 
> With one initiator and multiple responders, obviously that doesn’t work.
> 
> But the multi-partite process is *SO* complex; for example, you may be better off building a Steiner tree on a graph, whereas the initial request by the initiator might follow a set of (partially overlapping) two-terminal paths.  So how do you pick the path, collect the information about the links & nodes, perform the planning, and distribute?
> 
> I want bipartite and multipartite to be separate also because of the difficulty of getting enough people to understand and review even the two-party operation, and because multi-party state generation in an experimental network is still much farther away.  I want the mechanism we are defining here to be used by those building networks (e.g., Delft), and a more complex protocol is less likely to be adopted.
> 
> —Rod
> 
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies
> Keio University, Japan
> rdv@sfc.wide.ad.jp
> 
> 
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg