Re: [Qirg] [Fwd: [Fwd: Re: draft-irtf-qirg-principles: goals and principles]]

Wojciech Kozlowski <> Tue, 28 July 2020 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADDF43A0AAF for <>; Tue, 28 Jul 2020 03:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 a-fxe6pANzON for <>; Tue, 28 Jul 2020 03:43:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03F2D3A0AAC for <>; Tue, 28 Jul 2020 03:43:52 -0700 (PDT)
Received: from localhost (localhost []) by amavis (Postfix) with ESMTP id CB565CC00C3 for <>; Tue, 28 Jul 2020 12:43:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id AzXJLPKAb9Yj for <>; Tue, 28 Jul 2020 12:43:48 +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 B2737CC00BA for <>; Tue, 28 Jul 2020 12:43:47 +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, 28 Jul 2020 12:43:42 +0200
Received: from ([fe80::dc7a:a6b8:8bb9:2210]) by ([fe80::dc7a:a6b8:8bb9:2210%13]) with mapi id 15.01.1913.007; Tue, 28 Jul 2020 12:43:42 +0200
From: Wojciech Kozlowski <>
To: "" <>
Thread-Topic: [Qirg] [Fwd: [Fwd: Re: draft-irtf-qirg-principles: goals and principles]]
Thread-Index: AQHWPlTxBQ9mlf9Gx0W8l8T+KqzD/KjQQFaAgDRHrICAF0NVgIABLlwA
Date: Tue, 28 Jul 2020 10:43:42 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, nl-NL, en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_974013d2954276cc15150bc7b7767c14de43a251cameltudelftnl_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Qirg] [Fwd: [Fwd: Re: draft-irtf-qirg-principles: goals and principles]]
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, 28 Jul 2020 10:43:59 -0000

Thanks for your comments! I will incorporate them shortly after the IETF meeting, but I thought I'd reply to some of your questions below in-line


On Mon, 2020-07-27 at 10:41 -0600, Joey S wrote:
Dear QIRG,

In section 6.1. Goals of a quantum internet, in a similar way to this quote on point 2,
>>It should not be constrained due to considerations for early-stage hardware and applications

I think point 5.  Make them easy to monitor,
>>In order to manage, evaluate the performance of, or debug a network it is necessary to have the ability to monitor the network.
should/could include "while ensuring there'll be mechanisms in place to protect the confidentiality and integrity of the devices connected to it".

This would be so as not to repeat the limitations we currently deal with in, say, the DNS, which having been designed as an unencrypted point for control and administration, has suffered heavy exploitation and continues to be a source of debate on how to make it more secure now, decades after its design.

>>Furthermore, given one end of an entangled pair, it is impossible to tell where the other qubit is without any additional classical information.
Would there be a need for some type of metadata then? or duplicate qubits for monitoring purposes?

>>This implies that tracking entangled pairs necessitates some exchange of classical information.
Some definition on what classical information would need to be exchanged would also be good.

On point 6.  Ensure availability and resilience, and mostly out of curiosity, are there any projections/estimates on where will quantum networks be available? Will the implementation/deployment costs be too high so as to restrict its access/use to developed countries? or is it foreseeable that at some point all sectors of society could benefit from it?

These networks are expensive to deploy. Whilst they will be able to reuse a lot of our fibre infrastructure the hardware at the nodes (potentially including satellites) needs to be quantum-enabled and a lot of it is still in the experimental stage. However, the classical Internet didn't just appear overnight either.

QKD deployments already exist (networks that can run Quantum Key Distribution and nothing else) on metropolitan scales. There is work to extend this distance using satellites and trusted nodes (intermediate nodes must be physically secure). QKD is currently mostly of interest in sectors that require high levels of long lasting security for their communication (e.g. finance, data centres, government, critical infrastructure). However, it's still a pretty open question as to which sectors beyond the obvious candidates will benefit from QKD networks. With QKD there is always the question of whether post-quantum cryptography would be sufficient which does not require new physical infrastructure.

Quantum networks beyond QKD (what this RG is mostly interested in) are still being worked on. A demo network is being built in the Netherlands and should be going online within the next few years. For more information about applications, timelines, etc. in an accessible write-up: The US has also recently published a document on their blueprint for a national QI: It is likely that these networks have a potential to benefit all sectors of society as the Quantum Internet Magazine linked above mentions several interesting applications (such as secure voting, quantum digital signatures, anonymous transmission, quantum enhanced GPS), but as the systems are still being researched it's hard for me to say when, how, and at what cost that will happen.

Lastly, in section 8.  Security Considerations
>>Even though no user data enters a quantum network
Could I be pointed to references that explain this part please? Is user data confined to classical channels? Apologies if that's already somewhere in this draft and I missed it.

Yes, there is some extra explanation in the teleportation section (4.3):

The unknown quantum state that was transmitted was never fed into the  network itself.  Therefore, the network needs to only be able to reliably produce Bell pairs between any two nodes in the network. Thus, a key difference between a classical and quantum data planes is that a classical one carries user data, but a quantum data plane provides the resources for the user to transmit user data themselves without further involvement of the network.

I will add a reference to section 4.3. Might also be worth mentioning a caveat that with 3G networks one could transmit quantum data through the network without teleportation (though you would first have to answer the question of why not use teleportation).

This is not the first time this sentence has appeared confusing so I will try to fix that.

Thank you all,


Joey Salazar

Digital Sr. Programme Officer


6E9C 95E5 5BED 9413 5D08 55D5 0A40 4136 0DF0 1A91

On 12-Jul-20 3:26 PM, Wojciech Kozlowski wrote:
Dear QIRG,

I have updated the doc following the feedback received at the interim meeting. You can find the latest version here:

Relevant GitHub commit:


On Tue, 2020-06-09 at 15:04 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

Please find the minutes from todays meeting:<>
Blue sheets:<>

If you have any remarks as to the above, please let me know and I'll upload a revision.

My next step will be to include all the points raised in the meeting + some that were raised on the mailing list over the past few months (including Shota's generation PR).

I will write a separate e-mail about the discussion we agreed to take to the mailing list.


On Tue, 2020-06-09 at 11:56 +0000, Wojciech Kozlowski wrote:
5 miutes

On Tue, 2020-06-09 at 07:21 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

Reminder that this call is today at 12:00 UTC.

draft link:<>
WebEx link:<>
Calender event: attached


-------- Forwarded Message --------
From: Wojciech Kozlowski <<>>
To:<> <<>>
Subject: [Qirg] [Fwd: Re: draft-irtf-qirg-principles: goals and principles]
Date: Wed, 03 Jun 2020 10:07:14 +0000

Dear QIRG,

A reminder that there is a virtual interim call next week (9 June 12:00 UTC) to discuss section 6 of the Architectural Principles draft:<>
WebEx link:<>
Calender event: attached

The aim of this call is to step over section 6, review existing points, discuss, and suggest any additions. Experienced advice from people who helped build/witnessed/understand the current Internet architecture and its evolution would be very useful. This section is less about quantum, but more about how to correctly apply the lessons from the classical Internet to the Quantum Internet.

This is the last item that needs a discussion. Following this call I plan to include the feedback that's still waiting on my todo pile (including the generations pull request from Shota) and prepare a final version for top-down review by July.

A summary of the current content is below. Actual content is:<>

6.1.  Goals of a quantum internet

   1.  Support distributed quantum applications
   2.  Support tomorrow's distributed quantum applications
   3.  Support hardware heterogeneity
   4.  Be flexible with regards to hardware capabilities and limitations
   5.  Ensure security at the network level
   6.  Make them easy to manage and monitor
   7.  Ensure availability and resilience

6.2.  The principles of a quantum internet

   1.  Bell Pairs are the fundamental building block
   2.  Bell Pairs are indistinguishable
   3.  Fidelity is part of the service
   4.  Time is part of the service


-------- Forwarded Message --------
From: Wojciech Kozlowski <<>>
To:<> <<>>
Subject: Re: [Qirg] draft-irtf-qirg-principles: goals and principles
Date: Tue, 19 May 2020 15:03:57 +0000

I have scheduled a virtual meeting on June 9 at 12:00 UTC. Below are the call details and a calendar event is attached.

Agenda: Review section 6 of draft-irtf-qirg-principles<> and discuss possible additions

draft-irtf-qirg-principles: goals and principles
Hosted by Quantum Internet Research Group

Tuesday, Jun 9, 2020 5:00 am | 1 hour | (UTC-07:00) Pacific Time (US & Canada)
Meeting number: 617 400 539
Password: a37wSAQ2DDZ
Agenda: Review section 6 of draft and discuss possible additions<>

Join by video system
You can also dial and enter your meeting number.

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 617 400 539

On Fri, 2020-05-15 at 08:18 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

A reminder to fill out your availability for a call about the Architectural Principles draft:<>

A bit of background on what I want to do here:

Sections 1-5 set the scene as to what quantum networks are, how they function, etc. Section 6 is about looking forward. Given that we know the building blocks, what do we actually want to build with them? What matters more, what matters less? What should one keep in mind when designing protocols?

My inspiration for section 6 is the following paper by David Clark "The Design Philosophy of the DARPA Internet Protocols":<>

And the following RFC:<>

As RFC 1958 shows this need does not need to be an extensive section, but it's a good place to think a bit how the challenges introduced in the first few sections translate into protocol design.

This section will definitely benefit from protocol design/implementation experience.


On Tue, 2020-05-12 at 17:42 +0000, Wojciech Kozlowski wrote:
Hi all,

Added two more dates for additional flexibility: June 9 and June 10 (same times). So the meeting options are now June 2, 3, 9, or 10.

Doodle link:<>


On Tue, 2020-05-12 at 16:47 +0000, Wojciech Kozlowski wrote:
Dear QIRG,

To make progress on the Architectural Principles draft one last item of work remains which is section 6: goals and principles. Most of the document is informative and more of a review in content. However, this section allows us to bring some innovative and fresh ideas to the table and it would be great if as the QIRG we could try and do that.

The section is already non-empty so what I'm looking for is to

  *   go over what's currently written and review it
  *   discuss any further additions to both goals and principles

Anybody who has read and understood the contents of the draft so far should be able to contribute. Experts in network system design particularly welcome.

As this was meant to be a side meeting in Vancouver, to make progress I would like to organise a 1 hour long virtual meeting on either June 2 or June 3. If you would like to contribute, please fill out your availability using the link below by Monday May 18. For those for whom the time chosen might not be convenient, we will make sure the session is recorded.<>

Once this section is complete, the draft will go through some editorial updates + an update on 3 repeater generations currently also in the works. If possible, this might make the draft ready for the next stage by IETF 108.



Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>


Qirg mailing list<>