Subject: [Qirg] connection setup

From: Rodney Van Meter <[email-masked]>
Date: Wed, 13 Mar 2019 08:39:22 +0800

We uploaded a draft on connection setup in a quantum network.  This represents how our quantum Internet simulator actually does things today, though the implementation isn’t yet truly complete.
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/ <https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/>

With the chair’s permission(???), would like to add this to the agenda for Prague.

—Rod

P.S. I don’t think any of the three new drafts that were uploaded have correctly shown up as QIRG-related.  Will see what I can do to fix.

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 13 Mar 2019 10:19:48 +0000

Hi Rod,

What do you mean by : « quantum communication between two nodes more closely resembles a coordinated computation distributed among the set of nodes forming the path between the two nodes than a store-and-forward network session  » ?

Do you mean that quantum communication between two nodes is more closely concerned by distributed LOCC ( local operations and classical communication ) computation among the set of nodes forming the path between the two nodes than a store-and-forward network session  ? 

As entanglement represents a fundamental resource in quantum internet, thus LOCC being the class of operations that manipulates and consumes this resource ?

That's why you don't want to use the  « source »  and « destination »  terms for the connection level in a quantum network ? Because distributed quantum states coud be use to transform entanglement ( https://arxiv.org/pdf/quant-ph/9811053.pdf ) ? 

/Patrick

De : Qirg <[email-masked]> De la part de Rodney Van Meter
Envoyé : mercredi 13 mars 2019 01:39
À : [email-masked]
Cc : Rodney Van Meter <[email-masked]>
Objet : [Qirg] connection setup

We uploaded a draft on connection setup in a quantum network.  This represents how our quantum Internet simulator actually does things today, though the implementation isn’t yet truly complete.
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/

—Rod

---

From: Wojciech Kozlowski <[email-masked]>
Date: Thu, 14 Mar 2019 10:10:51 +0100

Hi Rod,

Very interesting draft. I have some questions/remarks:

 1. I think I could benefit from a more specific use-case example. I am
    struggling a bit to understand at what stage these connections are
    made. Is this something that a network sets up ahead of time, or is
    this set up per flow and must be maintained for its duration? I
    think this would also shed light on how failures along the path
    should be handled.

    At the moment I'm reading it as if it's set up per end-to-end
    connection. What happens if a node fails during various stages of
    the process?

 2. The new craze in classical networking as far as I can tell is
    segment routing. I don't know much about it, but my brief read on
    (http://www.segment-routing.net/) suggests that this is a classical
    mechanism that can be extended with QCaps. It even supposedly
    supports network programming which is exactly what you want to do.
    Would be worth investigating further.

Thanks,

Wojtek

On 13/03/2019 01:39, Rodney Van Meter wrote:
> We uploaded a draft on connection setup in a quantum network.  This 
> represents how our quantum Internet simulator actually does things 
> today, though the implementation isn’t yet truly complete.
> P.S. I don’t think any of the three new drafts that were uploaded have 
> correctly shown up as QIRG-related.  Will see what I can do to fix.
>
>
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---

From: Rodney Van Meter <[email-masked]>
Date: Fri, 15 Mar 2019 07:09:55 +0900

> On Mar 14, 2019, at 6:10 PM, Wojciech Kozlowski <[email-masked]> wrote:
> 
> Hi Rod,
> 
> I think I could benefit from a more specific use-case example. I am struggling a bit to understand at what stage these connections are made. Is this something that a network sets up ahead of time, or is this set up per flow and must be maintained for its duration? I think this would also shed light on how failures along the path should be handled. 

It could definitely use that.  Hopefully in the -01 draft.

We are assuming this is triggered by an application request. One good work item for QIRG is to advance our understanding of use cases.  In the foreseeable future, connection setup/teardown won’t be as fast as a TCP handshake, and connections will likely live for hours or days or longer; QKD, for example, is more likely to be in support of gateway-to-gateway IPsec than for every TLS session to Gmail or Amazon. But we think this mechanism will work across that range of possibilities.
> 
> At the moment I'm reading it as if it's set up per end-to-end connection. What happens if a node fails during various stages of the process?

Yes, it’s E2E setup we’re looking at here.  Although the goal is internetworking, in which case the endpoint in a particular notion can be the gateway to the wider internet.

At the moment, we have no fault tolerance built into this. Multipathing could be built on top of the rule-based repeaters; that’s something we’ve talked about but not yet pursued.
> 
> The new craze in classical networking as far as I can tell is segment routing. I don't know much about it, but my brief read on (http://www.segment-routing.net/ <http://www.segment-routing.net/>) suggests that this is a classical mechanism that can be extended with QCaps. It even supposedly supports network programming which is exactly what you want to do. Would be worth investigating further.

That’s a great topic of conversation. We haven’t attempted to compare it to segment routing. We actually developed the idea in the context of our Quantum Recursive Network Architecture (QRNA), https://arxiv.org/abs/1105.1238 <https://arxiv.org/abs/1105.1238>.

Let’s talk about segment routing here and/or in Prague. Anybody on the list got an opinion on segment routing?  (I might regret asking this…)

—Rod
>> [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: Fri, 15 Mar 2019 07:22:39 +0900

> On Mar 13, 2019, at 7:19 PM, Gelard Patrick <[email-masked]> wrote:
> 
> Hi Rod,
> 

Keeping in mind the continuous replenishment of link-level entanglement, yes.

In 1st generation repeater networks, the work of a repeater is
1. make link-level entanglement
2. manage errors: purification is error detection; this requires local operations and classical communication
3. lengthen entanglement: entanglement swapping splices together two short entangled states into one long one; this also requires LOCC
4. participate in managing the network: maintaining routing tables, traffic management, etc.

2 & 3 *are* small quantum computations, and they involve distributed states and sending classical messages.  Moreover, each node may be involved multiple times in the creation of a *single* E2E entangled state (Bell pair). And temporally...

> That's why you don't want to use the  « source »  and « destination »  terms for the connection level in a quantum network ? Because distributed quantum states coud be use to transform entanglement…

For two main reasons:
1. there may not even be data transferred between nodes; the entanglement might be used for some shared operation that doesn’t involve qubits moving back and forth via teleportation.  QKD is an obvious example, where both ends measure the entangled state and destroy it in order to get a classical bit.  No “source” or “destination”.
2. Temporally, operations may not even happen left-to-right along the chain of repeaters, again violating the notion that data is moving.  Sometimes, depending on how you think of things, the entangled state can be used atemporally.  I hesitate to say “backwards in time”, but one end can make use of its qubit before the e2e entanglement is actually even built.  This becomes most obvious in later generation networks, which is a complication we probably don’t want to get into here, but check out the diagrams in https://arxiv.org/abs/1701.04586 <https://arxiv.org/abs/1701.04586> if you want a headache or two.

—Rod

---

From: Gelard Patrick <[email-masked]>
Date: Fri, 15 Mar 2019 09:43:26 +0000

Thanks for your clear answers.

So there seem to be two types of infrastructures:

1/ Optical infrastructure to distribute entangled qubit pairs or to exchange classical messages. It seems to me that for this class of infrastructure the notion of source and destination still makes sense.

2/ A set of "virtual" quantum entanglement links layer carried by distributed Bell pairs. These entanglement links allowing to realize the services of entanglement swapping,  quantum cryptography, quantum state teleportation, super dense coding, distributed quantum computation,..... For this "infrastructure" class, the notions of source and destination are no longer relevant. 

/Patrick

De : Rodney Van Meter <[email-masked]> 
Envoyé : jeudi 14 mars 2019 23:23
À : Gelard Patrick <[email-masked]>
Cc : Rodney Van Meter <[email-masked]>; [email-masked]
Objet : Re: [Qirg] connection setup

On Mar 13, 2019, at 7:19 PM, Gelard Patrick <mailto:[email-masked]> wrote:

Hi Rod,

For two main reasons:
1. there may not even be data transferred between nodes; the entanglement might be used for some shared operation that doesn’t involve qubits moving back and forth via teleportation.  QKD is an obvious example, where both ends measure the entangled state and destroy it in order to get a classical bit.  No “source” or “destination”.
2. Temporally, operations may not even happen left-to-right along the chain of repeaters, again violating the notion that data is moving.  Sometimes, depending on how you think of things, the entangled state can be used atemporally.  I hesitate to say “backwards in time”, but one end can make use of its qubit before the e2e entanglement is actually even built.  This becomes most obvious in later generation networks, which is a complication we probably don’t want to get into here, but check out the diagrams in https://arxiv.org/abs/1701.04586 if you want a headache or two.

—Rod

/Patrick

De : Qirg <mailto:[email-masked]> De la part de Rodney Van Meter
Envoyé : mercredi 13 mars 2019 01:39
À : mailto:[email-masked]
Cc : Rodney Van Meter <mailto:[email-masked]>
Objet : [Qirg] connection setup

—Rod

mailto:[email-masked]

---

From: Rodney Van Meter <[email-masked]>
Date: Fri, 15 Mar 2019 19:03:48 +0900

Just quickly — there are a number of papers talking about entangled states that span multiple hops as if they represent a network themselves, talking about routing, etc. on top of those.

Personally, I am *opposed* to such terminology, since I think it obscures the dynamic and temporary nature of the entanglement. The very next state in sequence might be some other topology, and at any rate it’s all destroyed when you measure it out.

> On Mar 15, 2019, at 6:43 PM, Gelard Patrick <[email-masked]> wrote:
>