Subject: Re: [Qirg] comments on Use Cases draft

From: Bernardo Huberman <[email-masked]>
Date: Wed, 1 Dec 2021 23:25:28 +0000

My collaborator Bob Lund had this to say to your reply, which I concur with.

In what way does caching entangled pairs ahead of time not scale? Conceptually it is the same as allocating a network resource for future use, which of course is done all the time. The big difference is that the entangled quantum channel resource is consumed upon use.

One does not need to know who is talking to who ahead of time; the cached resource (entangled quantum channel) is a next hop network path. As long as a multi-hop path exists, anyone can talk to anyone on demand. How is this different from an IP network?

Caching in this manner is very flexible. When the network is small and QKD key creation is slow, more entangled pairs can be pre-positioned as next hop paths. As the network grows and key creation latency diminishes (hopefully), smaller caches can be used.

Bernardo
From: [email-masked] <[email-masked]>
Date: Saturday, November 20, 2021 at 1:02 PM
To: Bernardo Huberman <[email-masked]>
Cc: Rodney Van Meter <rdv=[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Qirg] comments on Use Cases draft
Hi, all,

Although that approach reduces latency for a given endpoint, it’s not considered a “solution” because it doesn’t scale, so can’t be used unless you know in advance who you want to talk to. At that point, you take the latency hit, so it remains a real cost.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<https://protection.greathorn.com/services/v2/lookupUrl/6e030f64-bce2-4290-bc66-79fb714ffc54/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=www.strayalpha.com>

On Nov 2, 2021, at 12:54 PM, Bernardo Huberman <[email-masked]<mailto:[email-masked]>> wrote:

Hello:

Your caveat about TLS (that QKD startup latency is very high) is easily solved by generating a cache of keys to use ahead of time.

This is the way it works in our implementation:

https://link.springer.com/article/10.1007/s10796-020-10086-5<https://protection.greathorn.com/services/v2/lookupUrl/e46bb801-a0df-4fad-afc0-ca4c1f4aba19/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=link.springer.com&path=/article/10.1007/s10796-020-10086-5>

or https://arxiv.org/abs/2007.05522<https://protection.greathorn.com/services/v2/lookupUrl/fadb5f6e-3fc7-4144-9e78-e6fe49fa37b2/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=arxiv.org&path=/abs/2007.05522>

Sincerely,

Bernardo Huberman
Fellow and VP
Next-Gen Systems
CableLabs
[email-masked]<mailto:[email-masked]>

From: Qirg <[email-masked]<mailto:[email-masked]>> on behalf of Rodney Van Meter <rdv=[email-masked]<mailto:rdv=[email-masked]>>
Date: Tuesday, October 19, 2021 at 5:43 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: Rodney Van Meter <[email-masked]<mailto:[email-masked]>>
Subject: [Qirg] comments on Use Cases draft
Chonggang et al.,

Some comments on
https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/

Crypto apps:

QKD should be generalized as creation fo shared, guaranteed secret classical bits. Their most obvious use case is keying of cryptogrqphic communication, either IPsec or TLS, with the caveat that latency of starting up a QKD connection is very high.
Should include secret sharing. with the caveat that it is a subroutine rather than an application.
Leader election. I think of this as crypto rather than distributed computing, but I suppose it can be either.

Clock sync. There are three completely independent proposals. Jozsa-Dowling, Chuang, and Komar-Lukin. Very different internally.

I think encephalography is a standalone app. Distributed imaging is Gottesman telescope interferometry.
More generally, there are several applications of entanglement as a reference frame.

Likewise, chemistry is a standalone app, no relationship to networking.

Blind computing is a platform technology, not an application. Any q app can be run remotely and safely using it. I think it's important to highlight that blind is client-server, like the original ARPANET.

In contrast to client-server, grouping together nodes simply to achieve scalability is like today's supercomputers or multicomputers. Work on this extends back to my Ph.D. thesis as well as work by Daniel Oi, Liang Jiang, and more recently Muhammed Ahsan. Most of the work has focused on the systems rather than the apps, though Yimsiriwattana and I both looked at Shor. My papers on multicomputers are already cited here, but this distinction between wide area/system area network and client-server v. symmetric multicomputer isn't conveyed clearly.

I'm not sure the control plane data plane discussion adds anything at all to the document.

BBM92 and E91 need to be discussed as entanglement-based QKD.

Enough for now. Hope this helps!

—Rod

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

_______________________________________________
Qirg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/qirg<https://protection.greathorn.com/services/v2/lookupUrl/21b03c5b-9510-4c8d-8438-58b449bcc36d/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=www.irtf.org&path=/mailman/listinfo/qirg>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 1 Dec 2021 16:05:36 -0800

It does not scale over multiple hops. Creating entangled pairs in advance over a single hop won’t reduce the latency across multiple hops; you have to perform teleportation throughout the network and establish entangled pairs between every pair of endpoints. That doesn’t scale either over hops or number of nodes.

If you merely create entanglement over a single hop, you haven’t done anything useful until after you coordinate their use over that link, which has the same latency cost across that link as creating the entanglement in the first place.

That doesn’t include the fact that maintaining those entangled pairs, even over a single hop, has real costs. And doesn’t automatically scale; creating more prepositioned entanglement, even over a single hop, requires more resources at that hop too.

—
www.strayalpha.com

> On Dec 1, 2021, at 3:25 PM, Bernardo Huberman <[email-masked]> wrote:
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> To: Bernardo Huberman <[email-masked] <mailto:[email-masked]>>
> Cc: Rodney Van Meter <rdv=[email-masked] <mailto:rdv=[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> www.strayalpha.com <https://protection.greathorn.com/services/v2/lookupUrl/6e030f64-bce2-4290-bc66-79fb714ffc54/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=www.strayalpha.com>
> 
> 
> On Nov 2, 2021, at 12:54 PM, Bernardo Huberman <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hello:
>  
> https://link.springer.com/article/10.1007/s10796-020-10086-5 <https://protection.greathorn.com/services/v2/lookupUrl/e46bb801-a0df-4fad-afc0-ca4c1f4aba19/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=link.springer.com&path=/article/10.1007/s10796-020-10086-5>
>  
> or https://arxiv.org/abs/2007.05522 <https://protection.greathorn.com/services/v2/lookupUrl/fadb5f6e-3fc7-4144-9e78-e6fe49fa37b2/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=arxiv.org&path=/abs/2007.05522>
>  
> Sincerely,
>  
>  
>  
> Bernardo Huberman
> Fellow and VP
> Next-Gen Systems
> CableLabs
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>  
>  
>  
>  
>  
> From: Qirg <[email-masked] <mailto:[email-masked]>> on behalf of Rodney Van Meter <rdv=[email-masked] <mailto:rdv=[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> Cc: Rodney Van Meter <[email-masked] <mailto:[email-masked]>>
> https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/ <https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/>
>  
> Crypto apps:
>  
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/qirg <https://protection.greathorn.com/services/v2/lookupUrl/21b03c5b-9510-4c8d-8438-58b449bcc36d/327/6f22b9b9adcc376ddedebf4a30bd18279a8af147?domain=www.irtf.org&path=/mailman/listinfo/qirg>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 1 Dec 2021 17:24:30 -0800

Yes, but those pairs don’t do anything until a path is created. That path still takes 1.5 RTTs to coordinate (a “three-way handshake”, the minimum required to established shared classical state between the path endpoints). So even if you deploy entanglement along all the hops, it doesn’t actually reduce the latency needed to create entanglement between path endpoints.

—

> On Dec 1, 2021, at 4:48 PM, Bob Lund <[email-masked]> wrote:
> 
> Entangled pairs are created along all paths that constitute next hops. The router at each hop decides which to use to get to the next hop.
> 
> On Wed, Dec 1, 2021 at 5:06 PM [email-masked] <mailto:[email-masked]> <[email-masked]> wrote:
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Dec 1, 2021, at 3:25 PM, Bernardo Huberman <[email-masked] <mailto:[email-masked]>> wrote:
>>