Re: [Qirg] comments on the architecture principles draft

[Wojciech Kozlowski <[e-mail]>]

I have now also cleaned up and sorted the references:

Latest version: https://github.com/Wojtek242/draft-irtf-qirg-principles/blob/master/draft-irtf-qirg-principles-06.txt

Done across two commits:
- https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/937fac5dbae5626961fead3a97796daab46401b6
- https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/908bbb80811e2e188a69bb1832a2d2e44a4c5b23


> -----Original Message-----
> From: Qirg <[e-mail]> On Behalf Of Wojciech Kozlowski
> Sent: 02 February 2021 17:19
> To: Rodney Van Meter <rdv=[e-mail]>; [e-mail]
> Cc: Rodney Van Meter <[e-mail]>
> Subject: Re: [Qirg] comments on the architecture principles draft
> 
> I've updated the draft (on GitHub):
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-
> 2Dprinciples_commit_16a813cbbba453d8bce284c817377d8575b5dcdc&d=Dw
> ICAg&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-
> TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m
> =38snX0BAIi6-
> VrZrSxYNuEROfyOZsgBmu9RoraJEYGM&s=18X59EkPsW8KKJdkSAcglqsIjI70zq
> -vbJvPEINVRqk&e=
> 
> 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=
> 
> _______________________________________________
> 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
> =38snX0BAIi6-
> VrZrSxYNuEROfyOZsgBmu9RoraJEYGM&s=YKNpjKa5WhihXbiVI1vySY07RhGg
> MD6BCe5RkjKUaTs&e=