Subject: Re: [Qirg] a #QuantumInternet Architecture position paper

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Jul 2021 14:30:56 +0200

Le 09/05/2021 à 14:00, Rodney Van Meter a écrit :
> (Happy Mother’s Day to the mothers of all QIRGers, and to all
> QIRGers who are mothers!  Maybe I should wait until Monday to send
> this out, more likely to hit some eyeballs then…but what the heck, I
> just finished it, so here it is.)
> 
> Okay, here's something I've been intending to write down for some 
> years...a brief outline of my ideas for a Quantum Internet 
> architecture,

With respect to architecture, I would like to point out that there is an
RFC titled "IP Version 6 Addressing Architecture".  This is the
addressing architecture of the current and future Internet where IPv4 is
phased-out.

In this sense, I wonder whether we understand the same thing
about Internet, as people who say Quantum Internet.

Is the Quantum Internet having an addressing architecture?  Which one?

Is the Quantum Internet something to happen in the foreseeable future,
or is it something to stay on paper for many decades to come?

Is the Quantum Internet something that will replace Internet?

[...]
> First off, of course, it's important to recognize that there will be
>  an *internetwork*, a network of networks.

I think it is already the case: The Internet is already an internetwork,
a network of networks.  It became an internetwork (network of networks)
in around 1990s, or so.  For example, it joined AOL with bitnet.

Is the Quantum Internet one of these networks that is part of the
network of networks?  Or is the Quantum Internet another Internet than
the Internet as we know it?

If the  Quantum Internet is one of the networks in the network of
networks, then we should call it 'a quantum network', and not 'Quantum
Internet'.

Alex

> http://dx.doi.org/10.1109/MNET.2012.6246754 or for an unfancy copy 
> https://aqua.sfc.wide.ad.jp/publications/van-meter-networking-review-preprint.pdf
>
>
> 
There will be more than one network architecture, no doubt; but to
> build a true Quantum Internet there will ultimately be only a single 
> internetwork architecture.
> 
> There are a number of key design decisions that must be made:
> 
> 1. the nature of the fundamental service: Bell pairs?  measured-out 
> classical bits?  qubit teleportation? multi-party graph states? 2. 
> how networks will come together to make an internetwork -- what is 
> the nature of the interaction?  (affected strongly by connections, 
> below) 3. the multiplexing discipline for resources (n.b.: not for 
> access to wavelengths; this is a higher-level, end-to-end concept): 
> circuit switching?  time division muxing?  statistical muxing, as in 
> the Internet?  buffer space muxing? 4. nature of connections: 
> entanglement swapping and purification (1G), or QEC (2G, 3G)? 
> (affects internetworking) 5. both of the above points affect whether 
> a connection requires state at each repeater/router 6. how 
> connections are established 7. how a path or route is chosen through 
> the network 8. all of the above affect choice of whether to try to
> do multipath for a single connection 9. security for the network
> 
> There are more, but those are some of the critical ones.  For more on
> these kinds of issues, (as well as a super-brief intro to quantum 
> networking for those without the background), see our Internet Draft,
> hopefully to become an RFC soon: 
> https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
> 
> On individual links, using memories at each end and photons to 
> entangle, it seems pretty obvious to me that the fundamental 
> primitive is the physical Bell pair (which we also call a "base 
> entangled state").  Everything else builds on top of this.
> 
> However, that's made more complicated by the possibility of 
> all-optical repeaters, an area we are currently researching. (See 
> https://quantum-journal.org/papers/q-2021-02-15-397/ and work 
> backwards from there.)  An especially tricky issue we are actively 
> working on right now is how to terminate such connections and how to
>  make them interoperate with other types of 
> connections/nodes/networks.
> 
> I believe that end-to-end multiparty states (GHZ, W, graph states) 
> are likely to be *extremely* valuable, but I think it's an open 
> question whether they are part of the fundamental service or should 
> be created and managed entirely by applications running at end
> nodes. (In particular, I'm not at all sure what the APIs at the
> responders are like to make something like this happen.  What is
> listen() like in this case?)  At any rate, I think QRNA and our
> RuleSet-based approach can handle either connection-level or
> multiparty graph states as we develop it over time.
> 
> Same for multipath connections.  It's a pretty obvious idea, and 
> sorry but I can't remember who first proposed them in print (Perdrix?
> Benjamin?).  My own opinion is that the benefits of multipath are
> likely to be minor, as a. often, the first hop will be the bottleneck
> anyway, b. asymmetry in the paths in the real world means that
> benefits will be minimal, and c. I assume there will be a lot of
> competition for resources on the net, and so the occasions when you
> can actually acquire the resources to do multipath effectively will
> be few.  Oh, and d. the software complexity is high. So, I think it's
> doable in QRNA+RuleSet, but it's far down my list of things to work
> on.
> 
> So, let's stick with Bell pairs for the moment as both the 
> fundamental link service and the *primary* end-to-end service.  If
> we build well, it will be possible to extend later.
> 
> That disposes of...let's see...point 1 in the list above.  On to 
> point 2...
> 
> I think that the internetwork architecture should be a fully 
> recursive system; we have named this the Quantum Recursive Network 
> Architecture (QRNA), after Joe Touch's RNA.  (Joe collaborated with 
> us on this.) Today, an idealization of the Internet is that it's a 
> two-level system, with BGP as the external gateway protocol and your 
> choice of internal gateway protocol (OSPF and IS-IS being two of the 
> most prominent).  The reality, with tunneling having long been 
> common, with switched Ethernets requiring a spanning tree protocol 
> underneath even though they are nominally "link layer", and lately 
> with the huge emphasis on virtualizing networks and services (e.g., 
> network slices), is that the Internet has long been a multi-tier 
> system with ad hoc interactions at each level.  Designing from 
> scratch, if we do a good job, this means that they are all unified 
> into a single system.
> 
> Of course, if you want, at *your* network boundary, you can run 
> anything you want inside: you just have to match the semantics of the
> connection's requests where they cross your borders.
> 
> Today, in the Internet, when a packet arrives at your border, the 
> implied semantics are for you to forward it across (for transit) or 
> to the matching end node (for termination).  For the Quantum 
> Internet, connections will have to be established in advance, with a 
> certain amount of state.  What I envision is a connection request 
> protocol where, in a multi-tier system, connections are for some 
> boundary-to-boundary (for transit) or boundary-to-end node (for 
> request termination) operations.  Presumably, for transit, what 
> connection requests see is each entire network as a node in the graph
> at this level (i.e., top-level eBGP graph).  Requests, then, are of
> the nature, "Please give me Bell pairs of fidelity F=x between here
> and address 1.2.3.4," where the requester knows that at this level of
> the graph that 1.2.3.4 is the next hop toward the destination.
> 
> Therefore, it's the responsibility of border routers to *rewrite* the
> request to internal actions that will fulfill this goal.  Again, 
> internally, it can be what you like -- but if you adopt QRNA 
> internally, it can be creating a new set of QRNA requests that reach
>  from here to the gateway on the other side of the network.
> 
> There's lots more to say on QRNA; see https://arxiv.org/abs/1105.1238
> or discussion in my book.  Beyond this vision, there is still a lot
> of work to do!
> 
> Two down, seven points to go...
> 
> Multiplexing: Lucho Aparicio's master's thesis addressed circuit 
> switching, time-division multiplexing, statistical multiplexing (like
> Internet best-effort forwarding), and buffer space multiplexing,
> where the qubits at each router node are assigned to specific
> connections but multiple connections can pass through, getting
> assigned a share of the qubits.  We studied aggregate throughput and
> fairness, and found, somewhat to our surprise, that stat mux works
> pretty well.  Aggregate throughput is actually *above* circuit
> switching, because it does a pretty good job of allowing multiple
> areas of the network to be working productively at the same time.
> What's more, as far as I am aware, this was the world's first 
> simulation of a quantum repeater *network*, as opposed to just a 
> chain of repeaters. 
> https://spie.org/Publications/Proceedings/Paper/10.1117/12.893272 or
>  https://aqua.sfc.wide.ad.jp/publications/Aparicio-master-thesis.pdf
> 
> *However*, that said, those early sims were for small-scale networks.
> I think this needs to be studied in *much* more detail to assess
> robustness in the face of complex, varying traffic patterns. In
> particular, I really fear that something akin to congestion collapse
> is possible, and is to be avoided.  We already know that connection
> state will have to be maintained at repeaters & routers; quite
> probably there will have to be some active management of resources
> here, as well.
> 
> This has to coordinate with routing, below.  Naturally, we want to 
> avoid fully blocking muxing protocol if possible.
> 
> Oh, and one more point on this: given that early networks will be low
> performance, how do we prioritize connections?  Do we create a static
> priority scheme, based on...how much money people have? Auction off
> time slots?  Use a fixed accounting/charging scheme and lower nodes'
> priority the more they use, like an OS multi-level feedback queue?
> (Can you tell that I lectured on MLFQ last week?)
> 
> Point four: an internetwork architecture needs to accommodate 1G, 2G
>  and 3G networks. https://www.nature.com/articles/srep20463 Although 
> these designations address advances in dealing with types of errors 
> as our capabilities improve, they do not necessarily correspond to 
> time.  Nevertheless, 1G, using acknowledged link layer entanglement 
> creation to handle photon loss and purification (quantum error 
> detection) to handle noise and decoherence, will definitely be the 
> first deployed.  (Indeed, Delft is getting there, one step at a time.
> https://arxiv.org/abs/2102.04471 or 
> https://science.sciencemag.org/content/372/6539/259)
> 
> So, we need an internetwork capable of interconnecting different 
> connection architectures.  We have addressed how routers at the 
> boundary can make entangled states that cross the borders. 
> https://arxiv.org/abs/1508.04599
> 
> Even for first-generation networks, though, you have to have a 
> mechanism for saying, "Okay, Bob, once you get a Bell pair with Alice
> and a Bell pair with Charlie, execute entanglement swapping, then
> send the Pauli frame correction to Charlie and a 
> notice-of-entanglement-transfer to Alice," and "If you have two Bell
>  pairs with Alice, both with fidelity less than 0.9, then purify."
> 
> Our approach to this is to define Rules that have a condition clause
>  and an action clause, very analogous to classical software defined 
> networking (SDN).  For a connection, each node is given a RuleSet 
> that should comprehensively define what to do as local events occur 
> (entanglement success, timeout, etc.) and as messages arrive.
> 
> This RuleSet-based operation is the heart of our work these days, and
> allows for explicit reasoning about how to achieve the maximum 
> asynchrony in the network (rather than waiting for explicit 
> instructions at every operation or attempts to make everything 
> proceed in lockstep).  The best reference to date on RuleSets is 
> Takaaki's master's thesis: https://arxiv.org/abs/1908.10758 or a PRA 
> paper on the topic: https://arxiv.org/abs/1904.08605
> 
> I believe this RuleSet-based approach meshes will with the vision of
>  QRNA.  Indeed, when combined with a rewrite engine at network 
> borders, as described above, it should serve well as an
> instantiation of QRNA.
> 
> All right, that actually handles point five, as well; RuleSets and 
> any qubits at the nodes that are currently assigned to a particular 
> connection, well, that's connection state at each repeater/router. 
> The scalability of this needs to be assessed, but I don't see a way 
> around it right now.
> 
> (n.b.: as a network architecture aside, for the foreseeable future, 
> there won't be any high-performance links; they'll all be low 
> performance.  Therefore, there won't really be backbone, long-haul, 
> high-bandwidth links, either; the network topology is going to have 
> to be richer.  So there might not be huge numbers of connections 
> passing through individual routers, anyway.)
> 
> So, point six, how do we set up connections...our approach is to use 
> a two-pass system.  On the outbound leg (starting, appropriate 
> enough, at the Initiator), you collect information about links and 
> available resources.  When the connection request reaches the 
> Responder, it takes that information and builds RuleSets for
> everyone along the path.  Those RuleSets are then distributed in a
> return pass, then the operation for the connection begins.
> 
> This has a few interesting points: a. it limits the amount of 
> information each node has to have on hand about the entire network, 
> b. it allows Responders to innovate (within the bounds of the RuleSet
> architecture), and c. it will work well with the border rewrites
> necessary for QRNA.
> 
> I have presented this approach in any number of talks (see, oh, for 
> example, https://indico.hep.caltech.edu/event/837/?print=1 -- there 
> is a video file there as well as PDF of my slides), but so far it's 
> only written down in an expired Internet Draft 
> (https://tools.ietf.org/html/draft-van-meter-qirg-quantum-connection-setup-01)
>
>
> 
that I hope to revive, and in some of the documentation on our Quantum
> Internet Simulation Package (QuISP). 
> https://github.com/sfc-aqua/quisp/tree/master/doc
> 
> Which brings us to point seven...how to pick a route.  We 
> investigated quite some time ago in 
> https://link.springer.com/article/10.1007%2Fs13119-013-0026-2 or 
> https://arxiv.org/abs/1206.5655 a variant of Dijkstra's algorithm, 
> which we inventively call qDijkstra.  We define link cost as "seconds
> per Bell pair of some index fidelity."  e.g., seconds to make a Bell
> pair of e.g. F=0.98.  Including fidelity in the metric makes a lot of
> sense; a high data rate but with poor fidelity may be less useful
> than one with a lower rate but higher fidelity.  Thus, if your base
> fidelity is poor, you have to take into account purification, which
> automatically reduces throughput by half and more likely by 3/4 or
> more.  We compared (via simulation) the throughput of various paths
> with heterogeneous links, and found a good correlation with our
> calculated path cost.  Fidelity is actually too simple a metric, so
> the correlation isn't perfect, but we think it's good enough.
> 
> The biggest open question here -- and one of the things we are 
> investigating -- is how to combine path selection with 
> multiplexing/resource reservation.
> 
> Whew...let's see, we covered multipath above when talking about 
> connections, so we're set there.
> 
> Bringing us to point nine, network security: in fact, we are the only
> group in the world looking at security of network operations for
> quantum repeaters. https://arxiv.org/abs/2005.04617 and 
> https://arxiv.org/abs/1701.04587 But this doesn't mean *at all* that 
> we have a complete plan for secure operation of the Quantum
> Internet. Fairly obviously, all of the protocols we've talked about
> above need authentication and tamper resistance; whether privacy is
> also required or useful is an open question.  Given the previous
> Internet (and, to a lesser extent, telephone network) experiences
> with lack of security in routing, accounting, DoS, etc., and the
> likely high cost of quantum connections, it seems pretty imperative
> to have a solid framework in place very early in the Quantum
> Internet, basically well before we have a truly operational network.
> And, this ties into the muxing decisions as outlined above -- you
> can't have accounting and authorization without authentication.
> 
> *Whew*, that's a lot of decisions, and lays out a lot of work to do.
>  And we haven't even addressed some important topics, like naming.
> 
> If you can't carry all that in your head, just remember the three 
> critical points: a recursive architecture for internetworking, 
> RuleSet-based connection operation, and a two-pass connection setup 
> routine (outbound info collection, inbound RuleSet distribution).
> 
> And although there is solid work on routing and multiplexing, 
> designing a system that will be robust at scale and that will serve 
> us well for decades is a big, open issue.
> 
> Rodney Van Meter [email-masked] Professor, Faculty of
> Environment and Information Studies, Keio University, Japan
> 
> _______________________________________________ Qirg mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/qirg
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 2 Jul 2021 09:42:58 -0700

Hi, Alexandre,

> On Jul 2, 2021, at 5:30 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
>> Okay, here's something I've been intending to write down for some years...a brief outline of my ideas for a Quantum Internet architecture,
> 

It’s probably useful to note that a quantum Internet needs a classical Internet to work, so I don’t see it as having its own addressing.

> or is it something to stay on paper for many decades to come?

It’s also clear there are a lot of component technologies that need to evolve, so decades AFAICT…

> Is the Quantum Internet something that will replace Internet?

As per above, this cannot occur. 

> in around 1990s, or so.  For example, it joined AOL with bitnet.

That happened two decades earlier, when IP packets traversed different link layers. Other networks did not have that capability.

> the Internet as we know it?

AFIACT, the quantum Internet, like the Internet, unifies heterogeneous link technologies. So it’s not just a quantum net, it should be (if done right) the layer through which all quantum links can interoperate.

> Internet’.

Agreed! 

So yes, much of what has been written to date in this RG is more about just quantum nets than a quantum Internet. It would be useful to differentiate the two better moving forward.

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Jul 2021 17:07:13 +0200

Hi, Joseph,

Le 02/07/2021 à 18:42, Joseph Touch a écrit :
[...]

> It’s probably useful to note that a quantum Internet needs a classical 
> Internet to work, so I don’t see it as having its own addressing.

I would agree that a quantum Internet needs a classical Internet to 
work, but if so, then there are two potential ways to achieve it:

- the network of quantum computers is overlayed over the classical 
Internet, with IP encapsulation.  In this case, each quantum computer 
would  still need to use IP addresses, because normal IP encapsulation 
is IP-in-IP.

- the quantum computers are extensions on serial lines of the classical 
computers.  There are no addresses on the serial lines (point-to-point, 
SLIP or PPP protocol).  So the quantum Internet does not have its own 
addressing.  Is this the quantum Internet?

But otherwise, when you said that a quantum Internet does not have its 
own addressing... did you mean that it doesnt have its own _different_ 
addressing, but the quantum Internet still has IP addressing?

Because it is impossible to have a network of any kind that does not 
have a notion of addressing.  The postal network, the IEEE MAC-layer 
network, the satellite network - each have a notion of addressing.

A network needs to distinguish among destinations, otherwise it's a 
multicast with a universal scope where all that one says is sent to 
everyone else.

I know that qubits are both 0 and 1 at the same time but at some point 
they do reveal what they really are...

In a same way the destination in a quantum network would still reveal 
its identity at some point, maybe with a high level of confidence.  Is 
that identity an IP address? Or maybe the confidence level 
(probability?) would we encoded in the rightmost bits of the IP address? 
  Or maybe the address is entirely made of qubits not of bits?

> evolve, so decades AFAICT…

In a sense yes, but projects of a few years time span are about to start 
these months, and to build the quantum Internet.  Provided we understand 
commonly what is a quantum Internet.

> As per above, this cannot occur.

So, why should we  build a quantum Internet?

> That happened two decades earlier, when IP packets traversed different 
> link layers. Other networks did not have that capability.
> 
> AFIACT, the quantum Internet, like the Internet, unifies heterogeneous 
> link technologies.

Why should one unify heterogeneous link technologies if they are already 
unified by the current Internet?

Alex

---

From: Joseph Touch <[email-masked]>
Date: Mon, 5 Jul 2021 09:49:45 -0700

Hi, Alexandre,

> On Jul 5, 2021, at 8:07 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi, Joseph,
> 
> I would agree that a quantum Internet needs a classical Internet to work, but if so, then there are two potential ways to achieve it:
> 
> - the network of quantum computers is overlayed over the classical Internet, with IP encapsulation. In this case, each quantum computer would  still need to use IP addresses, because normal IP encapsulation is IP-in-IP.

No encapsulation is needed. The classical net is used as the classical net.

> - the quantum computers are extensions on serial lines of the classical computers.  There are no addresses on the serial lines (point-to-point, SLIP or PPP protocol).  So the quantum Internet does not have its own addressing.  Is this the quantum Internet?

Quantum computers and other components of a quantum net need to communicate classically. You can either invent your own solution to that or use IP. IP allows you to abstract away the link technology/

> But otherwise, when you said that a quantum Internet does not have its own addressing... did you mean that it doesnt have its own _different_ addressing, but the quantum Internet still has IP addressing?

There are two parallel networks: a quantum net of quantum-capable links and nodes, and some way to control those nodes via classical comms. You can invent your own way to to the later or just use IP; I don’t see a good reason not to use IP.

> Because it is impossible to have a network of any kind that does not have a notion of addressing.  The postal network, the IEEE MAC-layer network, the satellite network - each have a notion of addressing.
> 
> A network needs to distinguish among destinations, otherwise it's a multicast with a universal scope where all that one says is sent to everyone else.

Strictly speaking, addressing is needed whenever a single comm channel has either more than one sender (fan-in, requiring a source address) or more than one receiver (fan out, requiring a destination address). Those addresses can be explicit, as is typical in packet nets, or implicit, e.g., using different media, codes, or time slots.

> I know that qubits are both 0 and 1 at the same time but at some point they do reveal what they really are...

And in a quantum net, yes, you need to know where they come from and where they go (if superposition), or what ends share state (for entanglement).

> In a same way the destination in a quantum network would still reveal its identity at some point, maybe with a high level of confidence.  Is that identity an IP address? Or maybe the confidence level (probability?) would we encoded in the rightmost bits of the IP address?  Or maybe the address is entirely made of qubits not of bits?

If you try to think about the quantum Internet - or a quantum network - as a quantum equivalent of the Internet or other network, you can easily end up with incorrect analogies. IMO, it helps to start with the basics:

A classical network creates and maintains shared state between two or more endpoints. 

A quantum network creates and maintains entanglement or teleports superposition between two or more endpoints.

A classical network can have in-band addressing but (IMO) a quantum network cannot (because it would not make sense to send messages “to an entangled address” or "to a superposition of addresses”. So when we talk about the rest of the net, i.e., addressing, control, etc., we need to explain that (IMO) we need *classical* addressing and control to manage quantum state.

> In a sense yes, but projects of a few years time span are about to start these months, and to build the quantum Internet.  Provided we understand commonly what is a quantum Internet.

If you don’t know what you’re building, I don’t see how you can know how long it will take. ;-)

> So, why should we  build a quantum Internet?

For the same reason that the Internet did not replace package delivery.

Just because a quantum Internet cannot exist without a classical net (preferably, IMO, an Internet), doesn’t mean it isn’t useful. A quantum Internet would be a way to interconnect heterogeneous quantum networks with a common interchange layer, allowing different quantum technologies to be used in different places but with one overall effect. The quantum Internet would enable combining smaller quantum computers into a bigger, virtual quantum computer that can solve bigger problems - in ways classical interconnects cannot (see Rod’s thesis), as well as all the other uses in the use case document. Just having a classical Internet doesn’t achieve that.

But again, the Internet did not put UPS or FedEx out of business, nor would the quantum Internet replace the need for an Internet.

>> AFIACT, the quantum Internet, like the Internet, unifies heterogeneous link technologies.
> 
> Why should one unify heterogeneous link technologies if they are already unified by the current Internet?

The Internet unifies heterogenous classical link technologies for sharing state, but cannot create entanglement or distribute superposition. 

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jul 2021 16:19:39 +0200

[...]

> There are more, but those are some of the critical ones.  For more
> on these kinds of issues, (as well as a super-brief intro to quantum 
> networking for those without the background), see our Internet
> Draft, hopefully to become an RFC soon: 

Ok.

[...]
> fundamental link service and the *primary* end-to-end service.

I think the Internet Draft above might benefit from citing the
end-to-end arguments in system design paper ("endtoend.pdf")

I suppose there would be a new layer in the stack.  That layer might be
called a 'quantum layer'.  It might be situated in the PHY layer, which
means at the very bottom of the stack.

However, the endtoend.pdf paper says that whenever we want to add a new
functionality we rather do it at higher layers.

In that sense, it might be that it is not very easy to consider 'Bell
pairs', and a primary end-to-end service.

Or maybe we dont understand the same thing by 'end-to-end'.

Maybe 'Bell pairs' consider the 'end-to-end' to be rather another
concept than the one in the paper endtoend.pdf.

For example, the Internet Draft qirg-principles says:
> Quantum networks combine multiple elementary link Bell pairs together
> to create one an end-to-end Bell pair, whereas classical networks
> deliver messages from one end to the other end hop by hop.

This shows a potential confusion.  It is in a confusion in explaining 
how 'classical' networks in the Internet work.  Because it does not say 
from at which layer are these 'hop by hop' transmissions looked at.

All the statements that use qualifiers such as 'hop-by-hop' or 
'end-to-end' must say at which layer is one situated when making the 
statement.  OTherwise there is confusion.

If we look at it from the TCP protocol at the transport layer, the 
messages are not transmitted hop-by-hop but they are transmitted end-to-end.

If rather we consider the MAC protocol at the data link layer, which 
sits below TCP but above PHY, the MAC messages are transmitted 
hop-by-hop.  In this, a 'hop' is an IP 'hop'.

So, at which layer sit the Bell pairs?  If the Bell pairs are at PHY 
layer then they are transmitted not even hop by hop (let alone not being 
transmitted end-to-end).

If so, then they - the Bell pairs - are not 'end-to-end' but something else.

If the Bell pairs are 'end-to-end' then they might be at the transport 
layer or higher and not at the PHY layer.

Alex

   If we build well,
> it will be possible to extend later.
> 
> anything you want inside: you just have to match the semantics of
> the connection's requests where they cross your borders.
> 
> connection requests see is each entire network as a node in the
> graph at this level (i.e., top-level eBGP graph).  Requests, then,
> are of the nature, "Please give me Bell pairs of fidelity F=x between
> here and address 1.2.3.4," where the requester knows that at this
> level of the graph that 1.2.3.4 is the next hop toward the
> destination.
> 
> Therefore, it's the responsibility of border routers to *rewrite*
> the request to internal actions that will fulfill this goal.  Again, 
> There's lots more to say on QRNA; see
> https://arxiv.org/abs/1105.1238 or discussion in my book.  Beyond
> this vision, there is still a lot of work to do!
> 
> switching, time-division multiplexing, statistical multiplexing
> (like Internet best-effort forwarding), and buffer space
> multiplexing, where the qubits at each router node are assigned to
> specific connections but multiple connections can pass through,
> getting assigned a share of the qubits.  We studied aggregate
> throughput and fairness, and found, somewhat to our surprise, that
> stat mux works pretty well.  Aggregate throughput is actually *above*
> circuit switching, because it does a pretty good job of allowing
> multiple areas of the network to be working productively at the same
> time.  What's more, as far as I am aware, this was the world's first
> *However*, that said, those early sims were for small-scale
> networks. I think this needs to be studied in *much* more detail to
> assess robustness in the face of complex, varying traffic patterns.
> In particular, I really fear that something akin to congestion
> collapse is possible, and is to be avoided.  We already know that
> connection state will have to be maintained at repeaters & routers;
> quite probably there will have to be some active management of
> resources here, as well.
> 
> Oh, and one more point on this: given that early networks will be
> low performance, how do we prioritize connections?  Do we create a
> static priority scheme, based on...how much money people have?
> Auction off time slots?  Use a fixed accounting/charging scheme and
> lower nodes' priority the more they use, like an OS multi-level
> feedback queue?  (Can you tell that I lectured on MLFQ last week?)
> 
> first deployed.  (Indeed, Delft is getting there, one step at a
> time. https://arxiv.org/abs/2102.04471 or
> mechanism for saying, "Okay, Bob, once you get a Bell pair with
> Alice and a Bell pair with Charlie, execute entanglement swapping,
> then send the Pauli frame correction to Charlie and a 
> This RuleSet-based operation is the heart of our work these days,
> and allows for explicit reasoning about how to achieve the maximum 
> borders, as described above, it should serve well as an instantiation
> of QRNA.
> 
> Responder, it takes that information and builds RuleSets for everyone
> along the path.  Those RuleSets are then distributed in a return
> pass, then the operation for the connection begins.
> 
> b. it allows Responders to innovate (within the bounds of the
> RuleSet architecture), and c. it will work well with the border
> rewrites necessary for QRNA.
> 
> which we inventively call qDijkstra.  We define link cost as
> "seconds per Bell pair of some index fidelity."  e.g., seconds to
> make a Bell pair of e.g. F=0.98.  Including fidelity in the metric
> makes a lot of sense; a high data rate but with poor fidelity may be
> less useful than one with a lower rate but higher fidelity.  Thus, if
> your base fidelity is poor, you have to take into account
> purification, which automatically reduces throughput by half and more
> likely by 3/4 or more.  We compared (via simulation) the throughput
> of various paths with heterogeneous links, and found a good
> correlation with our calculated path cost.  Fidelity is actually too
> simple a metric, so the correlation isn't perfect, but we think it's
> good enough.
> 
> Bringing us to point nine, network security: in fact, we are the
> only group in the world looking at security of network operations
> for quantum repeaters. https://arxiv.org/abs/2005.04617 and 
> we have a complete plan for secure operation of the Quantum Internet.
> Fairly obviously, all of the protocols we've talked about above need
> authentication and tamper resistance; whether privacy is also
> required or useful is an open question.  Given the previous Internet
> (and, to a lesser extent, telephone network) experiences with lack of
> security in routing, accounting, DoS, etc., and the likely high cost
> of quantum connections, it seems pretty imperative to have a solid
> framework in place very early in the Quantum Internet, basically well
> before we have a truly operational network.  And, this ties into the
> muxing decisions as outlined above -- you can't have accounting and 
> authorization without authentication.
> 
> Rodney Van Meter [email-masked] Professor, Faculty of Environment
> and Information Studies, Keio University, Japan
>

---

From: Joseph Touch <[email-masked]>
Date: Tue, 6 Jul 2021 09:05:28 -0700

Hi, Alexandre,

> On Jul 6, 2021, at 7:19 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> [...]
> 
>> on these kinds of issues, (as well as a super-brief intro to quantum networking for those without the background), see our Internet
>> Draft, hopefully to become an RFC soon: https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
> 
> Ok.
> 
> [...]

Here’s a more complete citation:

J. H. Saltzer, D. P. Reed, and D. D. Clark. 1984. End-to-end arguments in system design. ACM Trans. Comput. Syst. 2, 4 (Nov. 1984), 277–288. DOI:https://doi.org/10.1145/357401.357402 <https://doi.org/10.1145/357401.357402>
> means at the very bottom of the stack.

Layering is often ill-defined in general - the OSI 7-layer model is a discussion artifact, not really blueprints. In this case, it’s not at all clear you can do what you’re implying.

Versions of a quantum network “stack” do exist (Rod and I kicked one around at one point), but in that stack, the classical network is part of the control plane, not the stack. So no, quantum nets are not just classical nets with quantum PHY layers.

> functionality we rather do it at higher layers.

I disagree. Understanding of the paper has evolved over time significantly. It was originally an argument against telephone-style networks that build new features into the core in favor of the Internet style that builds new features at the edge, But that implication is vague at best; the only thing it actually claims is that:

	- *some* end-to-end services cannot be created *solely* by composing hop-by-hop services

It never says not to build services into hops; in fact, it explicitly notes that this is essential for efficiency. It just says that *some* services, notably reliability, cannot be implied as end-to-end when verified only hop-by-hop.

> pairs', and a primary end-to-end service.

We have Bell pairs as both a hop-by-hop service and - via teleportation - an end-to-end service. So we’re consistent. We don’t build the end to end simply from the hop by hop - the teleportation step itself is exactly the part that requires end-to-end coordination.

> Or maybe we dont understand the same thing by 'end-to-end'.

I think we’re actually fine, as per above.

> concept than the one in the paper endtoend.pdf.

The ‘ends’ of the paper above have always been relative,. Put differently, as we all know:
	
	hardware = that which can be kicked
	software = that which cannot be kicked

In the E2E argument:

	end = that which *I* can kick
	middle = that which *I* cannot kick

> This shows a potential confusion.  It is in a confusion in explaining how 'classical' networks in the Internet work.  Because it does not say from at which layer are these 'hop by hop' transmissions looked at.

Agreed, but I think we basically assume familiarity with classical networking (given this is the IRTF). It might be more precise to say:

	…whereas classical networks combine multiple classical hops into an end-to-end transfer.

(In neither case do we say “how” in this paragraph).

> All the statements that use qualifiers such as 'hop-by-hop' or 'end-to-end' must say at which layer is one situated when making the statement.  OTherwise there is confusion.

Strictly, it’s the ends and hops that need to be noted, but this would occur in a more detailed discussion of the E2E argument as it applies to quantum nets. I don’t think any of our docs aspire to address that in detail.

> If we look at it from the TCP protocol at the transport layer, the messages are not transmitted hop-by-hop but they are transmitted end-to-end.

The TCP ends confirm end-to-end transfer, yes, but they’re always transmitted hop-by-hop. End-to-end transmission is inferred by the ends.

> If rather we consider the MAC protocol at the data link layer, which sits below TCP but above PHY, the MAC messages are transmitted hop-by-hop.  In this, a 'hop' is an IP 'hop'.

IP is a hop. Ethernet logical link is a hop. Ethernet PHY is a hop. They’re different hops.

And if the IP goes over a tunnel, that’s another hop.

> So, at which layer sit the Bell pairs?  If the Bell pairs are at PHY layer then they are transmitted not even hop by hop (let alone not being transmitted end-to-end).

Bell pairs in a quantum network equate (IMO) to information (bits) in a classical net. They’re the end product of the entire system’s function. If they’re at any layer (again, OSI isn’t a blueprint for all nets), they’re at the application layer.

Information is represented in a classical network only at the PHY layer; the same is true for Bell pairs in a quantum layer At all other layers, they’re logical constructs.

> If the Bell pairs are 'end-to-end' then they might be at the transport layer or higher and not at the PHY layer.

I don’t think either of these claims follows from your assumptions above.

I hope my explanation as to why helps…

Joe

>> Of course, if you want, at *your* network boundary, you can run anything you want inside: you just have to match the semantics of
>> Today, in the Internet, when a packet arrives at your border, the implied semantics are for you to forward it across (for transit) or
>> protocol where, in a multi-tier system, connections are for some boundary-to-boundary (for transit) or boundary-to-end node (for request termination) operations.  Presumably, for transit, what connection requests see is each entire network as a node in the
>> the request to internal actions that will fulfill this goal.  Again, internally, it can be what you like -- but if you adopt QRNA internally, it can be creating a new set of QRNA requests that reach from here to the gateway on the other side of the network.
>> Multiplexing: Lucho Aparicio's master's thesis addressed circuit switching, time-division multiplexing, statistical multiplexing
>> chain of repeaters. https://spie.org/Publications/Proceedings/Paper/10.1117/12.893272 or https://aqua.sfc.wide.ad.jp/publications/Aparicio-master-thesis.pdf
>> This has to coordinate with routing, below.  Naturally, we want to avoid fully blocking muxing protocol if possible.
>> Point four: an internetwork architecture needs to accommodate 1G, 2G and 3G networks. https://www.nature.com/articles/srep20463 Although
>> time.  Nevertheless, 1G, using acknowledged link layer entanglement creation to handle photon loss and purification (quantum error detection) to handle noise and decoherence, will definitely be the first deployed.  (Indeed, Delft is getting there, one step at a
>> So, we need an internetwork capable of interconnecting different connection architectures.  We have addressed how routers at the boundary can make entangled states that cross the borders. https://arxiv.org/abs/1508.04599
>> Even for first-generation networks, though, you have to have a mechanism for saying, "Okay, Bob, once you get a Bell pair with
>> then send the Pauli frame correction to Charlie and a notice-of-entanglement-transfer to Alice," and "If you have two Bell pairs with Alice, both with fidelity less than 0.9, then purify."
>> Our approach to this is to define Rules that have a condition clause and an action clause, very analogous to classical software defined networking (SDN).  For a connection, each node is given a RuleSet
>> that should comprehensively define what to do as local events occur (entanglement success, timeout, etc.) and as messages arrive.
>> and allows for explicit reasoning about how to achieve the maximum asynchrony in the network (rather than waiting for explicit instructions at every operation or attempts to make everything
>> I believe this RuleSet-based approach meshes will with the vision of QRNA.  Indeed, when combined with a rewrite engine at network
>> any qubits at the nodes that are currently assigned to a particular connection, well, that's connection state at each repeater/router. The scalability of this needs to be assessed, but I don't see a way around it right now.
>> (n.b.: as a network architecture aside, for the foreseeable future, there won't be any high-performance links; they'll all be low performance.  Therefore, there won't really be backbone, long-haul, high-bandwidth links, either; the network topology is going to have
>> This has a few interesting points: a. it limits the amount of information each node has to have on hand about the entire network, b. it allows Responders to innovate (within the bounds of the
>> I have presented this approach in any number of talks (see, oh, for example, https://indico.hep.caltech.edu/event/837/?print=1 -- there
>> only written down in an expired Internet Draft (https://tools.ietf.org/html/draft-van-meter-qirg-quantum-connection-setup-01)
>> 
>> Internet Simulation Package (QuISP). https://github.com/sfc-aqua/quisp/tree/master/doc
>> investigated quite some time ago in https://link.springer.com/article/10.1007%2Fs13119-013-0026-2 or https://arxiv.org/abs/1206.5655 a variant of Dijkstra's algorithm, which we inventively call qDijkstra.  We define link cost as
>> The biggest open question here -- and one of the things we are investigating -- is how to combine path selection with multiplexing/resource reservation.
>> Whew...let's see, we covered multipath above when talking about connections, so we're set there.
>> for quantum repeaters. https://arxiv.org/abs/2005.04617 and https://arxiv.org/abs/1701.04587 But this doesn't mean *at all* that
>> muxing decisions as outlined above -- you can't have accounting and authorization without authentication.
>> *Whew*, that's a lot of decisions, and lays out a lot of work to do. And we haven't even addressed some important topics, like naming.
>> If you can't carry all that in your head, just remember the three critical points: a recursive architecture for internetworking, RuleSet-based connection operation, and a two-pass connection setup routine (outbound info collection, inbound RuleSet distribution).
>> And although there is solid work on routing and multiplexing, designing a system that will be robust at scale and that will serve
>> _______________________________________________ Qirg mailing list [email-masked] https://www.irtf.org/mailman/listinfo/qirg
> 
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg