Re: [Qirg] comments on the architecture principles draft

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

<author hat on>
It’s definitely getting closer.  As an author, I’m about ready to call it baked.

One tweak in the references:
I am baffled by the fact that many papers talk about the history of QKD networks and cite the SECOQC net in Vienna, but not the DARPA QKD network in Boston.  It’s not Wojtek’s fault, I’m sure; it seems to be common.  But the BBN-BU-Harvard network was ten nodes (optically switched) and was running five years before the SECOQC one.  It also worked with IPsec, albeit in a rather hackish fashion. It should be cited.

@InProceedings{elliott:qkd-net,
  author = 	 {Chip Elliott and David Pearson and Gregory Troxel},
  title = 	 {Quantum cryptography in practice},
  crossref =	 {sigcomm03},
}


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

> On Mar 30, 2021, at 5:43, Wojciech Kozlowski <[e-mail]> wrote:
> 
> 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 <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/937fac5dbae5626961fead3a97796daab46401b6>
> - https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/908bbb80811e2e188a69bb1832a2d2e44a4c5b23 <https://github.com/Wojtek242/draft-irtf-qirg-principles/commit/908bbb80811e2e188a69bb1832a2d2e44a4c5b23>
> 
> 
>> -----Original Message-----
>> From: Qirg <[e-mail] <mailto:[e-mail]>> On Behalf Of Wojciech Kozlowski
>> Sent: 02 February 2021 17:19
>> To: Rodney Van Meter <rdv=[e-mail] <mailto:rdv=[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Cc: Rodney Van Meter <[e-mail] <mailto:[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- <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] <mailto:[e-mail]>
>> https://urldefense.proofpoint.com/v2/url?u=https- <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=
> 
> _______________________________________________
> Qirg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>