Re: [Qirg] Survey paper about the Quantum Internet Protocol Stack

Marcello Caleffi <marcello.caleffi@unina.it> Wed, 08 June 2022 10:44 UTC

Return-Path: <marcello.caleffi@unina.it>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5304DC15D875 for <qirg@ietfa.amsl.com>; Wed, 8 Jun 2022 03:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4hW2CLmygqg for <qirg@ietfa.amsl.com>; Wed, 8 Jun 2022 03:44:27 -0700 (PDT)
Received: from leas1.unina.it (fmvip.unina.it [192.132.34.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F1CC15D86C for <qirg@irtf.org>; Wed, 8 Jun 2022 03:44:22 -0700 (PDT)
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by leas1.unina.it with ESMTP id 258AiCIx016930-258AiCJ1016930 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=CAFAIL); Wed, 8 Jun 2022 12:44:12 +0200
Received: from smtpclient.apple ([100.88.1.134]) (authenticated bits=0) by smtp2.unina.it (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 258AiB5v837699 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jun 2022 12:44:12 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Marcello Caleffi <marcello.caleffi@unina.it>
In-Reply-To: <92076DEA-CE4B-44C1-A20E-B0F275CB97EF@aero.org>
Date: Wed, 08 Jun 2022 12:43:56 +0200
Cc: Jessica Illiano <jessica.illiano@unina.it>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "qirg@irtf.org" <qirg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBBDD15E-E856-4A88-80A4-CD535E78EBE0@unina.it>
References: <95660D1B-5687-49E8-B779-6FFE27652B13@unina.it> <2d44d95d-2d90-64d6-20a4-36856432cac1@gmail.com> <A118EFF3-FC3E-462E-B368-BC8D95AFE768@unina.it> <92076DEA-CE4B-44C1-A20E-B0F275CB97EF@aero.org>
To: Joseph D Touch <joseph.d.touch@aero.org>
X-Mailer: Apple Mail (2.3696.100.31)
X-Virus-Scanned: clamav-milter 0.103.6 at smtp2.unina.it
X-Virus-Status: Clean
Authentication-Results: leas1.unina.it; spf=pass (unina.it: domain of marcello.caleffi@unina.it designates 192.132.34.62 as permitted sender) smtp.mailfrom=marcello.caleffi@unina.it
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/1BC30oufzWxU4PfAbsqStRBMG2M>
Subject: Re: [Qirg] Survey paper about the Quantum Internet Protocol Stack
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Quantum Internet RG <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2022 10:44:31 -0000

Hi Joseph,
I understand that the sentence copied by Jessica, taken as per-se and without reading the long discussion about "physical quantum connectivity" vs “entanglement-enabled virtual connectivity” conducted within the paper, could raise some misunderstanding.
Indeed, we believe that there is a lack of common terminology within the community — with different authors using different names for similar functionalities and vice-versa — and this might have impact as well.

I'll try to summarize some concepts at my best, tough some reading of the paper is the better option.

------------------------------------------------------------------------------------------------

Coming to your observations about classical Internet:
- I agree with you about ND “discovering” L2 connectivity
- but L2 connectivity means that sender could reach destination by simply transmitting the packet through the proper interface.. this requires that there exists a physical channel (or a sequence of physical channels with some optional hardware — the switch — in between with the only purpose of reducing the collision domain) interconnecting source and destination
- clearly, probing the existence of a (sequence) of physical channel(s) doesn’t imply that we can acquire full knowledge about the physical topology (and I substantiate your example about complex ethernet networks by mentioning that ND in general can’t discover redundant links closing a loop within switches but simply "Spanning-Tree”-enabled links),  
- so, I stand with the sentence "ND gather information about the physical connectivity”, or if you prefer with the sentence "ND gather partial information about the physical connectivity”, as long as we don’t write something like "ND gather full knowledge about the physical connectivity”

------------------------------------------------------------------------------------------------

Coming to the paper sentence (BTW, we didn't wrote that L2 classical topology is correlated with quantum link topology), the “physical” connectivity should be placed in the context of “physical" vs "entanglement-enabled virtual” (with the main meaning of “physical" for distinguish from virtual) rather than L1 (physical layer) vs L2 (link layer).

Let me give some more contest about the sentence (but, please, these are just short extracts from the paper with no ambition of providing a complete self-consistent description)

Pag. 13, Sec. V.1
<<<
In classical networks, a single concept of connectivity arises, referred to as \textit{physical} connectivity. Whenever there exists a physical communication link\footnote{Obviously, the definition of physical connectivity can be easily extended to a multi-hop route constituted by several communication links.} between two nodes, these nodes are defined ``\textit{connected}''. And the successful transmission of a classical message between these two nodes requires at least one use of the physical communication link. As a consequence, the successful transmission depends on the instantaneous propagation conditions of the physical channel underlying the communication link. Stemming from these considerations, the classical connectivity is \textit{physical} since it strictly depends on the physical channel.
Conversely, quantum teleportation enables the transmission of one qubit without any use of a quantum link. Specifically, as long as an entangled state -- say an EPR pair for the sake of simplicity -- is shared between two nodes, they can transmit a qubit regardless of the instantaneous conditions of the underlying physical quantum channel. Remarkably, the qubit transmission is still possible even if the nodes are not anymore interconnected by a quantum link\footnote{It is worthwhile to note that, thanks to the \textit{deferred measurement} principle \cite{NieChu-11,CuoCalKrs-21,IllCacMan-21}, the transmissions of the two classical bits -- and the subsequent post-processing at the destination needed for performing a teleporting operation -- can be delayed at any convenient time. Accordingly, in this section we focus on the peculiar connectivity characteristics arising with quantum entanglement.}. In this sense, we can say that entanglement enables a \textit{virtual} quantum link, and consequently the concept of \textit{virtual connectivity} arises.
>>

By oversimplifying:
- physical connectivity means that the connectivity requires the exchange of a message through a sequence of channels, whose instantaneous conditions affect the exchange. During the distribution of entanglement or by directly transmitting a qubit, you’re facing with physical connectivity.
- Yet, once shared, entanglement provides a virtual connectivity that is independent from the instantaneous propagation conditions of the physical channel
- (see also the remaining part of Sec. V.1 for further details). 

Pag. 25, Sec., VII.5
<<<
Clearly, as for the classical Internet, the Quantum Internet should rely on some networking functionalities such as path discovery, forwarding and routing [110, 21]. But these functionalities must be designed to account for the peculiarities of the entanglement as communication resource.
Indeed, part of these functionalities can be carried out through classical networks by existing protocols. As instance, neighbor discovery – used by network nodes to gather information about the physical connectivity – could be accomplished by resorting to classical protocols [111, 112, 113]. However, as widely described in Sec.5, the concept of virtual connectivity – including its variations such as the augmented and on-demand connectivity – arises with entanglement. Whether existing neighbor discovery algorithms can be employed for virtual neighbor discovery – and how the physical neighbor discovery should interacts with the virtual one – is yet to be determined. Indeed, not only the virtual connectivity dynamics are intrinsically different from the ones arising with physical connectivity – as described in Section 5 – but when it comes to multipartite entanglement the concept of neighborhood evolves from a binary question – “is a certain node one of my neighbors?” – to a more complex question, including at the very least the discovery of the identities of all the entangled nodes.
Furthermore, both physical and virtual neighbor discoveries play a pivotal role for the deign of routing services such as path discovery and path forwarding. Here, the first step is to identify, within the quantum network infrastructure responsible for the distribution of shared entangled states, at least a physical quantum path between source and destination. This quantum path must be augmented by a classical path, so that quantum nodes can exchange proper classical signaling as discussed in Section 7.2. In this regard, one should argue that physical connectivity enables direct communications between neighbor nodes, whereas quantum repeaters and entanglement swapping extend the spatial domain of the virtual connectivity, enabling direct communications between nodes that may be topologically remote. However, virtual connectivity should not be considered as the main connectivity, as well as neither physical and virtual connectivity should be considered as mutually exclusive strategies. On the contrary, they are strictly correlated and path discovery should be able to evaluate – case by case – whether entanglement-based communications outperform direct dispatch, where quantum information is directly transmitted through the physical quantum channel.
>>>

So, in a nutshell, in the Quantum Internet:
- we need classical topology discovery AND quantum topology discovery
- classical topology discovery might resort to classical protocols -> but we don’t believe this is the correct direction, see as instance [1,2] where we gave some insights on quantum solutions to classical network functionalities such as MAC
- quantum topology discovery can’t resort only to a quantum version of “classical” protocols because the connectivity is virtual, augmented, on-demand.. so we need to figure out new algorithms and the worst decision would be starting to design a Quantum ND without fully understanding the peculiar features with no classical counterpart of entanglement

[1] A.S. Cacciapuoti, J. Illiano, S. Koudia, K. Simonov, M. Caleffi, "The Quantum Internet: Enhancing Classical Internet Services one Qubit at a Time", arXiv, May 2022.
https://arxiv.org/abs/2205.09476
[2] J. Illiano, M. Viscardi, S. Koudia, M. Caleffi, A.S. Cacciapuoti, "Quantum Internet: from Medium Access Control to Entanglement Access Control", arXiv, May 2022
https://arxiv.org/abs/2205.11923

------------------------------------------------------------------------------------------------

Btw, thanks for the interest and the email, and feel free to reach us out for any further comment or doubt.

Regards,
Marcello


------------------------------------------------------------------------------------------------

Prof. Marcello Caleffi
	Editor, IEEE Transactions on Wireless Communications
	Associate Editor, IEEE Transactions on Quantum Engineering
	Emeritus Distinguished Visitor 2017-2019, IEEE Computer Society

FLY Lab Co-Director
http://www.quantuminternet.it
	Department of Electrical Engineering and Information Technologies
	University of Naples Federico II
	via Claudio 21, 80125 Naples, Italy
	Phone: +39-081-7683810

Personal Links
	https://www.linkedin.com/in/marcello-caleffi
	https://twitter.com/MarcelloCaleffi
	https://scholar.google.it/citations?user=fe6naasAAAAJ





> Il giorno 7 giu 2022, alle ore 18:02, Joseph D Touch <joseph.d.touch@aero.org> ha scritto:
> 
> Hi, all,
> 
> "Neighbor discovery" in IPv6 combines the function of IPv4's ARP and a portion of IPv4 ICMP.
> It allows IPv6 (which thinks of itself as 'layer 3') to find information about the 'layer 2' over which it runs, notably:
> 	- on a given link, what is the 'l2' address that corresponds to an 'l3' address? (if available on that link)
> 	- on a given link, should traffic intended for one L3 address be sent instead to a different L3 address (router redirect)
> Etc.
> 
> First: "l3" and "l2" are relative, but let's ignore that for now (it's important if you run IP over IP, etc.)
> 
> Second, in L3-speak, "link" is an interface on a device that can reach one or more other devices without going through another L3 device. It does NOT mean "directly connected".
> 
> I.e., ND 'discovers' the l2 logical topology. E.g., if I am connected to a complex Ethernet network, that all looks like one "l2" to me and to ND.
> 
> Back to relative layering, there is NO protocol that ever discovers physical anything. Everything in networking can be (and is) virtualized. So at a given L3, using ND 'discovers' the logical L2 immediately underneath only. There may be (and often are) other layers beneath that which these protocols do not expose (nor do any ever discover). Think of it like virtual memory. The OS knows when you're in it, but you don't (or can't), strictly speaking.
> 
> Finally, even if you use ND to map the logical L2 of a classical net, that logical L2 connectivity need not have ANY correlation to the quantum link topology. All you hope you know is that you have *endpoints* at each quantum node that you can use the classical net to communicate between.
> 
> Regarding the specific references:
> 	111: AODV "discovers" a point-to-point topology based on the ability of broadcast messages to reach other nodes; the protocol doesn't know if the broadcast is physical (e.g., via an omnidirectional antenna) or logical (via relay though many Ethernet switches)
> 	112: on-demand ad-hoc: see note for [111]
> 	113: IPv6 ND: see note at the top of this post, i.e., this 'discovers' addresses, not topology. ND requests are issued out only the interfaces that are already selected, so if a node is reachable on only one of three links at a router, the router will discover that node's L2 address *ONLY* if it already intends to reach it by the particular link selected by its forwarding algorithm. It will not send out NDs on each interface to 'find' that node
> 
> Joe
> 
> ----
> 
> On 6/7/22, 4:08 AM, "Qirg on behalf of Jessica Illiano" <qirg-bounces@irtf.org on behalf of jessica.illiano@unina.it> wrote:
> 
>    Dear Alex
>    Thank you for reaching us out.
> 
>    Reference 113 is cited in section 7.5 
>    <<Indeed, part of these functionalities can be carried out through classical networks by existing protocols. As instance, neighbor discovery -- used by network nodes to gather information about the physical connectivity -- could be accomplished by resorting to classical protocols [111,112,113].>>
> 
>    and, indeed, the citation rationale is for providing an update RFC for NDP implemented with classical protocols.
> 
>    Furthermore, indeed the bibliography is a comprensive list for deep analysis
> 
>    Best regards
> 
>    Jessica
> 
>> Il giorno 7 giu 2022, alle ore 10:59, Alexandre Petrescu <alexandre.petrescu@gmail.com> ha scritto:
>> 
>> Comment: it does list en entry '[113]' RFC4861, the 'ND' protocol of IPv6, but it does not cite this '[113]' in the running text?
>> 
>> Where is the article talking about IPv6?
>> 
>> Or is the Reference list a bibliography for further study?
>> 
>> Thank you for the paper.  I will print it and read it.
>> 
>> Alex
>> 
>> Le 06/06/2022 à 11:09, Angela Sara Cacciapuoti a écrit :
>>> Dear Friends and Colleagues,
>>> I would like to share with you a survey paper about the Quantum Internet Protocol Stack
>>> https://arxiv.org/abs/2202.10894 <https://arxiv.org/abs/2202.10894>
>>> which has been recently accepted for publication.
>>> I believe it could be of interest for many of you.
>>> Any comment is much appreciated.
>>> Kind Regards
>>> Sara
>>> Prof. Angela Sara Cacciapuoti, Ph.D., IEEE Senior Member
>>> Co-Director - FLY: Future Communications Lab
>>> http://www.quantuminternet.it <http://www.quantuminternet.it>
>>> Associate Professor, University of Naples Federico II
>>> IEEE ComSoc Distinguished Speaker
>>> DIETI ERASMUS Coordinator
>>> Area Editor:
>>> IEEE Communications Letters
>>> Editor/Associate Editor:
>>> IEEE Trans. on Communications
>>> IEEE Trans. on Wireless Communications
>>> IEEE Trans. on Quantum Engineering
>>> IEEE Network
>>> Email: angelasara.cacciapuoti@ieee.org <mailto:angelasara.cacciapuoti@ieee.org>
>>> Twitter: https://twitter.com/AngelaSaraCacc
>>> _______________________________________________
>>> Qirg mailing list
>>> Qirg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/qirg
>> 
>> _______________________________________________
>> Qirg mailing list
>> Qirg@irtf.org
>> https://www.irtf.org/mailman/listinfo/qirg
> 
>    _______________________________________________
>    Qirg mailing list
>    Qirg@irtf.org
>    https://www.irtf.org/mailman/listinfo/qirg
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg