Subject: [Qirg] Fortnightly call for draft-irtf-qirg-principles

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 16 Sep 2019 09:21:27 +0000

Dear QIRG,

I would like to drive some work for the "Architectural Principles for a
Quantum Internet" draft and prepare for the next QIRG meeting.

I will follow up with Bruno's suggestion of a PERIODIC VIDEO CALL which
will happen fortnightly (once every two weeks) and will go on at least
until the next QIRG meeting. We will see how far this gets us.

I have set up a framadate (doodle) poll to find a suitable time for the
first call (30 Sep - 4 Oct): https://framadate.org/iJJozdIqRtrWhwbq

If you would like to attend, please choose a time that will work for
you for this call. Assuming we stick to the same time, this time should
also work for you for a call once every two weeks.

Recordings of all meetings will be made available.

For choosing times there was obviously an issue with time zones. I
picked times that should work for Europe and Asia since it's impossible
to pick a time that works for all time zones. However, this might leave
out anybody who is in the Americas - if none of the times work for you
and you would like to participate, please let me know. Recordings will
be made available so if you would just like to listen in, that might
work for you better. I'm also open to other people's suggestions how to
manage multiple time zones.

Once a time is agreed. I will set up a recurring meeting in some
commonly used conference applications: zoom, google meet, bluejeans,
whatever else works well on Linux.

Thanks,
Wojtek

---

From: Wojciech Kozlowski <[email-masked]>
Date: Wed, 18 Sep 2019 08:02:25 +0000

Dear QIRG,

A reminder to sign up for the call: 
https://framadate.org/iJJozdIqRtrWhwbq

I would like to announce the meeting (time, what software will be used,
agenda) a week in advance. Since Monday (30 Sep) looks to be most
popular I will announce it on Monday (23 Sep).

If anybody else would like to update the poll with their availability,
please fill in your availability by Monday (23 Sep). Participation is
obviously independent of whether or not you fill out the poll, but it
will let me take your availability into account.

Thanks,
Wojtek

On Mon, 2019-09-16 at 09:21 +0000, Wojciech Kozlowski wrote:
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---

From: Bruno Rijsman <[email-masked]>
Date: Sat, 28 Sep 2019 17:26:05 +0200

I finally got around to a detailed reading of draft-van-meter-qirg-quantum-connection-setup-01. I have some comments and questions, which I will spoon-feed to the list to avoid bringing up too many topics at once.

Topic 1: Traffic engineered path computation: determination of node and link characteristics: a-priori vs at connection signaling time

The draft proposes that:

(a) "The outbound request is routed from Initiator to Responder using a standard NextHop-based forwarding table" [section 3.1.1]

(b) "The outbound pass collects information about the nodes and links" [section 3.2] by pushing QCap blocks on the PathSetupRequest message [section 4.2]

The draft makes a conscious decision *not* to flood the node and link information a-priori, for example using a modified OSPF [section 3.2].

This approach means that the information about the nodes and links is available only AFTER the route for the path for a quantum path (= connection) has already been decided and only AFTER signaling of the path establishment is already in progress.

My question is:

Do we foresee a need for traffic engineering in quantum networks?

By that I mean: is there ever a need for the computation of the route of an A-to-Z quantum path to take into account the characteristics of the nodes and links between A and Z, as well as the resources that have already been consumed by other paths?

(As oposed to simply always using the shortest path based on hop-count or cummulative metrics, which is intended by the "standard next-hop based forwarding table" approach?)

For example: when we “someone” (e.g. ingress node A or an SDN controller) computes the route for a quantum path from A to F in the following topology, is there a ever a need to know the characteristics of the nodes (B, C, D, E) and the links (A-B, B-C, B-D, etc.) as input to the path computation function (i.e. a priori)?

      C
     / \
A---B   E---F
     \ /
      D

I think the answer could very well be "yes". Speaking generally, a traffic engineering function is useful when the network is not overprovisioned, i.e. when the available resources (e.g. bandwidth) are small compared to the consumed resources. In quantum networks, this is very much the case. Resources such as quantum memories and "bandwidth" (expressed as bell pairs per second) are very much limited, so a traffic engineering function appears to be useful.

If traffic engineering is indeed useful in quantum networks, it implies that the information about the characteristics of the nodes and the links, and information about the resources already consumed by other quantum paths need to be available a-priori before the route of a new quantum path is computed, rather than a-posteriori when the path is already being signaled.

To make an analogy: in MPLS OSPF-TE floods information about the remaining available bandwidth and administrative group memberships precisely for the reason that the C-SPF path calculation (or the SDN controller) can take this information into account when choosing the best path for an LSP. Only after the route for a new path (LSP) has been decided, it is then signaled using RSVP-TE (which is the moral equivalent of the PathSetupRequest message in this draft).

I do appreciate the points that the draft makes in section 3.2:

(a) Quantum networks will tend to contain long linear chains of closely spaced repeaters. The details of the repeater-to-repeater hops within such a linear chain are not relevant to the path compuation function. (Because there is no path to be chosen in a linear chain; there is only 1 option.) Thus, from a traffic engineering point of view such a linear chain could be treated as a single hop. This is very similar to MPLS where layer-2 repeaters are not represented in the layer-3 topology.

(b) The volume of link and node information is large and dynamic, more more so than in classical networks. The set of information that is flooded a-priori could be a subset and/or a summarization of the detailed information. This is acceptable because only the information that could potentially influence that path routing information needs to be distributed. The more detailed information that influences the RuleSet computation could still be collected at path signaling time, as suggested in this draft.

— Bruno

---

From: Marcello Caleffi <[email-masked]>
Date: Mon, 30 Sep 2019 10:56:25 +0200

Dear Bruno,
I will definitely go with “Yes”.

Indeed, some time ago I proved that the problem of the “optimal path” may fail with next-hop based routing (i.e., Dijkstra and BF -based protocols)
https://doi.org/10.1109/ACCESS.2017.2763325

I recall that, within the paper, I also reviewed some previous works that reached the same conclusion with a simulation-based approach.

Marcello

> Il giorno 28 set 2019, alle ore 17:26, Bruno Rijsman <[email-masked]> ha scritto:
>

---

From: Rodney Van Meter <[email-masked]>
Date: Mon, 30 Sep 2019 19:56:17 +0900

I agree w/ Marcello here.  But I think it’s mostly because of the need for some sort of connection setup because a connection is really a distributed computation, and because of the real-time constraints caused by memory decay.  I can’t wait for you, because my memory will decay while I’m waiting.

I think our simulation with Luciano Aparicio was the first quantum *network* simulation, and it appears to show that for small networks, stochastic multiplexing will work well.  But I always considered that just a tentative conclusion.
https://www.spiedigitallibrary.org/conference-proceedings-of-spie/8163/1/Multiplexing-schemes-for-quantum-repeater-networks/10.1117/12.893272.short?SSO=1 <https://www.spiedigitallibrary.org/conference-proceedings-of-spie/8163/1/Multiplexing-schemes-for-quantum-repeater-networks/10.1117/12.893272.short?SSO=1>

—Rod

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

> On Sep 30, 2019, at 17:56, Marcello Caleffi <[email-masked]> wrote:
> 
> Dear Bruno,
> https://doi.org/10.1109/ACCESS.2017.2763325 <https://doi.org/10.1109/ACCESS.2017.2763325>
> 
>> Il giorno 28 set 2019, alle ore 17:26, Bruno Rijsman <[email-masked] <mailto:[email-masked]>> ha scritto:
>> 
>> [email-masked] <mailto:[email-masked]>