Re: [Qirg] Pull request for 'new challenges' subsection 'The first quantum networks may not be "routing and forwarding" networks.'
Shota NAGAYAMA <shota.nagayama@mercari.com> Wed, 01 July 2020 12:14 UTC
Return-Path: <shota.nagayama@mercari.com>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E981C3A0A1E for <qirg@ietfa.amsl.com>; Wed, 1 Jul 2020 05:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mercari.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ff4MZcGlRvj for <qirg@ietfa.amsl.com>; Wed, 1 Jul 2020 05:14:43 -0700 (PDT)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455483A0959 for <qirg@irtf.org>; Wed, 1 Jul 2020 05:14:43 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id k18so11836705ybm.13 for <qirg@irtf.org>; Wed, 01 Jul 2020 05:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mercari.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BHLyyH6vGfsZ/QN9SdywOPLDVma4tVKVqCV+Tv3iIOs=; b=Ucy/5SM8ZTLlwYHGLYM7xucePro2ujmXjnc2+NZSDiTSum765g7wkJnw3n2eDeRSmP lMno3eFrej8nQgckg2mLeGg+TXqW3IIPiqBu5uDpgaDFVRVs7RSyzCYlBMFr49hHRFvF hAESA05GbX0jGVSVBc3dgC6K8l4EXrpPWmISwrPHL0SmoU2KeBh7H7YX7ggbJey/dJoN r3eeTYsAlM/UOeT9kGZgSqpQ1aNghjF6L+iXnIqP5SBcAAd/0WQ6nhNaobLeoZphBcAy 8OXq42DNGqep+E0FRYk6pXm3SYJAOriGtUDVy1ki+t5trTNss/1ud0eg3fRBhweo2dUL czMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BHLyyH6vGfsZ/QN9SdywOPLDVma4tVKVqCV+Tv3iIOs=; b=qrLfqqOQ7Mv8ZXsWLHcAaF5gDtuIuKK4UiHrKvtYmg6eXrA6nHDJ/RWB9tPGNkARWc iJ9hqVw+CZ1MyKlJq/ky7BHG2cF1oe9AFjSfubjzO4/0t97FSIRUKl+I1egzXsdK3HkZ qLZrLaLt33l30HzLhHoKmsZT+Lai+pizvRxNRsnjZStgqgQruwFDYqg54gLDYGot5rQr sVqjtCtgChkzQA9jp24OMyZGJlC3qPqK7VK0T49UhQBlZaqDYaBy3gpqHhGainhL8Ban +/P9srsa2wV8+yRtbBnLxoq0AOiasHavpbQ0lXe0Vz5gcCYuwqj3jDmY8Wq+GjOTqSEr mqnA==
X-Gm-Message-State: AOAM531WBZ27zQTytWTr5Oq7NTEX92St6GUJFXew/qE1gEBEYCyup4rL aE1YFwUIPZ0H5yRCPBMlgfmXNUVq+zhtGLDtlj1xLw==
X-Google-Smtp-Source: ABdhPJxykx6Fi4Alb/gG9MjDTrGuuIv865s6IbDXymvRRZVQrB3Zu9PmAB1+JiESBEsGPfLPm0425gx1A8MDfc3D8Q0=
X-Received: by 2002:a5b:152:: with SMTP id c18mr2214569ybp.393.1593605681836; Wed, 01 Jul 2020 05:14:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAG_2Tb88O=CdGfUnf1+yrwQfUdR=pM8rYKB4Z9FW_yfPpL-iTQ@mail.gmail.com> <ca6fe3bc4f529e46dd3d93b46e40550148c11cb9.camel@tudelft.nl> <CAG_2Tb_Lnp3xdQzgi6CR3yxOnkSRk30pGPAATn1g2eo1e5sXHA@mail.gmail.com> <5c12aa32971397ff95dd881853738dd9efdca016.camel@tudelft.nl> <CAG_2Tb_CRrskKSk6NiLpQdy0Kbc51cjQ40=1F57baDsP5R4USw@mail.gmail.com> <c4ccf966b6613280b75afb82f933ecf239904772.camel@tudelft.nl> <393311e1644c4a32b1d80d0af8970630@thalesaleniaspace.com> <MN2PR11MB3936A5B9406E06186C92FC60C1AF0@MN2PR11MB3936.namprd11.prod.outlook.com> <650d6e197303ee7ae290fe9fdd0483b3fdd9590b.camel@tudelft.nl> <CAG_2Tb_Kk5N=70Sa0gWmHCMFw3nBZr4ZYoNMeqmgf6ZaCys=jA@mail.gmail.com> <40f6de6969d6b60e7cfaf5d30fc71dc3e49dc509.camel@tudelft.nl> <CAG_2Tb9jBmDrQV0ka+TUjF6GW0qsyAkbqgQEVTN5+tJoMVNFdg@mail.gmail.com> <e4aecc25dc2765a0d395f427ed58491ee39164f9.camel@tudelft.nl>
In-Reply-To: <e4aecc25dc2765a0d395f427ed58491ee39164f9.camel@tudelft.nl>
From: Shota NAGAYAMA <shota.nagayama@mercari.com>
Date: Wed, 01 Jul 2020 21:14:30 +0900
Message-ID: <CAG_2Tb9np_xnwA7cN62UR-6HZdoZMVUjL1sfybFvX=yM70HtqQ@mail.gmail.com>
To: Wojciech Kozlowski <W.Kozlowski@tudelft.nl>
Cc: "qirg@irtf.org" <qirg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000942a1605a9603cfa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/jJEBOjxrmkYBUHQxoLUFXRtnzK4>
Subject: Re: [Qirg] Pull request for 'new challenges' subsection 'The first quantum networks may not be "routing and forwarding" networks.'
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 12:14:48 -0000
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://qitf.org/ https://r4d.mercari.com 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 > > 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=> > >
- [Qirg] Pull request for 'new challenges' subsecti… Shota NAGAYAMA
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Shota NAGAYAMA
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Shota NAGAYAMA
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… VAN DEN BOSSCHE Mathias
- Re: [Qirg] Pull request for 'new challenges' subs… Scott Fluhrer (sfluhrer)
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Shota NAGAYAMA
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Shota NAGAYAMA
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Shota NAGAYAMA
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Shota NAGAYAMA
- Re: [Qirg] Pull request for 'new challenges' subs… Wojciech Kozlowski
- Re: [Qirg] Pull request for 'new challenges' subs… Shota NAGAYAMA