Re: [Qirg] arch I-D: pull request & comments

Rodney Van Meter <rdv@sfc.wide.ad.jp> Tue, 14 July 2020 23:03 UTC

Return-Path: <rdv@sfc.wide.ad.jp>
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 061D23A09D3 for <qirg@ietfa.amsl.com>; Tue, 14 Jul 2020 16:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sfc.wide.ad.jp
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 yisPRr6m6U6o for <qirg@ietfa.amsl.com>; Tue, 14 Jul 2020 16:03:35 -0700 (PDT)
Received: from mail1.sfc.wide.ad.jp (mail1.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:133]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88ABA3A09BE for <qirg@irtf.org>; Tue, 14 Jul 2020 16:03:35 -0700 (PDT)
Received: from vanmetedneysmbp.fletsphone (69.10.30.125.dy.iij4u.or.jp [125.30.10.69]) (Authenticated sender: rdv) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id E7EF58FF1; Wed, 15 Jul 2020 08:03:29 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1594767811; bh=LXAd6rxn42lTAjhZ+7hxFXjOoPz+IfQqkhXY2cfGxeE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=E9POyZWmJ54kHZ8YN6Lqh2bmADE5f/cP0wahItaIUrqZpoyLv8+1r5N4ecbTGl0Rs RiD29T0CqNiLJ3bO5DoaQoWnWP5wBTG5G/u/Ncwe6m99jpFM4GK/1DWPwge0/s18Jf yWU0657FxcgF2DRfbb3PAA4wQN8nut9/bPbPuXuApfW4Wn+V7lkG3yrtZzd2sX1T5f Pe2SqYykk62GAFFTFEmtDLyQpTiGh4Kby5Yrfsft2mKBMKZUP6eA363zeH4sNztlI6 Ziu2cogyXZ3Wb5xz0vfiXgcZ4gIG7AFNnd7g04mBSy8r29+QKLGMfhEmSSv/IZu7XO PFJ8l9Pby0pdA==
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Rodney Van Meter <rdv@sfc.wide.ad.jp>
In-Reply-To: <5543d40967778dcd33f3aa8f5cdd329f52036f44.camel@tudelft.nl>
Date: Wed, 15 Jul 2020 08:03:29 +0900
Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp>, "qirg@irtf.org" <qirg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F8FD0AD-4814-4E2C-A905-42971E59E557@sfc.wide.ad.jp>
References: <553672B6-E4C5-4537-8916-E2B1F200A362@sfc.wide.ad.jp> <5543d40967778dcd33f3aa8f5cdd329f52036f44.camel@tudelft.nl>
To: Wojciech Kozlowski <w.kozlowski@tudelft.nl>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/U4-v-mMMnrxRpASKVe-mhH0MSWI>
Subject: Re: [Qirg] arch I-D: pull request & comments
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, 14 Jul 2020 23:03:38 -0000

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
rdv@sfc.wide.ad.jp

(trimmed to just open questions)

> On Jul 13, 2020, at 6:33, Wojciech Kozlowski <w.kozlowski@tudelft.nl> wrote:
> 
>> 6. "shortest path" is undefined here.  Again, work of ours is
>> relevant: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1206.5655&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=5CZHrVvCzrqIE5WlMt53hX0WAA0H7gTARE-g4zWoR3Y&e=
>> 
>> 
> 
> In what sense is "shortest path" undefined. Could you elaborate?

OSPF deliberately treats link cost as a unitless scalar, allowing any network operator to use the cost to establish policy as they choose. However, a common goal is minimization of the workload of the entire network, so that resources are used efficiently. This can be achieved, at least approximately, by setting the link cost relative to the bandwidth — using a high-bandwidth link is “cheaper”.  (Note that even though we call it “shortest path”, it’s not shortest in distance or even in the latency you would see on an otherwise idle network, though it may come close to minimizing latency on a heavily loaded network.)

Without some discussion, we have no concept of what “shortest” or “cheapest” means in a quantum network.  We defined a goal of the network to be maximizing the throughhput, measured in Bell pairs per second *of a particular fidelity*, then chose a meaning for the link metric (seconds per Bell pair of a particular fidelity) and evaluated how good a job simple summation of per-hop metrics does in maximizing that E2E throughput.  (Pretty good, as it turns out.)

So of course SPF continues to function as an abstract mathematical thing, but operationally what are the goals of _using_ SPF and how do we achieve it?

Maybe that’s a separate or secondary document in terms of analysis, but I think it’s an open question that needs to be addressed.

> 
>> 7. In discussion of rule-based operation, again, work of ours is
>> relevant: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1904.08605&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=RZE6ErezqKuvt7bPhzr6A7xV3ilHq0krX0EcYpQyadA&e=
>> 
>> (I _know_ it sounds like I'm citing "cite me" a lot, but this _is_ the
>> field we have been working for over a decade to establish, and we've
>> covered a lot of ground in that time, and my students and postdocs
>> deserve some recognition for the work they have done that is, or
>> should be, influencing these documents and designs.)
>> 
> 
> Not sure where to insert the ref though. If you could point out a location or
> submit a PR that would be great.

Mmm, back when I wrote this, I had somewhere in mind, but that’s long gone from my mind now…

> 
>> 8. The use of "control plane" and "data plane" here might differ a bit
>> from standard networking use.  "Control plane" usual refers to routing
>> and management traffic, path setup for MPLS, etc. but here it refers
>> to soft real-time messages that are part of the entangled state
>> creation process, essentially the equivalent of packet headers and
>> SYNs and ACKs in TCP/IP.  I'd argue that's closer to data plane than
>> control plane.
> 
> I 100% agree with this point, but I'm not sure if this point needs clarifying
> in this doc. We actually do not define a control/data plane split in this doc.

“control” or “control information” and “the two planes” are used a *lot* in this document, but I’m worried that the usage here differs enough from e.g. SDF control plane or routing and management traffic that it will confuse people. You wouldn’t call a TCP ACK “control plane information”, so is it right to call entanglement success/failure messages “control plane”?  Is there another term we can use?  I don’t have a good suggestion this morning…

>> 
>> 
>> * overall, the flow and structure are much better than -00. I
>>  particularly like 6.2 now, though I'm not sure it's finished yet.
>> * additional refs:
>>  - Dur group (Pirker, Zwerger)
>>  - (more stuff from us, e.g. my book?)
>>  - Kimble
>>  - Mark Wilde
>>  - Jones on links?
>>  - all-optical?
>>  - triangle inequality for routing
>>  - Riefel
>>  - Simon on QEC
>>  - Dur review of purification
>>  - distributed algorithm zoo
>>  - something from Pan?
>>  - Broadbent
>>  - Gottesman
>>  - Wootters, Park, Ortigoso on no-cloning
> 
> 
> References are still TODO. Hopefully the last TODO.
> 
>> * needs a little wordsmithing here and there at some point
> 
> Generally addressed through all the fixes since this e-mail.
> 
>> * security needs work
> 
> Language slightly improved, but let me know if you would like to see some more
> substantial changes.
> 

Will check.

> 
>> * describe time-skewed Bell pairs
> 
> I don't know what this is. Could you elaborate?
> 

Some people (e.g. Bill Munro — Bill, are you lurking on this mailing list?) worry about the philosophical implications of *when* the two halves of the Bell pair arrive at the destination.  If the network is building a Bell pair between you and me, and my half arrives 10msec before yours, and I measure my half before yours even arrives, did we ever really have entanglement between the two of us?  Mostly it’s a philosophical point, I think, but it can affect loophole proofs.

Keep this one on your list for later; I’m not ready to discard it but don’t think it needs to be done right away.  May decide to discard att some point, though.

Oops, there was a question about all-optical here that I deleted in editing…

Keep “review for whether all-optical is excluded by the language” on your TODO list before we finalize things.

This email is written before I’ve completely read the -04 draft, so I may have more comments by the time of the meeting.

—Rod