Subject: [Qirg] Multipatite entanglement

From: Frédéric Grosshans <[email-masked]>
Date: Fri, 8 Nov 2019 18:27:44 +0100

This is my first mail in the QIRG mailing list, and I must
confess I haven’t read the archives. I apologize if the issue I am
raising has been discussed earlier.

I am currently interested in the routing/use of multipartite
entanglement in networks, one of the  “other problems” mentioned
in the charter:

* multi-party
states and multi-party transfers such as network coding:

rather than simple, independent point-to-point
transfers, how can we

create and use more complex states?

I have read draft-van-meter-qirg-quantum-connection-setup-01.txt
(but not the other two documents yet) and it seems almost
exclusively focused on point-to-point (P2P) connections. Don’t
take me wrong, I indeed think it is totally normal to start with
point-to-point connections, since it‘s the simpler case to tackle.
However, I think we will need to look at multipartite entanglement
distribution at some point, e.g. for the long-baseline
interferometry example of the 1st paragraph in the charter, and
that provisions for this case should be taken early, otherwise it
will be difficult to move away from P2P connection.

In particular, I have the feeling that the notion of Initiator
and Responder are difficult to generalize to multiparty case, and
that they look a lot like a sender and a receiver in disguise.
Maybe a simple solution which would not change a lot the current
situation but would nevertheless be generalizable would be to have
three roles. Something like:

Client    an end node which should receive a share of
the entangled state distributed by the connections. A P2P link
has two clients, typically the Initiator and the Coordinator,
but quantum multicast links could involve more than two clients.

Initiator  the initiator of the classical process of
establishing the connection by sending a message toward the
Coordinator. Typically, Initiator one of the clients

Coordinator is responsible of the connection process
initiated by the Initiator. Coordinator created the rulesets for
all nodes establishing the connection and commonly will be the
smarter node. In P2P connection, the Coordinator is typically is
one of the client, the one which is not the initiator. For
multipartite connections, the Coordinator will need to exchange
messages with clients beyond the Initiator, can be the Initiator
itself or can be a node in the network.

For P2P distribution, we have two Clients, one is the Initiator
and one is the Coordinator (ex-Responder) like in the current
document, so it does not change much. The change is motivated by
case like GHZ state distribution (seen as a star graph state)
where I think it would be natural to have the Initiator and the
Coordinator being the same end node client, which has to exchange
messages with all the other clients to get the relevant network
topology. I think the name “Responder” is less natural in this
case, that‘s why I’ve changed it to Coordinator.

What do you think?

Of course such changes would imply slight changes accross the
documents, but I think they’re worth its and I’m volunteer to work
on it.

Cheers,

Frédéric

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 11 Nov 2019 02:22:39 +0000

The question of multicast/multi-party entanglement comes up every now and then. It will definitely need some dedicated treatment since as you say there will be applications that need it. However, this should be achievable with many P2P links. Once you distribute your Bell pairs you should be able to use them to create your multi-partite states through teleportation or other means. It could be that dedicated processes in the network could be more efficient, but I don't think anybody has investigated that yet.

Do you think this approach would be good enough?

________________________________
From: Qirg <[email-masked]> on behalf of Frédéric Grosshans <[email-masked]>
Sent: 08 November 2019 18:27:44
To: [email-masked]
Subject: [Qirg] Multipatite entanglement

This is my first mail in the QIRG mailing list, and I must confess I haven’t read the archives. I apologize if the issue I am raising has been discussed earlier.

I am currently interested in the routing/use of multipartite entanglement in networks, one of the  “other problems” mentioned in the charter:

  * multi-party states and multi-party transfers such as network coding:
    rather than simple, independent point-to-point transfers, how can we
    create and use more complex states?

I have read draft-van-meter-qirg-quantum-connection-setup-01.txt (but not the other two documents yet) and it seems almost exclusively focused on point-to-point (P2P) connections. Don’t take me wrong, I indeed think it is totally normal to start with point-to-point connections, since it‘s the simpler case to tackle. However, I think we will need to look at multipartite entanglement distribution at some point, e.g. for the long-baseline interferometry example of the 1st paragraph in the charter, and that provisions for this case should be taken early, otherwise it will be difficult to move away from P2P connection.

In particular, I have the feeling that the notion of Initiator and Responder are difficult to generalize to multiparty case, and that they look a lot like a sender and a receiver in disguise. Maybe a simple solution which would not change a lot the current situation but would nevertheless be generalizable would be to have three roles. Something like:

Client    an end node which should receive a share of the entangled state distributed by the connections. A P2P link has two clients, typically the Initiator and the Coordinator, but quantum multicast links could involve more than two clients.

Initiator  the initiator of the classical process of establishing the connection by sending a message toward the Coordinator. Typically, Initiator one of the clients

Coordinator is responsible of the connection process initiated by the Initiator. Coordinator created the rulesets for all nodes establishing the connection and commonly will be the smarter node. In P2P connection, the Coordinator is typically is one of the client, the one which is not the initiator. For multipartite connections, the Coordinator will need to exchange messages with clients beyond the Initiator, can be the Initiator itself or can be a node in the network.

For P2P distribution, we have two Clients, one is the Initiator and one is the Coordinator (ex-Responder) like in the current document, so it does not change much. The change is motivated by case like GHZ state distribution (seen as a star graph state) where I think it would be natural to have the Initiator and the Coordinator being the same end node client, which has to exchange messages with all the other clients to get the relevant network topology. I think the name “Responder” is less natural in this case, that‘s why I’ve changed it to Coordinator.

What do you think?

Of course such changes would imply slight changes accross the documents, but I think they’re worth its and I’m volunteer to work on it.

  Cheers,

        Frédéric

---

From: Patrick Gelard <[email-masked]>
Date: Mon, 11 Nov 2019 09:04:35 +0100

Hi Frédéric,

As you probably know, there are a number of studies on the subject like 
this one https://www.nature.com/articles/s41598-018-36543-5 which is a 
very good entry point.

Multipartite entangled states shared among several nodes of the network 
opens the way for applications such as secret voting and secret sharing, 
conference key agreement,
clock synchronization, or distributed quantum computation (e.g One-way 
quantum computing in distributed architecture 
https://www.worldscientific.com/doi/10.1142/S0219749910006198 ).

Now regarding the control plan for deploying such a service, he seems to 
me that one of the questions is: should we develop a new control plan or 
adapt some traditional network control plans (e.g Resource Reservation 
Protocol (RSVP) Mulicast ; SDN ; etc.) that could do the job?

Best regards

/Patrick

Le 11/11/2019 à 03:22, Wojciech Kozlowski a écrit :
>
> The question of multicast/multi-party entanglement comes up every now 
> and then. It will definitely need some dedicated treatment since as 
> you say there will be applications that need it. However, this should 
> be achievable with many P2P links. Once you distribute your Bell pairs 
> you should be able to use them to create your multi-partite states 
> through teleportation or other means. It could be that dedicated 
> processes in the network could be more efficient, but I don't think 
> anybody has investigated that yet.
>
>
> ------------------------------------------------------------------------
> *From:* Qirg <[email-masked]> on behalf of Frédéric Grosshans 
> <[email-masked]>
> *Sent:* 08 November 2019 18:27:44
> *To:* [email-masked]
> *Subject:* [Qirg] Multipatite entanglement
>
> This is my first mail in the QIRG mailing list, and I must confess I 
> haven’t read the archives. I apologize if the issue I am raising has 
> been discussed earlier.
>
> entanglement in networks, one of the  “other problems” mentioned in 
> the charter:
>
> I have read draft-van-meter-qirg-quantum-connection-setup-01.txt (but 
> not the other two documents yet) and it seems almost exclusively 
> focused on point-to-point (P2P) connections. Don’t take me wrong, I 
> indeed think it is totally normal to start with point-to-point 
> connections, since it‘s the simpler case to tackle. However, I think 
> we will need to look at multipartite entanglement distribution at some 
> point, e.g. for the long-baseline interferometry example of the 1st 
> paragraph in the charter, and that provisions for this case should be 
> taken early, otherwise it will be difficult to move away from P2P 
> connection.
>
> In particular, I have the feeling that the notion of Initiator and 
> Responder are difficult to generalize to multiparty case, and that 
> they look a lot like a sender and a receiver in disguise. Maybe a 
> simple solution which would not change a lot the current situation but 
> would nevertheless be generalizable would be to have three roles. 
> Something like:
>
>     *Client*    an end node which should receive a share of the
>     entangled state distributed by the connections. A P2P link has two
>     clients, typically the Initiator and the Coordinator, but quantum
>     multicast links could involve more than two clients.
>
>     *Initiator*  the initiator of the classical process of
>     *Coordinator *is responsible of the connection process initiated
>     by the Initiator. Coordinator created the rulesets for all nodes
>     establishing the connection and commonly will be the smarter node.
>     In P2P connection, the Coordinator is typically is one of the
>     client, the one which is not the initiator. For multipartite
>     connections, the Coordinator will need to exchange messages with
>     clients beyond the Initiator, can be the Initiator itself or can
>     be a node in the network.
>
> For P2P distribution, we have two Clients, one is the Initiator and 
> one is the Coordinator (ex-Responder) like in the current document, so 
> it does not change much. The change is motivated by case like GHZ 
> state distribution (seen as a star graph state) where I think it would 
> be natural to have the Initiator and the Coordinator being the same 
> end node client, which has to exchange messages with all the other 
> clients to get the relevant network topology. I think the name 
> “Responder” is less natural in this case, that‘s why I’ve changed it 
> to Coordinator.
>
> What do you think?
>
> documents, but I think they’re worth its and I’m volunteer to work on it.
>
>   Cheers,
>
>         Frédéric
>
>
>
>
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---

From: Frédéric Grosshans <[email-masked]>
Date: Tue, 12 Nov 2019 12:35:26 +0100

[...]
> However, this should be achievable with many P2P links. Once you 
> distribute your Bell pairs you should be able to use them to create 
> your multi-partite states through teleportation or other means. It 
> could be that dedicated processes in the network could be more 
> efficient, but I don't think anybody has investigated that yet. 

Well... I did not say it in my previous email, but it was motivated by 
my earlier investigation of this problem in [arXiv:1811.05445 
https://arxiv.org/abs/1811.05445], together with Clément Meignant and 
Damian Markham. Actually, one of the main difference with the similar 
work of A. Pirker and W. Dür, [New Journal of Physics 21, 033003 (2019), 
arXiv:1810.03556 https://arXiv.org/abs/1810.03556] is our study of 
efficiency.

If the network is organized as  at tree, in our idealized setting (1 
Bell pair/link/time-sep), this leads to the distribution of a N-GHZ 
state in a single timestep while I think going through endpoint 
Bell-pair sharing would need N-1 timesteps

   Cheers

---

From: Frédéric Grosshans <[email-masked]>
Date: Tue, 12 Nov 2019 12:49:53 +0100

Hi Patrick,

Le 11/11/2019 à 09:04, Patrick Gelard a écrit :
>
> As you probably know, there are a number of studies on the subject 
> like this one https://www.nature.com/articles/s41598-018-36543-5 which 
> is a very good entry point.
>

Thanks for the reference. I’ve actually read other papers from this 
team, but I somehow missed this one.

>
> Multipartite entangled states shared among several nodes of the 
> network opens the way for applications [...]
>
Indeed
>
>
> Now regarding the control plan for deploying such a service, he seems 
> to me that one of the questions is: should we develop a new control 
> plan or adapt some traditional network control plans (e.g Resource 
> Reservation Protocol (RSVP) Mulicast ; SDN ; etc.) that could do the job?
>
My problem with this is that I’m a physicist with a really elementary 
knowledge (if any!) of network protocols. For example, in the 
theoretician’s protocol we designed with Clément Meignant and Damian 
Markham, [arXiv:1811.05445 https://arxiv.org/abs/1811.05445],a key 
ingredient of GHZ state generation (which is a primitive for the 
following) is to find a subtree of the network linking the end-nodes. 
The operation on nodes of the tree are then local, and look a bit like 
entanglement-swapping for a repeater line, bit on a tree.

I guess the control plan would look a lot like the one for multicast, 
but it‘s pure speculation from me.

Cheers,

         Frédéric