[Qirg] comments on the architecture principles draft

[Rodney Van Meter <[e-mail]>]

Wojtek,

Some specific comments, a few requiring work and a number just wordsmithing.

General:
* The set of references seems to be in neither order of appearance nor
  alphabetic order. I'd have to check which is more common in RFCs,
  but it should be one or the other!

1.:
* Not sure it's "longer-baseline" interferometry; instead it's
  "higher-precision, long-baseline" interferometry

3.:
* "it is the transmission of qubits that draws the line between a
   genuine quantum network and a collection of quantum computers
   connected over a classical network." I don't fully agree with
  that.  The simple sharing of an entangled state does not necessarily
  involve the transmission of qubits.
* "A quantum network is defined as a collection of nodes that is able to
   exchange qubits and distribute entangled states amongst
  themselves." and / or?

4.1.4:
* Jiang's paper also needs to be cited where Fowler's is for QEC in
  communication. Jiang's paper predates Fowler, so if you can have
  only one, probably Jiang, but citing both should be okay.

4.3:
* "This can be achieved via quantum state
   teleportation." cite Charlie
* "quantum data plate"

4.4.1:
* how does container shipping fit into 4.4.1?

4.4.2:
* 4.4.2: a good opportunity to emphasize that the classical
  communication is why we can't xmit useful info faster than c?

4.4.3.1:
* "round-trip delays due to classical communication
   ([17])." don't need the ()

4.4.3.2:
* "QEC encodes a single logical qubit using many physical qubits."
  generally, speaking, false.  There are a lot of QEC codes that
  encode multiple qubits in a block, but there are disadvantages to
  this.

4.4.3.3:
* "small, shallow quantum circuits" -- this is the first time we've
  used the term "circuit", and it's undefined.  I'd recommend
  rewording this to not use the term, but if you prefer you could
  define it instead.
* "empowered by QEC" -- an awkward phrase
* hmm, I'm not sure the 2G description here is clear enough...
  (1G ande 3G seem okay)

5.1:
* "the router looks up its forwarding table" -- an awkward phrase.
  Consults its forwarding table?

5.2:
* 5.2: I think we talked once about hard real time classical
  signalling (e.g., physical-layer sync pulses) v. the slightly
  softer real time operations concerning operations such as
  distillation and swapping.  Should this distinction be mentioned
  here?

5.3.2:
* "automated quantum nodes" -- what are these?  e.g., entangled photon
  pair sources that don't need any inbound, classical digital
  messages?  Maybe we should say so.  I don't _think_ a Bell state
  analyzer (BSA) counts here, does it?

5.4.3:
* "important distinctions in how errors will
   be managed, as described in Section 4.4.3.3, which affects"
   s/affects/affect/
   Also, maybe reference Shota's interoperability paper here?

5.5.1:
* "demonstrated, but these qubits were not yet connected"
  --> demonstrated for qubits not connected
* Maybe also worth commenting here again about the importance of
  planet-wide RTT, compared to intra-laboratory connections?
  Also, does this need to be "as of 2020"?

5.5.2:
* "A fast repetition rate for Bell pair generation is
   achievable, but only a small fraction will succeed."
  First, that's only true for some link architectures.  Second, it's a
  little confusing.  How about
  "Repetition rate for entanglement creation attempts is a technology-
  and link-dependent factor; many link architectures are limited to
  link-level round-trip time signalling for each attempt using each
  memory qubit.  Some link architectures allow faster attempts not
  regulated by link RTT.  As of 2020, all technologies have very low
  success probabilities."
  Too wordy?

5.5.3:
* "using a subset of its available qubits" -- delete "its".
  A little later, add a comma after "In particular"

6.:
* "As this is a completely new..." it's a new paragraph, so "this" has
  no antecedent.

6.1:
* "For example, QKD" -- goes on to talk about its relationship to Bell
  pairs, but this obscures the relationship to single-photon QKD.
  Maybe just add "For example, entanglement-based QKD"
* "It should not be
       constrained due to considerations for early-stage hardware and
       applications." No clear antecedent for "it".

6.2:
* "Time is part of the service" -- I was thinking that high-precision
  timestamping is part of the service, especially for sensor uses,
  although authenticated timestamps for certain actions could be part
  of some cryptographic protocols, as well.  But I don't see this
  mentioned here; instead, this section is mostly about trying to be
  timely to improve performance and fidelity.
* "Second, it should not..." again, no findable antecedent for "it".

After Sect. 7, comparison with classical networks, the draft kind of
ends without any sort of conclusion.  Should we have a summing up of
some kind?  Personally, I find it very tempting to list the set of
things that would need to be decided to have a complete architecture,
but a "work item list" doesn't belong in an RFC.

I kept an eye on two of the concerns I keep expressing: does
all-optical fit in, and what about container shipping links?  I still
think it should be tweaked a bit to accommodate them, but I don't
think there are any show stopper reasons to hold up the document if I
don't figure out how add them.

I have not yet tried to compare to the use cases draft.

Rodney Van Meter
[e-mail]
Professor, Faculty of Environment and Information Studies, Keio University, Japan