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

[Wojciech Kozlowski <[e-mail]>]

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
[e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of VAN DEN BOSSCHE Mathias
Sent: Monday, April 27, 2020 10:34 AM
To: [e-mail]<mailto:[e-mail]>
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:[e-mail]] De la part de Wojciech Kozlowski
Envoyé : lundi 27 avril 2020 14:20
À : [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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
[e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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
[e-mail]<mailto:[e-mail]>
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=>