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

Wojciech Kozlowski <> Wed, 30 September 2020 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 413F13A1452 for <>; Tue, 29 Sep 2020 17:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jRb7NKv7LuMk for <>; Tue, 29 Sep 2020 17:23:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05EDD3A144E for <>; Tue, 29 Sep 2020 17:23:47 -0700 (PDT)
Received: from localhost (localhost []) by amavis (Postfix) with ESMTP id 13858CC00E8; Wed, 30 Sep 2020 02:23:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id a0zMUMXzo7Nd; Wed, 30 Sep 2020 02:23:44 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCE63CC00E6; Wed, 30 Sep 2020 02:23:43 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2044.4; Wed, 30 Sep 2020 02:23:36 +0200
Received: from ([fe80::dc7a:a6b8:8bb9:2210]) by ([fe80::dc7a:a6b8:8bb9:2210%13]) with mapi id 15.01.2044.006; Wed, 30 Sep 2020 02:23:36 +0200
From: Wojciech Kozlowski <>
To: Rodney Van Meter <>
CC: "" <>
Thread-Topic: [Qirg] arch I-D: pull request & comments
Thread-Index: AQHWLaQyrVsKAcW+NkSdtv+Hsw5K7qkEq2eAgAM9w4CAeTmtgA==
Date: Wed, 30 Sep 2020 00:23:36 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, nl-NL, en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Qirg] arch I-D: pull request & comments
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Sep 2020 00:23:50 -0000

See in-line marked with [[WK]]

Latest version of draft at: 

-----Original Message-----
From: Rodney Van Meter <> 
Sent: 15 July 2020 01:03
To: Wojciech Kozlowski <>
Cc: Rodney Van Meter <>jp>;
Subject: Re: [Qirg] arch I-D: pull request & comments

Rodney Van Meter
Professor, Faculty of Environment and Information Studies Keio University, Japan

(trimmed to just open questions)

> On Jul 13, 2020, at 6:33, Wojciech Kozlowski <> wrote:
>> 6. "shortest path" is undefined here.  Again, work of ours is
>> relevant: 
>> 06.5655&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3
>> k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUe
>> FaKT0byF8SKqSzWE&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.

[[WK]] Added a brief mention that "least-cost" might mean something else in a quantum network + reference

>> 7. In discussion of rule-based operation, again, work of ours is
>> relevant: 
>> 04.08605&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe
>> 3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sU
>> eFaKT0byF8SKqSzWE&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…

[[WK]] If anything comes up, fell free to just submit a PR

>> 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…

[[WK]] I have now added a new section (5.3.1) to clarify this. 

>> * 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

[[WK]] Added a bunch of these 

> 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.

[[WK]] So, as far as I can tell, these are already mentioned at the end of 5.3.3, just not called "time-skewed".

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.

[[WK]] Haven't added anything on all-optical, but I would need help on this if we are to include something on this subject

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