Minutes interim-2019-qirg-01: Mon 11:00
minutes-interim-2019-qirg-01-201909301100-00

QIRG online meeting:
2019/9/30

Wocjiech Kozlowski, convener
rdv, scribe

Patrick Gelard
Andrey Hoursanov
Stephen Diadamo
Wojciech Kozlowski
Takaaki Matsuo
Shota Nagayama
Gyananjay Rai
Bruno Rijsman
Piotr Rydlichowski
Sothy Shan
Rana Sircar
Matthew Skrzypczyk
Rodney Van Meter
Chonggang Wang
Raja Yehia

agenda:
* agree on goals of draft
* summarize current state
* next steps

Want to expand ownership of draft
https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/

goal:
* layout vocab
* facilitate cross-communication w/ physicists

(Agreed via silence.)

Discussion of feedback received orally. Some of this is captured at the Github
source for the draft,
https://github.com/Wojtek242/draft-irtf-qirg-principles/blob/master/CONTRIBUTING.md

WK: We need to distinguish different types of roles.
rdv: We used the term “Half Entangled” in some of the state machine designs we
had years ago.

Gyanajay: Easy-to-understand common terms is better than more specialized.

WK: How is entanglement created and moved (via swaps), and consumed? Is
lifetime worth talking about?

rdv: We got asked for an example for our connection draft, could be useful here
to follow an entangled pair over the course of its life.

WK: We get the question of what the packet format looks like for qubits. We’re
used to packet formats, but this is really at the physical plane. What is the
equivalent of a packet?

rdv: There are classical timing pulses and heralds, so there is something of a
frame format.

bruno: Something like GPLS, where control messages are completely separate.
There are hard-real time and soft-real time, same thing in quantum.

WK: Okay, two points: Qubit frames are divided into control and data, and into
hard and soft real time. Is that right? <assent from bruno> More analogies to
classical comms in the I-D would be good.

Chonggang Wang
Can we also add clarification on: whether and how classic app data will be
transmitted over quantum channel (i.e. using qubits) and/or over both
quantum/classical channel?

Patrick Gélard
The goal of a classical network is to answer the requirement of applications,
thus what are the requirement of quantum applications (QKD, Distributed quantum
computing, quantum sensing, ...) ? The commun need of quantum application is
the request of resgister of entangled qubits ?

Rana Sircar
In Quantum Networking, apart from transferring quantum information, there is a
hybrid mix of Classical channels and Quantum information sharing. It may be
useful to clearly separate the two in terms of Space &amp; Time (timing signals)

WK: Worth emphasizing separation of data and control planes. Worth emphasizing
that the classical network is still necessary; some people don’t realize that. 
Will be valuable to write down the relationship between the two.

Andrey: I would propose to cover also the naming of quantum nodes and key
aspects related to it, such as sending a message to a receiver of choice under
assumption of a mesh-network (not a p2p network)

rdv: Don’t throw the kitchen sink in, too long and not finished are not good.

Gyananjay
It's application application like world wide web and future application of
quantum will probably derive from classical application

WK: Had the question of whether we should cover routing, traffic engineering,
etc. in this draft, and I think that should be elsewhere.  They are too
complicated to cover here.

Andrey: I would expect separate, detailed doc, but having some hints in this
would be good.

WK: What’s the next step for getting people involved?  Is it a valid working
model to divide into smaller groups to tackle specific things?

bruno: yes, it is, and I’m willing to work on sections.  Should keep it all in
public.

WK: Could go section-by-section in these calls.  Or we can pick a particular
topic for next call.

rdv: Keep as much as possible on the mailing list, for archival purposes.

WK: Okay, let’s work through the list and use these calls to consolidate.

Stephen
Could use "Projects" in Github to generate tasks / tickets and people can know
what is left to be done or who is working on what. Maybe there is also a hook
such that emails are sent to the mailing list when tasks are updated

Andrey:

WK: I think we’re in general agreement.  Don’t want it to be a kitchen sink,
want to leave flexibility.

Bruno Rijsman
There is actually a working group (or team) in the IETF that deals with github
intergation. They may be able to advise

WK: Any general remarks?

Chonggang: Wondering, for this draft, can we cover use cases?  Or a separate
draft?

WK: Good point.

rdv: Great idea, defer to later document.

Gyananjay
Can draft be shared on this app screen and draft will have a larger annotations
instantly

WK: Anything on the draft?

Shota Nagayama: Let’s try to keep this to things that won’t become outdated.

WK: Good point.  Anything else?

rdv: Singapore -- can we do Tuesday or Wednesday?  How long a meeting do we
want?

WK: That should work.  One hour?  Maybe two.

chonggang: What happened to WQRN?

rdv: Postponed to April 2020.

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
rdv@sfc.wide.ad.jp