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