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

Hi Wojtek,

Please find the update in github.
https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6

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://qitf.org/
https://r4d.mercari.com

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=>
>>
>>