Re: [Qirg] Pull request for 'new challenges' subsection 'The first quantum networks may not be "routing and forwarding" networks.'

Hi Wojtek,

I've checked your changes. That new Error Management section is a good
idea. Thank you for editing.

--Shota
------------------------------------------------
永山翔太 Shota Nagayama, Ph.D.
shota.nagayama@mercari.com
https://shota.io/
https://qitf.org/
https://r4d.mercari.com

On Mon, Jul 13, 2020 at 6:23 AM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
wrote:

> Thanks Shota! I've merged the PR now. I also did some wordsmithing and
> what I hope is only minor editing. The main change is that I moved the bulk
> of the text to section 4.4. Please check my changes in this commit to see
> if you agree with them:
> <https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/22a1a836ef77a69353f2c9a9c846d62b75825bac>
> https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/22a1a836ef77a69353f2c9a9c846d62b75825bac
>
> The latest version of the doc is at:
> https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
>
> On Thu, 2020-07-02 at 21:09 +0900, Shota NAGAYAMA wrote:
>
> Hi Wojtek,
>
> Please find the update in github.
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_6&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hAQVW8IYSdukptpQ2e9CgMYkeDHoRaiBt4JYgVBZLtA&s=QmAcHej17jDgsIM4ZLpVKcFIcnoAjddxFJupdshDjus&e=>
>
> I have moved the section to a subsubsection of boundaries subsection. I
> would think that a subsection just after the boundaries subsection would
> also fit. Let me know what you think.
>
> --Shota
> ------------------------------------------------
> 永山翔太 Shota Nagayama, Ph.D.
> shota.nagayama@mercari.com
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hAQVW8IYSdukptpQ2e9CgMYkeDHoRaiBt4JYgVBZLtA&s=qLRWgPGjF36SoK3gLoDQHyvNiXq-amH1V-lg8bxyryA&e=>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=hAQVW8IYSdukptpQ2e9CgMYkeDHoRaiBt4JYgVBZLtA&s=-_qhf0ocXhVNLs3HVMrBFv6ZDuVgdW7Pwz64O8OVUJA&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=hAQVW8IYSdukptpQ2e9CgMYkeDHoRaiBt4JYgVBZLtA&s=0bqDCkO4ArL9Ny6-3Kbw3_Q0KcVDBmII5Iv4M6ez77c&e=>
>
>
> On Wed, Jul 1, 2020 at 9:36 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
> wrote:
>
> Thanks for the update! Once ready I'll incorporate it into the rest of the
> draft.
>
>
> And as a side note, I'm merely a NetSquid user, so credits go to the
> developers like Rob at QuTech (TU Delft and TNO) :)
>
> Wojtek
> ------------------------------
> *From:* Shota NAGAYAMA <shota.nagayama@mercari.com>
> *Sent:* 01 July 2020 14:14:30
> *To:* Wojciech Kozlowski
> *Cc:* qirg@irtf.org
> *Subject:* Re: [Qirg] Pull request for 'new challenges' subsection 'The
> first quantum networks may not be "routing and forwarding" networks.'
>
> Hi Wojtek,
>
> First, congrats for releasing the new version of NetSquid.  I like that
> NetSquid supports multiple physical systems, which leads to compatibility
> and supporting heterogeneity.
>
> Sorry for late reply. I think your points are reasonable and I'm working
> on updating my PR. ETA is tomorrow Japan time.
>
> ------------------------------------------------
> 永山翔太 Shota Nagayama, Ph.D.
> shota.nagayama@mercari.com
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=Cv2RycNrOtjVYN1msMMte_k-RnLAz4_QqkdVxVfHpSY&s=-xmzKuNU5s_-ZpLZANdl9oRqYYpPJLsMYaiy9NiDxzk&e=>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=Cv2RycNrOtjVYN1msMMte_k-RnLAz4_QqkdVxVfHpSY&s=EDg5DpmQwC2R4CFHVu8CERI8ANfJUKddh0Aslz_wSn4&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=Cv2RycNrOtjVYN1msMMte_k-RnLAz4_QqkdVxVfHpSY&s=WynuQJqBIHjpE_rf9EgsedU-3JE0az6iwtVzq5jLwA4&e=>
>
>
> On Wed, Jun 10, 2020 at 9:37 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
> wrote:
>
> Hi Shota,
>
> I finally had a proper look at your generations PR.
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_6&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=Cv2RycNrOtjVYN1msMMte_k-RnLAz4_QqkdVxVfHpSY&s=JNJMjOmgAccYiN-Gahba0P27y5CpgIUIKupjR_iibGk&e=>
>
> First, thanks for contributing the section. Following various discussions
> on the mailing and the virtual interim, it's pretty clear that this section
> would be quite valuable.
>
> I do think it needs some work though. I think what needs to be said is
> already present in the text, it just needs some clarifying to make the key
> points more obvious.
>
>
>    1. Currently the text does say that there are three categories of
>    quantum networks and that error correction has something to do with it, but
>    I think this needs to be made clearer. I'm not sure I'd reach this
>    conclusion by reading the current text. Rodney used some very good phrasing
>    in one of his e-mails:
>
>    "acknowledge that not only are there physical differences
>    and administrative boundaries, but there are important distinctions in
>    how errors will be managed, which affects the content and semantics
>    of messages that must cross those boundaries, as well -- both
>    for connection setup and real-time operation"
>
>    The first paragraph needs to really make it clear that the point is
>    that error management is the distinguishing factor and it will impact
>    protocol design. Worth also clarifying terminology here that generations
>    does not imply a time progression and that it's more like categories.
>    Following that point, I feel it's also important to state that the
>    generations do not obsolete each other and which one is used depends on the
>    particular hardware platform in use.
>
>    2. Distillation has its own subsection just a bit above this section
>    and some error-correction statement are strewn around the text. It might be
>    worth moving all of that into this section and also having a small
>    subsection explaining what you mean by the quantum error correction you
>    mention a bit more.
>
>    3. The table is great, but worth defining what is meant by "loss
>    tolerance", "error tolerance", and "signaling".
>
>    4. With all that above, then I don't think you need to have much text
>    to describe each generation. In my opinion a description of the procedure
>    is not necessary. The signalling needs can instead be explained in the
>    distillation and error-correction sub-sections. Then one can figure out
>    what signalling is needed for which generation from the table. The first
>    sentences of each point are great so I'd keep those, probably worth adding
>    more words to explain in a bit more detail.
>
>    5. You say that 3G implies store and forward. I think we should phrase
>    it as 3G enables store and forward, but can still be used for "store and
>    swap". This is an important point as otherwise it implies we need to redo
>    all protocols to be store and forward.
>
>    6. You also write that the document focuses on 1G. Having thought
>    about it I think the document is pretty lax by not proposing any
>    architecture so I don't think this needs to be said. Instead, it is focused
>    on what you called "store and swap" which can apply to all generations as
>    opposed to "store and forward" which is only possible with 3G.
>
>
> What do you think?
>
> Cheers,
> Wojtek
>
> On Tue, 2020-05-19 at 05:37 +0900, Shota NAGAYAMA wrote:
>
> Hi Wojtek,
>
> First, thank you for merging :)
> I merged the sentences separated from PR #5 to PR #6.
>
> I agree that either categories or classes is a better terminology than
> generations. This document may be the only chance to start to use better
> terminology. I think that we should still mention the word "generations" to
> clarify the rephrase.
> Latter pointings are also correct, I think.
>
> Best,
> Shota
> ------------------------------------------------
> 永山翔太 Shota Nagayama
> shota.nagayama@mercari.com
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=6SusBnyxiK4COPuWloD3hqyE85X738UHYZGXdf85BKo&s=16eXajOvxfE3M0UufTw7zjuoEe7890SB7SqR7m1qXdQ&e=>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=6SusBnyxiK4COPuWloD3hqyE85X738UHYZGXdf85BKo&s=04UPINqByeZyLsczaUtcEwgmmZtRbsjZJegTtmvoM-E&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=6SusBnyxiK4COPuWloD3hqyE85X738UHYZGXdf85BKo&s=M2K2xcdXFtDedecE270SB41E_E9aSxLcvBuM7RZ8Lic&e=>
>
>
> On Wed, May 13, 2020 at 5:57 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
> wrote:
>
> Hi all,
>
> Following a discussion with a colleague of mine who is more familiar than
> me on the literature on repeater generations here are some thoughts. This
> should answer the questions raised about 3G and store-and-forward.
>
> This is with regards to Shota's PR:
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_6&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=6SusBnyxiK4COPuWloD3hqyE85X738UHYZGXdf85BKo&s=krnoezkDsQjQZ9P97dyyQvYHvKPuWqmXgS3Gyz5r7Uc&e=>
>
> A lot of what I say can be read up further on in one of the articles I
> linked earlier, which is open access:
> https://www.nature.com/articles/srep20463.pdf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nature.com_articles_srep20463.pdf&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=6SusBnyxiK4COPuWloD3hqyE85X738UHYZGXdf85BKo&s=52HkYtna47wDL_1Y_tFCC2BfkxRpAdsPhz1HQAtPkrg&e=>
>
> First of all: the name "generations" is slightly confusing. It implies a
> definite temporal progression. In some sense there is a temporal
> progression as 2G and 3G have signifiant hardware requirements (number of
> qubits and gate quality) which are not possible at the moment. However, the
> authors of the linked paper above, say that these generations are merely
> *categories*, and which generation's architecture is best depends on your
> hardware parameters as summarised with the plots in Fig. 6 of the linked
> paper. The generations in some sense represent what hardware trade-off is
> being made.
>
> So the section on generations in the draft should definitely emphasize
> that this is not a temporal progression where 2G obsoletes 1G and 3G
> obsoletes 2G. Some might argue we should choose a better name, but I'd
> rather not reinvent terminology in this draft as it will make it difficult
> to understand the references and existing academic literature.
>
> Second: store-and-forward vs store-and-swap. A particular feature of 3G is
> that it enables what is called "one-way signalling" which means that we can
> send qubits hop-by-hop from source to destination. However, just because we
> can does not mean we have to. We can also simply use this one-way signaling
> to create entangled pairs as well. A problem with 3G though is that because
> "one-way signalling" can only tolerate up to 50% losses the repeater is
> more constrained and as was pointed out - rebuilding an infrastructure is
> not a sane solution.
>
> I suspect that even once 3G becomes possible we may want to stick to Bell
> pairs anyway. Though they may be created differently in 3G as they don't
> use heralding. Bell pairs have advantages that one-way signalling does not.
> Intuitively, it appears far better suited for traffic-engineering purposes
> because you can distribute entangled pairs before the user needs them. With
> one-way signaling, just like in classical networks you would only be able
> to engineer once it actually is flowing. The advantage of 3G though is that
> it will rely less on connection-oriented architectures which may be
> beneficial in some circumstances. Perhaps what we will see is entangled
> pairs in the core/backbone and one-way signalling when connecting to users.
>
> So another point we would need to make in the draft is that 3G =/=
> store-and-forward. It simply enables store-and-forward, but 3G can still be
> used for store-and-swap.
>
> Third: there are other engineering trade-offs to take into account in
> between the generations that may have to be reflected at the protocol
> level. 1G uses heralded entanglement generation and purification, both of
> which require two-way classical communication. 2G uses heralded
> entanglement generation, but error-correction instead of purification.
> Error-correction requires only one-way classical signalling. 3G uses
> error-correction to overcome losses as well as operational errors and no
> longer requires two-way classical signalling.
>
> This is a point worth making in the draft as it will translate into
> protocol design.
>
> What's next? If anybody has anything to add/correct me, ask questions,
> please go ahead. Once there is nothing more to add Shota and I will extract
> the conclusions and reflect them in the PR.
>
> Regards,
> Wojtek
>
> On Sun, 2020-05-03 at 13:27 +0900, Shota NAGAYAMA wrote:
>
> I have the same understanding; the progression 1G->2G->3G is about
> reducing latency. The problem caused by this latency is not only
> decoherence but the occupation of the memory qubits. The next Bell pair
> generation cannot start during this latency. This will hit the performance.
>
> Wojtek, I separate the pull request and merged your proposed changes to my
> PR. Please see it.
>
> ------------------------------------------------
> 永山翔太 Shota Nagayama
> shota.nagayama@mercari.com
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=hvo4RtMWFHwRl8UqmDpyhSXz5wVhDfmHOIkg9WhX67Q&e=>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=PivNY9mnrbRsBeFBto3cl7pNKq7iJJlRGqeBQN5Ip8c&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=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=5RtpHFHRPogNJ5xHCcdXBR0qL0Q4xpMzbiwFTHde8eM&e=>
>
>
> On Tue, Apr 28, 2020 at 11:00 PM Wojciech Kozlowski <
> W.Kozlowski@tudelft.nl> wrote:
>
> Fair point Mathias.
>
> I'm still thinking about how best to include the generations into the
> draft. Most practical work is focused on what some call the first
> generation and the draft itself is heavily inspired by this particular
> generation.
>
> Subsequent generations describe the new possibilities as our technological
> capabilities increase. I'm not exactly clear if a new generation fully
> obsoletes the previous one, because whilst they improve upon the previous
> generation in certain aspects they also come with higher requirements in
> other areas.
>
> I'm pretty sure there is quite a bit of interest in including generations
> in this draft - at least a mention on what they are even though the focus
> is on the first. I think this point merits some discussion so I wills start
> off by leaving two articles that I usually refer to on this subject:
>
> - https://www.nature.com/articles/srep20463
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nature.com_articles_srep20463&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=4JKywxFHCPgIvFZef4QSi5To3q-HHTLmZQXfsKYacuc&e=>
> (should be open access)
> - https://ieeexplore.ieee.org/abstract/document/7010905/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ieeexplore.ieee.org_abstract_document_7010905_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=p8vXtRSBi2vSBoXf7GDRh7KTMzkKliOjQ01Z_g0z1d4&e=>
>
> The second article isn't open access and I can't find an arXiv version.
> I'm not the author so I'm not sure how okay it is to just share the pdf on
> a public mailing list as much as I'd like to do just that. I'd rather avoid
> the same trouble Sci-Hub got into. If somebody who knows copyright law
> knows how to correctly distribute such articles, please let me know.
>
> To answer your question Mathias, I tried phrasing that 3G enables rather
> than warrants direct transmission though I have some reading up to do since
> I don't really spend much time thinking about anything other than 1G. It
> may be, that as you say, that an infrastructure we deploy puts certain
> constraints on how the technology develops which is sort of the reason why
> I don't spend much time thinking about what will be when 3G becomes
> possible.
>
> Ultimately, my impression is that the progression 1G->2G->3G is more about
> reducing classical communication that causes latency. As Scott said, we can
> send Megabytes of data if that helps, but latency is usually the focus in
> this progression.
>
> Thanks,
> Wojtek
>
>
> On Mon, 2020-04-27 at 15:18 +0000, Scott Fluhrer (sfluhrer) wrote:
>
> I would like to point out that there are certainly classical networks that
> use “circuit switching”, that is, setting up a long term network path
> between two end points, and then using that path to allow the two end
> points to communicate.  Examples of this would be both MPLS and OTN.
>
>
>
> On the other hand, we shouldn’t feel constrained to do what classical
> networks do.  For one, the relative costs for a Quantum Network would be,
> at times, radically different than the corresponding costs for a classical
> one.  For a Quantum Network, control traffic (that is, the traffic used to
> manage the flow through the network) can be done using classical bits, and
> so are almost free in comparision to the data traffic bits (which are
> qubits); if we could reduce by one the number of qubits that need to be
> exchanged, at the cost of exchanging a megabyte of classical control
> traffic, it would make sense for us (but would make absolutely no sense in
> the classical case).
>
>
>
> Hence, while it makes sense to use classical protocols as a source of
> ideas (they thought about it a lot, and so perhaps we can reuse some of
> what they came up with), we need to remember that the things they optimized
> for are not always the things we need to optimize for…
>
>
>
> *From:* Qirg <qirg-bounces@irtf.org> *On Behalf Of *VAN DEN BOSSCHE
> Mathias
> *Sent:* Monday, April 27, 2020 10:34 AM
> *To:* qirg@irtf.org
> *Subject:* Re: [Qirg] Pull request for 'new challenges' subsection 'The
> first quantum networks may not be "routing and forwarding" networks.'
>
>
>
> Hi all,
>
>
>
> Looking at the discussion on github, I am a bit puzzled at this idea of
> store-and-forward.  Actually, it deserves a motivation.
>
> As we put it in the early generations, QIN establish an end-to-end
> entanglement link, and when it is ready, use it to send qbits directly end
> to end.
>
> In a telephone network, it is like pulling a new copper or a new fiber
> anytime you want to make a call.
>
>
>
> Later generations are proposed that tend to look more like classical
> networks (store-and-forward, i.e. routing, transport, etc).
>
> It is clear that doing this will require progress in the nodes. But is it
> worth the pain? Of course in classical networks, pulling a new line is
> awfully costly.
>
> Would it be so with entanglement ? Do we have to let us drive by analogy
> with classical networks? Aren’t there more options for
>
> next generations (e.g. quantum broadcast with multipartite entanglement,
> etc)?
>
>
>
> Just to get some light
>
>
>
> Mathias
>
>
>
>
>
>
>
> [@@ THALES ALENIA SPACE INTERNAL @@]
>
>
>
> *De :* Qirg [mailto:qirg-bounces@irtf.org <qirg-bounces@irtf.org>] *De la
> part de* Wojciech Kozlowski
> *Envoy**é :* lundi 27 avril 2020 14:20
> *À :* shota.nagayama@mercari.com
> *Cc :* qirg@irtf.org
> *Objet :* Re: [Qirg] Pull request for 'new challenges' subsection 'The
> first quantum networks may not be "routing and forwarding" networks.'
>
>
>
> Hi Shota,
>
>
>
> Thanks for the update! I've just reviewed it:
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/5#pullrequestreview-400873270
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_5-23pullrequestreview-2D400873270&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=0t7Khb_IckCCk62CLYBL3K6GC1lJFnJi-SxvcdXy0ps&s=td4j-NUySEg_1AMWyxCg-xLep1ki_8m7xCxi-XeeOV8&e=>
>
>
>
> Summary of my comments (follow the link for details):
>
>
>
> I would like to spend some more time on the generation section though. I
> need to think more about what this section should contribute to the
> document. There is nothing wrong with what you wrote, I'd just rather not
> include it until I'm clear on what its contents should be and then I'll
> come back to your contribution.
>
> However, the text about directionality, once you have a look at my
> proposed changes, can already be included. Since the generation section is
> currently in the same PR, if you would like your contributions merged
> sooner, please submit the section about generations as a separate PR, and I
> will merge the rest.
>
>
>
> Thanks,
>
> Wojtek
>
>
>
> On Sat, 2020-04-18 at 08:35 +0900, Shota NAGAYAMA wrote:
>
> Hi Wojtek,
>
>
>
> I've updated the pull request.
>
> I meant to clarify that routing would be the same, however, it might have
> been confusing. I have left out routing; just store-and-forward and
> store-and-swap are compared. And I added a section about generations.
> Please see other points on the pull request page and the document.
>
>
>
> --Shota
>
> ------------------------------------------------
>
> 永山翔太 Shota Nagayama
>
> shota.nagayama@mercari.com
>
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=W1Dk7HRbhwba24hJPb0j3cNNRjQX3Qhi-qYejXhGGdY&e=>
>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=QjsA76ECOj4SzbwZP1_NVqZbEi18Eaq7kx1Ty8PbVvg&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=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=SA7SzipWOrNiFcQfsdO72wJheFD3TpWHiYjuW9gVXB4&e=>
>
>
>
>
>
> On Fri, Apr 3, 2020 at 6:32 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
> wrote:
>
> Hi Shota,
>
>
>
> Thanks for your contribution!
>
>
>
> I've reviewed your update. My detailed review comments are on the GitHub
> repo:
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/5#pullrequestreview-387089034
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_5-23pullrequestreview-2D387089034&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=AdZ85HJUabhoLYQUDalsUH2UWKETdx8VYzF89o2FgTI&s=epUqRQwb6LPd2qi2Qipww5ec3JG1D74NvadCBq7WQNQ&e=>
>
>
>
> In summary:
>
>
>
> Overall, I think your contribution makes a very important point that will
> be very useful for people coming from a classical background. My comments
> are mostly about clarifying what you meant. With further clarifications,
> your contribution can be merged.
>
>
>
> I am also not sure about this "routing and forwarding" and "routing and
> swapping" terminology. Is it common? I know of "store-and-forward" and
> perhaps we can say "store-and-swap" which highlights the need for memory
> (some proposals do not need a memory, not sure if they will be practical
> any time soon though). Also "store-and-swap" suggests we can keep things in
> memory for a long time which is not the case. I think this would be a good
> point to discuss. I would definitely suggest leaving routing completely out
> of this section as it is not actually discussed at all.
>
>
>
> Wojtek
>
>
>
> On Tue, 2020-03-31 at 14:02 +0900, Shota NAGAYAMA wrote:
>
> Hi Wojtek,
>
>
>
> How are things going? I'm looking forward to your review.
>
>
>
> BTW, it's very nice that now you are a co-chair of the group :)
>
>
>
> Thanks,
>
> Shota
>
> ------------------------------------------------
>
> 永山翔太 Shota Nagayama
>
> shota.nagayama@mercari.com
>
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=e7e0ouv4Yq7s8KyDdBBHKM7RF-nKr_0iLOZsRcyKMxk&e=>
>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=y3h0gz6GnUT9x1OpbKkqX_2CMG3DZ5pMnFpmwIExaTI&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=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=7AWoJwX6ypg-cUFHSwdyQaxiRB4mWAUdlwWH0CMNmyg&e=>
>
>
>
>
>
> On Mon, Mar 9, 2020 at 5:53 PM Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
> wrote:
>
> Hi Shota,
>
>
>
> Thanks for your contribution. I haven't had time to look at it yet so I
> won't include it in the draft I upload today. I will try to review it
> before Vancouver though so at least the work can still go on.
>
>
>
> Thanks,
>
> Wojtek
>
>
>
> On Fri, 2020-03-06 at 01:51 +0900, Shota NAGAYAMA wrote:
>
> Hi,
>
>
>
> I finally made a pull request for 'The first quantum networks may not be
> "routing and forwarding" networks.' subsection in the new challenges
> section. This subsection tells what is caused by the fact that Bell pairs
> are undirected network resources. Please find it.
>
>
>
> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/5
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_5&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=-sTHDClmClG4EIhCAKj9azqNfPLpgPb_e0cEi-3bmys&e=>
>
>
>
> ------------------------------------------------
>
> 永山翔太 Shota Nagayama
>
> shota.nagayama@mercari.com
>
> https://shota.io/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__shota.io_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=Qx2Pi5RpW5eFvMfMQc_CwyafjSl8U7c1ZtiUXV8imDo&e=>
>
> https://qitf.org/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__qitf.org_&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=n0L3EMEwnxHvv2LAuLvgxvvKDoaCjL9PRCiPtFfUTV8&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=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=fOR-fYIq-0jJJzCMkbmHPjRgDX9VvP5tEEGb7S39W4M&e=>
>
> _______________________________________________
>
> Qirg mailing list
>
> Qirg@irtf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=wLaiWvpUZ5lb_P0nUOLjyde3okLuO2zPyxHFWPr3_VM&s=AsjKClF3rnjkQc4PUebFFsqBP_YQrh5cNjyCqvalD68&e=
>
>
>
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> 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=SSe8nfX7Q27kWqyic_1YxDWtHXWE-492zzxBnKyvcDA&s=xwTVo7VAuf97wRriYn1xNDrsJRtkD5tIx94Wcce68ps&e=>
>
> _______________________________________________
>
> Qirg mailing list
>
> Qirg@irtf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=0t7Khb_IckCCk62CLYBL3K6GC1lJFnJi-SxvcdXy0ps&s=Qh9EQs0OUnn6Nw3voV0VAFmol43Sv3zKY00Q5qBGaFA&e=
>
>
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> 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=ywdoeO2kmt37_bGWQtCGt9gZSf43JBDSdN1Ln9LR4Z4&s=HdHbxHeMvK3Hj8qOHkgo1KEpEAOlGmQ0Fv2Pmm5bnH8&e=>
>
>
>