Subject: [Qirg] Update to draft-irtf-qirg-principles

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 17 Feb 2020 10:17:32 +0000

Dear QIRG,

I have just added a contribution to the elementary link generation section.
Thank you Sara and Marcello.

Latest version: 
https://github.com/Wojtek242/draft-irtf-qirg-principles/blob/master/draft-irtf-qirg-principles-03.txt

Diff: 
https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/3952b2f15f3720325ce42c61c8857a2ede1a0f2e

Moving forward: my plan is now to finalise the principles/goals sections. Some
feedback has already been given on this subject and I will try to make sure I
take it all into account.

I propose that for this part, I first write the update myself based on feedback
received so far. If you have something to add with regards to this section,
please share on the mailing list as soon as you can. I will then upload an
update some time next week so that I can incorporate any feedback (deadline for
drafts for this IETF is 9 March).

Unless these last updates lead to much debate, I'd think this will mark the
last few updates to the draft (+ pending PRs). In this case, I would aim to
start finalising it after Vancouver. If there are any contentious issue, I will
aim to resolve them on the mailing list before the next meeting.

Thanks,
Wojtek

---

From: Rodney Van Meter <[email-masked]>
Date: Fri, 21 Feb 2020 08:52:54 +0900

For an architecture doc, I’d say one of the things we need to do is substantially raise the # of references, in context, of course.

For link-layer architectures with memory, there are three major ways you can organize:

* memory-to-memory (M—>M)
* midpoint interference, which we call M—>I<—M and Cody calls meet-in-the-middle
* midpoint source, which we call M<—S—>M

Best reference on these is
https://iopscience.iop.org/article/10.1088/1367-2630/18/8/083015/meta <https://iopscience.iop.org/article/10.1088/1367-2630/18/8/083015/meta>
which, blessedly, is open access.

I saw a message about a presentation — have we restarted telecons on this doc?  If so, my apologies on missing that announcement.

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

> On Feb 17, 2020, at 19:17, Wojciech Kozlowski <[email-masked]> wrote:
> 
> Dear QIRG,
> 
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---

From: Shota NAGAYAMA <[email-masked]>
Date: Fri, 21 Feb 2020 21:20:50 +0900

Hi,

I think this document should explicitly explains that quantum networks may
and may not execute forwarding (data) in Subsec. 5.1.
Routing and forwarding are different functionalities. Routing decides which
way to go, forwarding executes the transfer obeying the decision.
The 1st and the 2nd generation (Muralidharan's definition) quantum networks
execute routing and swapping, instead of forwarding.
The 3rd generation does routing and forwarding.

"Routing and swapping" might have to be "routing and measuring". "Routing
and measuring" can intuitively cover broader ideas, such as graph
state-based routing and surface code quantum communication, that don't
execute forwarding and don't execute even entanglement swapping, but
execute measurements. (Of course, entanglement swapping has measurements)

Muralidharan's three generations should not be explicitly mentioned in the
document since more types (generations) of quantum networks would appear in
the future.
However, I would believe that any types of quantum networking belong to the
roughly divided two types of quantum networks, "routing and measuring" and
"routing and forwarding". Hence those two types would be worth writing. At
least, it is worth writing that forwarding may not exist, as the unique
distinction of quantum networking.

Such a new section will help network-backgrounded people who may
unconsciously suppose store and forward system.

The current document implies that there are generations of quantum networks
(Subsec. 4.2 Direct transmission mentions "generation"), but no section
summarizes generations. The new explanation would solve the wonder of
readers raised by the implication.

How do you think?

I'm going to make a pull request. Please see that.
------------------------------------------------
永山翔太 Shota Nagayama
[email-masked]
https://shota.io/
https://qitf.org/
https://r4d.mercari.com

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 24 Feb 2020 12:37:51 +0000

> For an architecture doc, I’d say one of the things we need to do is substantially raise the # of references, in context, of course.

This is something I was wondering about and it came up when I was working with Sara on the elementary link generation. What is the right number of references? As an IRTF document (as opposed to an IETF doc) we have flexibility to define what is suitable. Here are some of my thoughts on this:

  1.  I kept the number of references light, because the intended audience who will benefit the most from this doc (IETF folk) will probably not benefit much from dense physics-heavy quantum networking academic literature.
  2.  This is an intro document to set the stage for further discussion, not an academic review of the field.
  3.  Academics for understandable reasons care about being cited, but RFCs don't go into a citation count anyway (I think).
  4.  Nevertheless, adding references means that the interested reader knows where to look and acknowledges the fields' origin.

There is likely a meaningful compromise between my spartan reference list and a full blown review reference list which will cite a 100 papers before the end of the first paragraph. Thoughts, citation suggestions, and PRs all welcome on this topic.

Opinions from readers on the list who are not physicists or academics particularly welcome.

> For link-layer architectures with memory, there are three major ways you can organize:

I believe this has been included now in the elementary link generation section..

Thanks,
Wojtek
________________________________
From: Rodney Van Meter <[email-masked]>
Sent: 21 February 2020 00:52:54
To: Wojciech Kozlowski
Cc: Rodney Van Meter; [email-masked]
Subject: Re: [Qirg] Update to draft-irtf-qirg-principles

Best reference on these is
https://iopscience.iop.org/article/10.1088/1367-2630/18/8/083015/meta<https://urldefense.proofpoint.com/v2/url?u=https-3A__iopscience.iop.org_article_10.1088_1367-2D2630_18_8_083015_meta&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=9oGH87PwWnOQaZwYFdfDUQYApf4nsDV8Q_-j1B3JBwo&s=ZQsgkvPhFyR8dh5MzPsi7hluRSVQ6-5Yu2mKaLvm6bM&e=>
which, blessedly, is open access.

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

On Feb 17, 2020, at 19:17, Wojciech Kozlowski <[email-masked]<mailto:[email-masked]>> wrote:

Dear QIRG,

Latest version:
https://github.com/Wojtek242/draft-irtf-qirg-principles/blob/master/draft-irtf-qirg-principles-03.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_blob_master_draft-2Dirtf-2Dqirg-2Dprinciples-2D03.txt&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=9oGH87PwWnOQaZwYFdfDUQYApf4nsDV8Q_-j1B3JBwo&s=h8UTII244xcn9ku-GQ1u1c--qrLT2IQb_IJrj_IRk00&e=>

Diff:
https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/3952b2f15f3720325ce42c61c8857a2ede1a0f2e<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_commit_3952b2f15f3720325ce42c61c8857a2ede1a0f2e&d=DwQFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=9oGH87PwWnOQaZwYFdfDUQYApf4nsDV8Q_-j1B3JBwo&s=Fja4CVs6SXH5qSbkXF680Wx7RdABeTNEERA0i8uRiPs&e=>

Thanks,
Wojtek
_______________________________________________
Qirg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/qirg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwQFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=9oGH87PwWnOQaZwYFdfDUQYApf4nsDV8Q_-j1B3JBwo&s=CtiWk0MpzuFjuCfRQP0wmd1MZnFQPOkQHnseUuJRiwo&e=>

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 24 Feb 2020 12:41:10 +0000

> I saw a message about a presentation — have we restarted telecons on this doc?  If so, my apologies on missing that announcement.

There isn't enough time really to organise a teleconf on this doc before the 9 March deadline for drafts so I'll be posting an update soon and having a discussion on the mailing list. However, I have realised that the last section should definitely reflect more than just my thoughts so I will try to organise a face-to-face meeting at the IETF (with a bridge for remote participants). I noticed the preliminary schedule placed us on Tuesday so Monday would be good - will send details later.

Wojtek

Rodney Van Meter

Dear QIRG,

Latest version:

Diff:

Thanks,
Wojtek

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 24 Feb 2020 13:13:03 +0000

There's a lot of good points here.

> I think this document should explicitly explains that quantum networks may and may not execute forwarding (data) in Subsec. 5.1.

I think it's already mentioned somewhere, but worth reiterating if it's not clear.

> quantum networks execute routing and swapping, instead of forwarding

This is correct, but ultimately I would put swapping and forwarding under the umbrella of "data plane". It is definitely worth clarifying that the first generations of quantum networks will swap generic pairs as opposed to forward user-data, but beyond that I'm not sure how much more needs to be done. First, we must be careful to drop the word "forwarding" in case it does appear somewhere in the draft. Second, define in much clearer text what is expected from the data plane - however, given that this definition may shift as these networks get built over the coming years this shouldn't be too restrictive.

> "Routing and swapping" might have to be "routing and measuring". "Routing and measuring" can intuitively cover broader ideas, such as graph state-based routing and surface code quantum communication, that don't execute forwarding and don't execute even entanglement swapping, but execute measurements. (Of course, entanglement swapping has measurements)

Perhaps, going back to my previous point - put it all under data plane action and explain what action that might be.

> suppose store and forward system

This also raises a good point - whilst this problem is explained indirectly as swapping and decoherence in the draft at no point does it say explicitly that  neither the store nor forward concepts of store-and-forward work very well in the first generation networks.

> The current document implies that there are generations of quantum networks (Subsec. 4.2 Direct transmission mentions "generation"), but no section summarizes generations. The new explanation would solve the wonder of readers raised by the implication.

Very good point. The draft basically only explains enough concepts for the first generation and it is probably worth sticking to it given that these are in the process of actually being built in labs. But it would be worth explaining in some moderate detail what the road ahead might look like.

> I'm going to make a pull request. Please see that.

This would be welcome.

Thanks,

Wojtek

________________________________
From: Shota NAGAYAMA <[email-masked]>
Sent: 21 February 2020 13:20:50
To: Wojciech Kozlowski
Cc: [email-masked]
Subject: Re: [Qirg] Update to draft-irtf-qirg-principles

Hi,

I think this document should explicitly explains that quantum networks may and may not execute forwarding (data) in Subsec. 5.1.
Routing and forwarding are different functionalities. Routing decides which way to go, forwarding executes the transfer obeying the decision.
The 1st and the 2nd generation (Muralidharan's definition) quantum networks execute routing and swapping, instead of forwarding.
The 3rd generation does routing and forwarding.

"Routing and swapping" might have to be "routing and measuring". "Routing and measuring" can intuitively cover broader ideas, such as graph state-based routing and surface code quantum communication, that don't execute forwarding and don't execute even entanglement swapping, but execute measurements. (Of course, entanglement swapping has measurements)

Muralidharan's three generations should not be explicitly mentioned in the document since more types (generations) of quantum networks would appear in the future.
However, I would believe that any types of quantum networking belong to the roughly divided two types of quantum networks, "routing and measuring" and "routing and forwarding". Hence those two types would be worth writing. At least, it is worth writing that forwarding may not exist, as the unique distinction of quantum networking.

Such a new section will help network-backgrounded people who may unconsciously suppose store and forward system.

The current document implies that there are generations of quantum networks (Subsec. 4.2 Direct transmission mentions "generation"), but no section summarizes generations. The new explanation would solve the wonder of readers raised by the implication.

How do you think?

I'm going to make a pull request. Please see that.
------------------------------------------------
永山翔太 Shota Nagayama
[email-masked]<mailto:[email-masked]>
https://shota.io/<https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=mdcx9G2TAEosKgcW5QzHKwoLNFc53LUlK0mwjFBU33M&s=vBNOZMRv6Rsz36pvi3DzvnfM58WIB5lNgmbAC1G20v4&e=>
https://qitf.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=mdcx9G2TAEosKgcW5QzHKwoLNFc53LUlK0mwjFBU33M&s=alX2gr-JJ062fMsN2j9xVs0DeoMBBXfb-3a2F_9n5ms&e=>
https://r4d.mercari.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__r4d.mercari.com&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=mdcx9G2TAEosKgcW5QzHKwoLNFc53LUlK0mwjFBU33M&s=GTb2pgBmlBAsixMFOa_67p4p1LqYMW0rdanfD0ATZs8&e=>

On Mon, Feb 17, 2020 at 7:17 PM Wojciech Kozlowski <[email-masked]<mailto:[email-masked]>> wrote:
Dear QIRG,

Latest version:
https://github.com/Wojtek242/draft-irtf-qirg-principles/blob/master/draft-irtf-qirg-principles-03.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_blob_master_draft-2Dirtf-2Dqirg-2Dprinciples-2D03.txt&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=mdcx9G2TAEosKgcW5QzHKwoLNFc53LUlK0mwjFBU33M&s=PB6R4ikTK78IeWosVGptAhTva9qeCNukIULIvP9OACk&e=>

Diff:
https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/3952b2f15f3720325ce42c61c8857a2ede1a0f2e<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_commit_3952b2f15f3720325ce42c61c8857a2ede1a0f2e&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=mdcx9G2TAEosKgcW5QzHKwoLNFc53LUlK0mwjFBU33M&s=Kqr3cIYos22_BE1c6wneixG8jDXvAfFbwUO3I57y5iw&e=>

Thanks,
Wojtek
_______________________________________________
Qirg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/qirg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=mdcx9G2TAEosKgcW5QzHKwoLNFc53LUlK0mwjFBU33M&s=y2AfhD-2kk1yhLSKQve-89EhZhBX-4mX4OxCRsf31zs&e=>