Subject: [Qirg] renewing I-Ds: comments, please!

From: Rodney Van Meter <[email-masked]>
Date: Tue, 3 Sep 2019 07:37:29 +0900

Those of us who submitted I-Ds before the March meeting are facing expiration in a week or so.  While there was truly excellent discussion during the meeting in Prague, <personal hat on>off the top of my head, I don’t recall specific feedback on my I-D on connection setup.

The following draft will expire soon:

Name:     draft-van-meter-qirg-quantum-connection-setup
Title:    Connection Setup in a Quantum Network
State:    I-D Exists
Expires:  2019-09-12 (in 1 week, 2 days)
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/ <https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/>

<personal hat off, chair hat on>
In addition to ours, Wojciech’s architectural principles, which I consider a very valuable document, is set to expire:
https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/ <https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/>

The other two QIRG documents,
https://datatracker.ietf.org/doc/draft-kaws-qirg-advent/ <https://datatracker.ietf.org/doc/draft-kaws-qirg-advent/>
https://datatracker.ietf.org/doc/draft-dahlberg-ll-quantum/ <https://datatracker.ietf.org/doc/draft-dahlberg-ll-quantum/>

were updated shortly after Prague, and hence have a few weeks’ more runway, but will also expire before Singapore if not renewed.

Comments on all four documents are appreciated!
<all hats off>

Thanks, and see you in Singapore,

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[email-masked]

---

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 3 Sep 2019 07:45:19 +0000

Hi Rodney (and QIRG),

Thanks for the reminder! I've had an updated version ready for a while (with all the feedback I received - thank you all who did) with some extra notes to spur discussion, but I got caught up in a flurry of other activity (and holiday) since May. I will submit an updated version Friday/next Monday.

From your e-mail I infer QIRG is planning to meet in Singapore so I will set some goals to aim for for the meeting.

Thanks,
Wojciech

On Tue, 2019-09-03 at 07:37 +0900, Rodney Van Meter wrote:
Those of us who submitted I-Ds before the March meeting are facing expiration in a week or so.  While there was truly excellent discussion during the meeting in Prague, <personal hat on>off the top of my head, I don’t recall specific feedback on my I-D on connection setup.

Name:     draft-van-meter-qirg-quantum-connection-setup
Title:    Connection Setup in a Quantum Network
State:    I-D Exists
Expires:  2019-09-12 (in 1 week, 2 days)
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/

<personal hat off, chair hat on>
In addition to ours, Wojciech’s architectural principles, which I consider a very valuable document, is set to expire:
https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/

The other two QIRG documents,
https://datatracker.ietf.org/doc/draft-kaws-qirg-advent/
https://datatracker.ietf.org/doc/draft-dahlberg-ll-quantum/

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[email-masked]<mailto:[email-masked]>

_______________________________________________

Qirg mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/qirg

---

From: Chonggang Wang <[email-masked]>
Date: Tue, 3 Sep 2019 13:54:13 +0000

Hi Rodney,

Thanks for the reminder. I would like to volunteer to review those I-Ds and share my comments with the QIRG.

Best regards,
CG

From: Qirg <[email-masked]> On Behalf Of Rodney Van Meter
Sent: Monday, September 2, 2019 6:37 PM
To: [email-masked]
Cc: Rodney Van Meter <[email-masked]>
Subject: [Qirg] renewing I-Ds: comments, please!

Rodney Van Meter

[Banner]

[Banner] [Banner]
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

---

From: Melchior Aelmans <[email-masked]>
Date: Tue, 3 Sep 2019 22:06:10 +0200

Dear chairs,

There is currently no-one working on draft-kaws-qirg-advent
<https://datatracker.ietf.org/doc/draft-kaws-qirg-advent/> so no time
needed during the WG.

Regards,
Melchior

On Tue, Sep 3, 2019 at 12:37 AM Rodney Van Meter <rdv=
[email-masked]> wrote:

> Those of us who submitted I-Ds before the March meeting are facing
> expiration in a week or so.  While there was truly excellent discussion
> during the meeting in Prague, <personal hat on>off the top of my head, I
> don’t recall specific feedback on my I-D on connection setup.
>
> In addition to ours, Wojciech’s architectural principles, which I consider
> a very valuable document, is set to expire:
> were updated shortly after Prague, and hence have a few weeks’ more
> runway, but will also expire before Singapore if not renewed.
>
> [email-masked]

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 4 Sep 2019 10:31:30 +0900

By all means!  Comments are very welcome on my draft, and should be equally welcome on all the drafts.

To move the group forward, perhaps Wojciech’s draft is the right place to put in effort. He says he already has an updated draft, so perhaps the thing to do is for Wojciech to  upload that ASAP, and then we can all look at it and move forward from there.

Rodney Van Meter

> On Sep 3, 2019, at 22:54, Chonggang Wang <[email-masked]> wrote:
> 
> Hi Rodney, 
>  
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>  
> 
> 
>  
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 4 Sep 2019 10:32:00 +0900

Roger. The plan is to let it expire, then?

Rodney Van Meter

> On Sep 4, 2019, at 5:06, Melchior Aelmans <[email-masked]> wrote:
> 
> Dear chairs,
> 
> 
> There is currently no-one working on draft-kaws-qirg-advent <https://datatracker.ietf.org/doc/draft-kaws-qirg-advent/> so no time needed during the WG.
> 
> Regards,
> Melchior
> 
> On Tue, Sep 3, 2019 at 12:37 AM Rodney Van Meter <rdv=[email-masked] <mailto:[email-masked]>> wrote:

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 4 Sep 2019 04:51:34 +0000

Hi,

As you surely remember, we had a side meeting in Montreal, focused on QKD, and these are the conclusions I shared with those who participated:

  *   It seemed interesting to start a “track” within QIRG dedicated to QKD and its applicability to the evolution of the current Internet, and the security practices in it.
  *   Such a track would be interesting, among other things, for bridging activities more subject to basic research, and those more related to applied research, able to influence standardization results in the mid-term.
  *   The best way to bring such a track into reality would be to start working in a draft, including, at least:
     *   An overview of architectural options
     *   Report the experiences on the integration of QKD in network operations
     *   Describe requirements for different application scenarios
     *   Analyze the lessons learned in connection with architectural proposals, even trying to bridge them (as much as possible)
     *   Describe workflows for application, and possibly management and control, aspects
  *   I would be more than happy to act as editor for such a draft, and help would be greatly appreciated. I think I can have a general skeleton ready by mid-September
     *   Contributors are not only expected, but needed
  *   The goal would be to have a reasonably mature document to be discussed within the QIRG in Singapore.

If everything goes well, we’d have a document to present and discuss in November with a first version hopefully available soon.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 03/09/2019, 00:37, "Qirg on behalf of Rodney Van Meter" <[email-masked]<mailto:[email-masked]> on behalf of rdv=[email-masked]<mailto:rdv=[email-masked]>> wrote:

Rodney Van Meter

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Melchior Aelmans <[email-masked]>
Date: Wed, 4 Sep 2019 08:19:43 +0200

As far as I'm concerned, yes. If someone feels the need to continue working
on the draft he/she is more than welcome to do so.

Regards,
Melchior

On Wed, Sep 4, 2019 at 3:32 AM Rodney Van Meter <[email-masked]> wrote:

>> In addition to ours, Wojciech’s architectural principles, which I
>> consider a very valuable document, is set to expire:

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 4 Sep 2019 14:45:38 +0000

Hi,

An interesting article that presents in a simple way the key concepts of a quantum Internet.

Some comments :

1/ Quantum Internet will take into account point-to-point communication, but also multipoint communication; So I would have written :

The vision of a quantum Internet is to fundamentally improve Internet technology by allowing quantum communication between any two or more than two points on Earth.

2/ It is written that :

However, it is impossible to entangle two qubits without ever having them directly interact with each other (e.g. by performing a local two-qubit gate, such as the CNOT)

Does this sentence not contradict the paragraph “4.3.3.  Bell Pair links and entanglement swapping”   ? Because with entanglement swapping it is possible to entangle two qubits that never directly interact with each other : https://arxiv.org/abs/quant-ph/0409093 !!!

3/ To achieve teleportation, a Bell Pair needs to be distributed between the source and destination. Thus to teleport a Qubit we need first to distributed a Bell Pair and also use two classical bit. This is not a very effective type of communication because it is consume more resource than the one is transmit, isn’t it ? !!!

4/ 5.3.1.  Goals of a quantum internet.

-          Support distributed quantum applications and Support tomorrow's distributed quantum applications. For example concerning the QKD, there is a great zoology of QKD algorithms ( https://arxiv.org/pdf/1906.01645.pdf ) not necessarily based on the same quantum phenomenon (Heisenberg's uncertainty principle, entanglement) and require different characteristic of quantum channel.   Can an internet quantum communication infrastructure take into account this diversity of needs?

5/ 5.3.2.  The principles of a quantum internet.

-          Bell Pairs are the fundamental building block. Distributed quantum computation need multipartite entangled states shared among several nodes of the network and thus more than  Bell Pairs, isn’t it ? Or the goal is to transforming multipartite entangled states into the tensor product of bipartite Bell pairs between specific nodes using only a certain class of local operations and classical communication ( https://arxiv.org/abs/1907.08019 ) ?

/Patrick

---

From: Wojciech Kozlowski <[email-masked]>
Date: Fri, 6 Sep 2019 16:05:41 +0000

Thanks for your feedback. I didn't have time to address all your points, but I have some comments inline:

On Wed, 2019-09-04 at 14:45 +0000, Gelard Patrick wrote:
2/ It is written that :

This is a very good point and it just shows the draft needs some extra care with the language. I guess the best way to clarify this point is that entanglement swapping doesn't actually create entanglement. Instead one of the particles is simply teleported to a more distant location. I haven't addressed this point in the latest version though.

It doesn't consume more resources, because we are not interested in transmitting classical data. Qubits are teleported for the purposes of sharing quantum states and entanglement (for use by higher-layer applications), something you cannot do by simply transmitting classical bits.

Adding references is a pain to do in the XML format for drafts so I haven't added this reference. I would also add a reference to https://wiki.veriqloud.fr/index.php?title=Main_Page

I'm not sure I follow this point. You can create more complex entangled states from Bell Pairs.

---

From: Wojciech Kozlowski <[email-masked]>
Date: Fri, 6 Sep 2019 16:05:52 +0000

Here are my comments on

Major comments are below, minor comments are in attached file (search
for '# WK').

1. The biggest value I see in this draft are the RuleSets and their
condition+action rules mentioned in section 4.3, but they aren't
sufficiently expanded on. I think that this concept, if generalised,
would be valuable to quantum networking in general.

I would first propose renaming them to match+action to tie to existing
terminology in the networking community (match+action is definitely
common, I'm not sure I ever heard of condition). It would also be good
to go into more detail about what these conditions and actions could
be. I think this draft lacks concreteness that a precise list of
possible conditions and actions could provide. A discussion on their
extensibility would also be valuable.

2. I would consider separating the RuleSet definition from the
distribution mechanism. Why? The match+action rules resemble SDN
(software-defined networking) with OpenFlow which program match+action
rules for classical forwarding and thus it would allow these RuleSets
to be distributed in different ways. However, the current protocol also
includes collecting information about available resources so this might
not be as easy as it first sounded in my head. I'm sure it must be
possible though. After all SDNs can also implement telemetry.

Another reason for separating, is that the concepts in this draft
remind me of L3VPN tunnels (especially when the authors talk about the
Responder being 'smarter'). Admittedly, I'm not an expert on this
topic, but a BGP router could potentially fulfil the role of the
Initiator and Responder and distribute information about these
connections using mechanisms that already exist in BGP and MPLS.

3. The resource discussion should be more concrete, but that will be
difficult without some pre-agreed nomenclature and commonly agreed on
notion of resources. It would be good perhaps to tie this with the
principles draft which will lay down necessary resource concepts on
which this draft can build upon.

4. I'm missing a bigger picture somewhere in the draft. Where does this
protocol fit in? Is it meant to run across a single administrative
domain or will it span many? Is it done end-to-end? If it's not end-to-
end, how are different connections glued together. Some diagrams could
help.

Cheers,
Wojciech

---

From: Patrick Gelard <[email-masked]>
Date: Fri, 6 Sep 2019 19:14:59 +0200

Hi

Thanks for your answers.

1/ About teleportation the feedback i have from telcom engineers :

    To be able to teleport 1 Qubit you must first :

    - generate a pair of maximally entangled qubits, referred to as EPR
    pair, with each qubit stored at each remote node.

    - consume two classical bit.

A direct transmission of Qubit does not need to consume all these 
communication resources, but you are limited by the distance unless 
quantum error correction progress significantly

Teleport a qudits (with d>> 2) should be more beneficial even if consume 
more ressources than a qubit. Because you can exploit more parallelism 
(exponential) for the calculation (more dimensions)

2/Can a set of Bell pairs be used to establish multipoint/multicast 
communication? for example, for distributed quantum computing.

/Patrick

Le 06/09/2019 à 18:05, Wojciech Kozlowski a écrit :
>> However, it is impossible to entangle two qubits without ever having 
>> them directly interact with each other (e.g. by performing a local 
>> two-qubit gate, such as the CNOT)
>>
>> Does this sentence not contradict the paragraph “4.3.3.  Bell Pair 
>> links and entanglement swapping”   ? Because with entanglement 
>> swapping it is possible to entangle two qubits that never directly 
>> interact with each other : https://arxiv.org/abs/quant-ph/0409093 !!!
>>
>
> This is a very good point and it just shows the draft needs some extra 
> care with the language. I guess the best way to clarify this point is 
> that entanglement swapping doesn't actually create entanglement. 
> Instead one of the particles is simply teleported to a more distant 
> location. I haven't addressed this point in the latest version though.
>
>> 3/To achieve teleportation, a Bell Pair needs to be distributed 
>> between the source and destination. Thus to teleport a Qubit we need 
>> first to distributed a Bell Pair and also use two classical bit. This 
>> is not a very effective type of communication because it is consume 
>> more resource than the one is transmit, isn’t it ? !!!
>>
>
> It doesn't consume more resources, because we are not interested in 
> transmitting classical data. Qubits are teleported for the purposes of 
> sharing quantum states and entanglement (for use by higher-layer 
> applications), something you cannot do by simply transmitting 
> classical bits.
>
>
>> -Support distributed quantum applications and Support tomorrow's 
>> distributed quantum applications. For example concerning the QKD, 
>> there is a great zoology of QKD algorithms ( 
>> https://arxiv.org/pdf/1906.01645.pdf ) not necessarily based on the 
>> same quantum phenomenon (Heisenberg's uncertainty principle, 
>> entanglement) and require different characteristic of quantum 
>> channel.   Can an internet quantum communication infrastructure take 
>> into account this diversity of needs?
>>
>
> Adding references is a pain to do in the XML format for drafts so I 
> haven't added this reference. I would also add a reference to 
> https://wiki.veriqloud.fr/index.php?title=Main_Page
>
>
>> -Bell Pairs are the fundamental building block.Distributed quantum 
>> computation need multipartite entangled states shared among several 
>> nodes of the network and thus more than  Bell Pairs, isn’t it ? Or 
>> the goal is to transforming multipartite entangled states into the 
>> tensor product of bipartite Bell pairs between specific nodes using 
>> only a certain class of local operations and classical communication 
>> ( https://arxiv.org/abs/1907.08019 ) ?
>>
>

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 16 Sep 2019 09:42:46 +0000

On Fri, 2019-09-06 at 19:14 +0200, Patrick Gelard wrote:

Hi

Thanks for your answers.

- generate a pair of maximally entangled qubits, referred to as EPR pair, with each qubit stored at each remote node.

A direct transmission of Qubit does not need to consume all these communication resources, but you are limited by the distance unless quantum error correction progress significantly

Teleport a qudits (with d>> 2) should be more beneficial even if consume more ressources than a qubit. Because you can exploit more parallelism (exponential) for the calculation (more dimensions)

I think measuring the worth of quantum teleportation in terms of how much information it can carry compared to classical communication is missing the point. Quantum teleportation allows you to transport arbitrary quantum data, and more importantly, entanglement. Something you cannot do classically. Hence, it's valuable even at the qubit level.

2/Can a set of Bell pairs be used to establish multipoint/multicast communication? for example, for distributed quantum computing.

That's an interesting question. It will depend on what you want to achieve:

1) You can use the Bell Pairs to build up larger multi-qubit entangled states such as the GHZ state. You can also build your network to directly distribute such states. This isn't exactly multicast, but it involves more than two end-nodes.

2) I believe some people are working on quantum multicast where you perform imperfect clones of the original data - https://ieeexplore.ieee.org/document/8710255

/Patrick

Qirg mailing list

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>      Garanti sans virus. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>