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

Wojciech Kozlowski <> Sun, 12 July 2020 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B75963A0893 for <>; Sun, 12 Jul 2020 14:33:49 -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 Oget5V0hGeF9 for <>; Sun, 12 Jul 2020 14:33:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E97A13A088A for <>; Sun, 12 Jul 2020 14:33:46 -0700 (PDT)
Received: from localhost (localhost []) by amavis (Postfix) with ESMTP id A9A442400CA for <>; Sun, 12 Jul 2020 23:33:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id yFACbMJrULA6 for <>; Sun, 12 Jul 2020 23:33:43 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 088622400BB for <>; Sun, 12 Jul 2020 23:33:42 +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.1913.5; Sun, 12 Jul 2020 23:33:40 +0200
Received: from ([fe80::dc7a:a6b8:8bb9:2210]) by ([fe80::dc7a:a6b8:8bb9:2210%13]) with mapi id 15.01.1913.007; Sun, 12 Jul 2020 23:33:40 +0200
From: Wojciech Kozlowski <>
To: "" <>
Thread-Topic: [Qirg] arch I-D: pull request & comments
Thread-Index: AQHWLaQyrVsKAcW+NkSdtv+Hsw5K7qkEq2eA
Date: Sun, 12 Jul 2020 21:33:40 +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-ID: <BA9041B05DF8464FB413E4E7D96FC9BA@forest.intra>
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: Sun, 12 Jul 2020 21:33:50 -0000

Hi Rodney

So finally got around to addressing your comments. See in-inline.

Note that I actually had two e-mails from you in the pipeline. Since some
points were raised in both e-mails I simply appended the older e-mail at the
bottom and also addressed the comments in-line.


On Tue, 2020-05-19 at 15:09 +0900, Rodney Van Meter wrote:
> <chair hat off>
> <individual contributor hat on>
> Wojtek et al.,
> A pull request for the architecture I-D awaits you at
> (I didn't generate the .txt from it, I figure it's generally better
> for such generated files that are stored in git to be managed at one
> node.)
> I went through the I-D and made a number of small changes; I doubt
> anything will need discussion but please check.  Almost all edits are
> for clarity, spelling or grammar.  I modified the Muralidharan
> reference to the right "generations" paper, and I added Sutor as a
> reference for beginners.  (I really do think that's an excellent
> beginner's book on quantum computing, with the dead-minimum
> assumptions of background in CS, math and physics, as opposed to Mike
> & Ike, which can be a steep climb.)

PR was accepted

> A number of things occured to me while reading, some of which we've
> probably covered before:
> 1. My memory fails me -- in the section on network boundaries, we
> previously had a discussion of how much to cover the different types
> of logical networks (1G, 2G, 3G), didn't we?  What did we decide?
> Personally, I think it's _critical_ in a document like this, intended
> to be long-lived and set the direction for the network architecture,
> to acknowledge that not only are there physical differences and
> administrative boundaries, but there are important distinctions in how
> errors will be managed, which affects the content and semantics of
> messages that must cross those boundaries, as well -- both for
> connection setup and real-time operation.

This has been included through w PRs from Shota. See latest doc version now.

> 2. Assessment of fidelity is a statistical thing, requiring constant
> monitoring and the sacrifice of generated Bell pairs for tomography or
> other methods.  Should we clarify this?  At the moment, fidelity is
> mentioned but where it comes from is not.

Added the clarification.

> 3. Mentions QKD as depending on Bell pairs, which is not exactly true for
> BB84.  Also, E91 and BBM92 are probably worth citing as better
> instances of entanglement-based QKD.

Good point. Cited Ekert paper, but didn't explain it in words as I'm worried it
might detract from the main point of the text.

> 4. This (and some of the surrounding paragraphs) needs work:
>            It turns out that as long as the underlying implementation
>            corresponds to (or sufficiently approximates) theoretical models
> of
>            quantum cryptography, quantum cryptographic protocols do not need
>            the network to provide any guarantees about the authenticity,
>            confidentiality, or integrity of the transmitted qubits or the
>            generated entanglement. Instead, applications, such as QKD,
>            establish such guarantees using the classical network in
> conjunction
>            with he quantum one. This is much easier than demanding that the
>            network deliver secure entanglement in the first place.
>            <vspace blankLines="1" />
> This could cite Satoh on quantum network security; AFAIK, our work on
> the security of repeater network operation remains the world's only
> work on the topic.  One or both of

Done, both refs included.

> 5. We have discussed Bell pairs as the primary service provided by the
> network, but it may be worth mentioning that multi-party states are
> useful, and may be generated either by applications operating
> end-to-end or by the network itself as a service.  There are a number
> of uses of multi-party states documented in the literature, but only
> Clement, Damian and Frederic Grosshans on how to create them, I
> think.


> 6. "shortest path" is undefined here.  Again, work of ours is
> relevant: 

In what sense is "shortest path" undefined. Could you elaborate?

> 7. In discussion of rule-based operation, again, work of ours is
> relevant: 
> (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.

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

> I don't think the document is close to ready for last call yet, but it
> has made a lot of progress.  I think we can put serious discussion of
> the document onto the agenda for July, with the hopes of publishing
> soon after.
> —Rod
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies
> Keio University, Japan
> _______________________________________________
> Qirg mailing list

On Fri, 2020-03-06 at 09:17 +0900, Rodney Van Meter wrote:
> Wojtek,
> About two weeks ago, I started working on a list of things I’d like to see in
> the draft, but I’m afraid I’m not going to be able to turn them into text and
> an actual pull request by Monday. My apologies.  A few are absolute nits, a
> few are rather big.
> Put these on your TODO list, and maybe we can find time to work on them
> together F2F sometime during the week in Vancouver?
> Comments for Wojtek on QIRG architecture I-D:
> * 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.

> * needs to talk about logical differences at network boundaries
>   (differences in error management parallels the other two very well)
> * should cover 1G, 2G, 3G

Both points are now addressed under "Error management" and in network
boundaries section thanks to Shota's PR.

> * "support tomorrow's dist q apps" is time-sensitive, and why
>   is it different from the apps just above it?

This point is addressed as goal/principles have been rewritten.

> * does doc accommodate all-optical links or paths?

Not at the moment. Do you think it should? What would you propose?

> * does doc describe 1G as a distributed computation?
>   - important corollary: state along the path v. stateless forwarding
>   - equally important corollary: resource reservation/multiplexing

The "Comparison to classical networks" section does mention "stateful
distributed task". This section does cover your two corollaries as well.

> * just a shade more on apps, as parallel I-D is developing

This will be in use-case doc which is now cited.

> * describe time-skewed Bell pairs

I don't know what this is. Could you elaborate?

> * "Therefore, we cannot use the same methods known from
>    classical computing for the purposes of error detection and
>    correction." ==> without modification, though both codes derived
>    from classical and wholy unique to quantum are known (cite Simon?)
>   Overall, this paragraph needs work to be both more accurate and
>   clearer.
>   reconcile w/ later ACK that QEC exists


> * "through a variety of checksums" -- not entirely accurate.
>   how about "through both error detection and error correction mechanisms"?


> * section on direct transmission needs work
>   --> make it a subsection of 4.1, titled "inadequacy of direct
>       transmission"?


> * "challenges" v. "new challenges" is awkward

Fixed, by just having "challenges". Though admittedly some creativity in section titles would not hurt.

> * use the name "Dirac's ket notation"
>   (makes it easier for neophytes to find)


> * expand CNOT first time it's used

Done (in your PR I believe)

> * connection architecture v. network architecture

I've though about this, but I don't think this is material for this draft.
Connection architecture is getting close to specific protocols.