Re: [Qirg] comments on the architecture principles draft

[Wojciech Kozlowski <[e-mail]>]

I've updated the draft (on GitHub): https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/16a813cbbba453d8bce284c817377d8575b5dcdc

Comments in-line

> -----Original Message-----
> From: Qirg <[e-mail]> On Behalf Of Rodney Van Meter
> Sent: 21 November 2020 06:21
> To: [e-mail]
> Cc: Rodney Van Meter <[e-mail]>
> Subject: [Qirg] comments on the architecture principles draft
> 
> 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!
[WK] Good point. I'm leaving this for the very final edits just before submitting as more references might be added.

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

> 
> 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?
[WK] In general I agree. However, the previous part of that paragraph explained how one needs to be able to transmit qubits to generate entanglement in the first place.

> 
> 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.
[WK] Fixed

> 
> 4.3:
> * "This can be achieved via quantum state
>    teleportation." cite Charlie
[WK] Fixed

> * "quantum data plate"
[WK] Fixed

> 
> 4.4.1:
> * how does container shipping fit into 4.4.1?
[WK] From my brief skim of the paper, is it not just a 3G quantum network?

> 
> 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?
[WK] Added this point, but elsewhere (together with teleportation)

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

> 
> 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.
[WK] Removed this sentence as it was there all alone and not contributing much anyway.

> 
> 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.
[WK] Good point, fixed

> * "empowered by QEC" -- an awkward phrase
[WK] Fixed

> * hmm, I'm not sure the 2G description here is clear enough...
>   (1G ande 3G seem okay)
[WK] Slightly improved. Open to suggestions though as I don't have any better ideas.

> 
> 5.1:
> * "the router looks up its forwarding table" -- an awkward phrase.
>   Consults its forwarding table?
[WK] Fixed

> 
> 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?
[WK] I think this is best left to more concrete documents. Last time this question was raised there was a fear that this will go down a rabbit-hole of trying to define hard real time and soft real time

> 
> 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?
[WK] It does say in the definition that it's a quantum repeater though... I did rephrase it slightly to hopefully be clearer.

> 
> 5.4.3:
> * "important distinctions in how errors will
>    be managed, as described in Section 4.4.3.3, which affects"
>    s/affects/affect/
[WK] Fixed

>    Also, maybe reference Shota's interoperability paper here?
[WK] Actually forgot about this - I'll push it in a separate commit in a moment so remind me if that commit isn't there when you read this.

> 
> 5.5.1:
> * "demonstrated, but these qubits were not yet connected"
>   --> demonstrated for qubits not connected
[WK] Fixed

> * Maybe also worth commenting here again about the importance of
>   planet-wide RTT, compared to intra-laboratory connections?
[WK] Didn't see how to meaningfully add this

>   Also, does this need to be "as of 2020"?
[WK] Fixed

> 
> 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?
[WK] Agreed that it didn't sound very good. After scratching my head how to merge your suggestion into the text I realised it's just better off without this sentence at all.

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

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

> 
> 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"
[WK] Fixed

> * "It should not be
>        constrained due to considerations for early-stage hardware and
>        applications." No clear antecedent for "it".
[WK] Fixed

> 
> 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.
[WK] Upon rereading, I rephrased the paragraph, but it is about performance and fidelity though. Timestamping sounds way more concrete than desirable in this draft.

> * "Second, it should not..." again, no findable antecedent for "it".
[WK] fixed

> 
> 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.
[WK] I actually like ending on this comparison. But you are right it feels like it doesn't have a conclusion. So I slightly rephrased the introduction and title to that last section to make that a conclusion. To me it is a rather creative way of saying "hey, here's what an architecture could look like" which is better than just a bullt point list

> 
> 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.
[WK] As I see it, if there's nothing in the draft to stop them there's no need to explicitly accommodate them. Though, I'm no expert on all-optical though so cannot really say. Containers sound like 3G quantum repeaters. But we should also remember, that this is not a document proposing a concrete architecture so if, down the line, some incompatibility is found, I don't think that would be the end of the world.

Anyway, open to proposals, but I won't be working on this point myself.
> 
> I have not yet tried to compare to the use cases draft.
[WK] I believe they're mostly in-line barring some control plane fixup I pushed in the next commit so they should be aligned now.

> 
> Rodney Van Meter
> [e-mail]
> Professor, Faculty of Environment and Information Studies, Keio University,
> Japan
> 
> _______________________________________________
> Qirg mailing list
> [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
> =t1J1c2DukwzFx0VKZsbsSAQtWA_JaMcLWsXvypBL3vs&s=IdBw7Tsn6yJmlpn
> 3WtQs_7JjLvjV4B2dX2AcgbWzxtw&e=