[Qirg] multi-partite entanglement

[Rodney Van Meter <[e-mail]>]

I did some thinking about this last night and tonight.  I realized that the approach we’ve proposed for bipartite won’t work.  We propose that the information for planning be accumulated on the outbound leg from the initiator to the responder, then the RuleSets constructed at the responder, and the RuleSets distributed on the return leg.  One of the nice things about this is e.g. if you’re a user and you want to connect to quantumgooduckduckgogle.com, then one of quantumgooduckduckgogle.com’s potential value adds business-wise is the ability to do a better job of connection planning than you as an individual can, or better than duckgooduckquantum.com can, and they can upgrade that ability autonomously.

With one initiator and multiple responders, obviously that doesn’t work.

But the multi-partite process is *SO* complex; for example, you may be better off building a Steiner tree on a graph, whereas the initial request by the initiator might follow a set of (partially overlapping) two-terminal paths.  So how do you pick the path, collect the information about the links & nodes, perform the planning, and distribute?

I want bipartite and multipartite to be separate also because of the difficulty of getting enough people to understand and review even the two-party operation, and because multi-party state generation in an experimental network is still much farther away.  I want the mechanism we are defining here to be used by those building networks (e.g., Delft), and a more complex protocol is less likely to be adopted.

—Rod

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