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

Wojciech Kozlowski <> Tue, 19 May 2020 13:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B7033A040D for <>; Tue, 19 May 2020 06:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 Rf4TWxwJfbmy for <>; Tue, 19 May 2020 06:28:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 115E83A040B for <>; Tue, 19 May 2020 06:28:56 -0700 (PDT)
Received: from localhost (localhost []) by amavis (Postfix) with ESMTP id 36D3E400A8 for <>; Tue, 19 May 2020 15:28:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id etnhPHHWnxZY for <>; Tue, 19 May 2020 15:28:53 +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 8D6274008D for <>; Tue, 19 May 2020 15:28:52 +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; Tue, 19 May 2020 15:28:46 +0200
Received: from ([fe80::dc7a:a6b8:8bb9:2210]) by ([fe80::dc7a:a6b8:8bb9:2210%13]) with mapi id 15.01.1913.007; Tue, 19 May 2020 15:28:46 +0200
From: Wojciech Kozlowski <>
To: "" <>
Thread-Topic: [Qirg] arch I-D: pull request & comments
Thread-Index: AQHWLaQyrVsKAcW+NkSdtv+Hsw5K7qivRggA
Date: Tue, 19 May 2020 13:28:46 +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: <055274B89C7EB34F9F92A88F07236104@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: Tue, 19 May 2020 13:29:02 -0000

Responses in-line. I am going to put items that require action from me on top
of the TODO items from your 6 March e-mail to handle after updating section 6
which will hopefully be next month.

More details in-line. No comment means I fully agree with your point and have
nothing to add.

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

Thanks! Pretty straightforward. Merged.

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

Shota has submitted a PR about generations which I've been currently
withholding until it becomes clearer what is expected from this section and we
had a bit of a discussion on the mailing list. In general, I agree. We should
add something about generations and what defines them to the draft. The current
state of this PR is here:

I have not reviewed that PR yet, but I have already mentioned what I would like
to see in this section (see

Feel free to add your thoughts either in the PR or on the mailing list.

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

I think clarifying the difficulties around fidelity would be valuable. Will add
something once I sort out section 6.

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

This is a good point and I've been pondering many times about where do the soft
real-time messages belong to. Lately I've been lumping them into the data plane
which sounds in line with your thinking. Will look into clarifying this.

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

Yes agreed. To me, the following items need work:

1. Section 6 needs an update (currently in the process of setting up online
meeting - email coming soon)
2. Add a section on generations (work can start with Shota's PR)
3. Implement your feedback from 6 March e-mail and this e-mail
4. Final editing pass

To me, only items 1 and 2 are what I'd call "major" items which need careful
thought. For item 3, in general I will just implement your feedback. I haven't
done so yet since it covers the entire draft top to bottom so I wanted to have
the core text finalised first in case some of that feedback can be incorporated
with these changes.

> —Rod
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies
> Keio University, Japan
> _______________________________________________
> Qirg mailing list