Dan: Hello again.

Thank you so much for tuning in.

Welcome back to the quantum divide.

And I mean that, by the way, if
it wasn't for you listening,

I wouldn't be doing this.

And it is a lot of fun to do this.

So keep listening.

This episode right now is.

It's pretty exciting
for a number of reasons.

First of all, it's extremely
central to the focus of.

This, this podcast.

, it's focusing fully on the
state of quantum networking.

In the here and now.

So I have with me this time,
Wojciech Kozlowski and.

I'm not going to ruin his
introduction, so you'll have to listen.

A little bit further to, to catch that.

What's, super interesting
about Wojceich is his journey.

All the way through academia focused on
physics and quantum physics and optics.

And then taking a real U-turn and
working as a software developer in

a classical IT vendor for awhile.

And then taking a fortuitous turn to
combine both of these skillsets into one.

Uh, it makes for a really
interesting conversation.

Okay . Wojciech, thank you
very much for joining us.

It's a real privilege to
have you on the podcast.

How are you doing?

Wojciech: you for inviting me.

I'm good.

Thank you.

How are you doing?

Dan: Fine, fine.

Let's get started with a bit of a bit of
a run through your background, shall we?

And yeah, we'll go from there.

Wojciech: Uh, Right My journey,
I guess, started when I got did

my master's degree at Cambridge.

I did it in theoretical quantum physics,

after which I decided to follow on
with more quantum physics, and I

did a PhD in theoretical quantum
optics at the University of Oxford.

My thesis was on the interaction of
quantized light with ultra cold gases.

After that, I actually.

I thought I want to leave academia
and I did, and I worked for two

years as a software engineer for a
company called Metaswitch in London.

Over there I worked on as a
software developer for the

control planes of Metaswitch.

That's where I learned my computer
networking and I got quite a, I

feel, solid background over there.

And that's where I also learned
to appreciate the subject.

After which I completely coincidentally
found out about Metaswitch.

Quantum networking at an IETF meeting
to which I was sent by Metaswitch.

And I thought it was pretty
cool to combine both my previous

experience in quantum and my new
experience in computer networking.

So I joined QuTech first as a postdoc in
the group of Stephanie Venner, where I

worked on The software stack and network
protocols for the quantum internet.

But after two years, I transitioned
to a more engineering role.

And now my role is called quantum
network engineer within which I

work on actually developing this
software and network protocol stack

for the quantum internet alliance.

So I do less research and more.

Development now, and so this is where I am
right now as part of this current role, I

am doing mostly uh, software development,
but I am also work package lead in the

quantum internet alliance leading the
whole software and network protocol

stack development of the collaboration.

Dan: That's great.

That's a lot to dig into.

So I'm looking forward to this.

First of all, just an observation.

I think you're the only person
I know that's gone from quantum

physics into classical networking
and then into quantum networking.

Do you think it's just a timing thing,
or were you just sick of physics

by that point and you just thought
I need, I need something that pays

better than a postdoc or something?

Wojciech: Uh, I think I just
lost my momentum in academia.

I think academia is not actually really
the right place for me, to be honest.

Hence my departure from after my PhD,
I didn't really enjoy the process

of writing papers and publishing.

And I always preferred more
of like practical work of

actually developing things.

So when I just happened towards the end of
my PhD, explore more programming concepts

in my spare time, I got really excited
by it so much that I was like, I was

way more excited about what I was doing
after hours than my postdoc applications.

And then it hit me.

Maybe I shouldn't really
continue with a postdoc then.

So I quickly pivoted and applied
for software engineering jobs.

And it was pure coincidence that
I got a computer networking job.

I applied for many programming jobs
at that time, but it was mostly

motivated by just interests and
I think lack of it in academia.

So then I guess raised the
question, where did I go back?

Which I did go back with the intention
of not staying as an academic, to be

honest, but I just didn't really see
any other way to get into the field of

quantum networking because it's a very
young field and it's very difficult to

enter such a field, which is still in
such a heavy research phase, but then I

was very clear about my intentions and
hence, I Didn't continue the academic

path, and instead I agreed on the position
of a quantum network engineer with

QuTech, where I did the development of
the, where I work on the development of

the software and network protocol stack.

Dan: Yeah, it's funny how the decisions
in life or the opportunities that come

along take you on a completely different
path than maybe you originally planned.

So if you're looking for a
developer's job, I'm just going

to focus on that for a minute.

Did you do a lot of coding when you were
doing your PhD and what kind of languages

did you use and, what did that look like?

Of

Wojciech: I did a lot of simulating
because my PhD was in theoretical

quantum physics To my dislike, to
be honest, it was mostly MATLAB but

that was the best tool for the job.

So that's what I used.

There was a tiny bit of
code I had to do in C.

There were some new simulation methods
called, I think it was called tensor

method program or something like that.

There was very good for simulating very
specific systems that we were studying.

And I did.

Dive into that a bit, but
it was still mostly MATLAB.

Nowadays, I guess it would be
Python mostly with NumPy and

SciPy, but that days was MATLAB.

So when I had some C experience from
some summer internships before that.

But when I started I was, I
basically was self taught combined

with some MATLAB experience.

Dan: Alright, I mean C is not an easy
language to learn, so you've really

got to immerse yourself, haven't you?

Wojciech: Yeah.

Yeah.

Dan: yeah hey, before we get to QuTech
would you like to talk a little bit about

Metaswitch and what you got up to then?

You mentioned coding the control planes.

Did that uh, was that all in C?

Wojciech: So Metaswitch the business
of Metaswitch was wider than just

control planes and networking.

They're most, they're generally in
a larger area of telecommunications.

Also just for completeness, since I
left, they were bought by Microsoft

and their business has, I think,
slightly more shifted to different

areas, I think related to 5G.

But going back to when I was working,
I was working on a team responsible

for developing software control planes.

Which were then sold to OEMs who then
sold the end product to operators.

My work was in C and C
which I really enjoyed.

And I learned a lot about the programming
languages and that particular challenge

that I was engaged in when I was
there was Metaswitch was developing

integration with integration layer
with different hardware vendors.

Historically, they didn't really do the
integration with the hardware, but turns

out it's a good product on its own.

So they were developing a intermediate
layer which would allow them to integrate

more easily with different underlying
platforms, such as Broadcom, or actually

one example, it was also a P4 soft switch
as well, which was quite interesting

because it's quite useful for testing.

Dan: Yeah.

I don't know if they're in the SP
domain or were, but certainly there's

been a journey of disaggregation in
that industry for a long time, right?

In terms of Silicon
software, hardware, and

Wojciech: Yeah.

Yeah.

Dan: So great.

Okay.

Let's go on to QuTech, shall we?

Tell us a bit about your work at QuTech
in the stack and integration team.

You've basically gone from
research to engineering and

yeah, what does that look like?

Wojciech: Oh, it was
an interesting journey.

When I joined QuTech I knew quantum
physics and I knew computer networking,

I didn't really know quantum networking.

So a lot of it was also
a lot of learning for me.

Okay.

And it was very enjoyable.

My first, first, I was there as a postdoc
and effectively exploring the area of

how to construct network protocols.

, this was an, this Was an interesting
question to consider because most work

in the field is still very much of
the physical layer and mostly focused

on connecting nodes directly to each
other and getting the physics right.

Cause there's still many
technological obstacles to.

Developing these devices
and technologies further.

But there was also a part of QTEC that
was exploring things, but further as

to how does one actually construct the
higher layers the link, the network

layer protocols, the link layer protocol
was actually wrapped up just as I So

my focus was mostly on the network.

Layer, how does one interconnect
larger networks and so on and so forth.

And that's where I could actually bring
my experience from Metaswitch quite

significantly because the people at
QuTech were predominantly from a physics

background whereas I could use the
fact that I had experience with control

planes and I knew what a control plane
data plane separation was and how does

one, and also I had a personal interest
in software defined networking from

my time at Metaswitch, which I thought
actually was a great fit for research.

Because in fact, that is how
software defined networking

was originally developed.

And I think a lot of that slowly
permeated the community at QuTech and

it's translated to how things are built.

And so as part of that, I proposed a
network layer protocol proposed it's

a research and academic exercise.

It produced.

I introduced some concepts that these
seem to work well in simulation.

There was an intention of testing them on
hardware, but it turns out building and.

Network of multiple nodes is much
harder at the hardware level.

So that is yet to come.

But after that work, I got much
more deeply involved in actually

developing the software systems and
actually translating all of this

research of the link layer work.

Protocol that was proposed before in the
network layer protocol into an actual

software implementation and combining this
with other research that is happening at

QuTech as to how to execute applications
on these nodes and putting that into

a single software system that actually
runs on an actual quantum network node.

So I got involved in that.

It sits under the name of QNodeOS within
QuTech the idea being that there's an

operating system that runs on these nodes.

And as part of a collaboration between
the research groups of Ronald Hansen and

Stephanie Venner we Demonstrated actually
the ability to deliver entanglement

through such a software stack on the
nitrogen vacancy nodes at QuTech.

And this was a very interesting,
very valuable demonstration because

so it was previously was already
demonstrated that the hardware is

capable of generating this entanglement.

We demonstrated that is not
only capable of generating this

entanglement, but also doing it.

Using a platform agnostic network
protocol stack, or to an extent

platform agnostic, one cannot always
erase all platform independent,

all platform dependent features.

And we showed that this is possible
and that was, and we already learned

a few things from that experiment.

Primarily that is very difficult to
integrate software with hardware systems.

And then one must and that is basically
just challenging and one has to

work very closely together and just.

really focus on these
integration challenges.

So it was an interesting challenge
and it was a very good demonstration

and the work on that is still ongoing.

Within the Quantum Internet Alliance
we're taking that further and the

intention is to translate what we did
on two nodes to eventually a prototype

network which connects metropolitan
networks over a long distance backbone.

Dan: It's fascinating stuff.

So I'd like to know before we go on to the
Quantum Internet Alliance the protocols

and the layers that you're talking about
there in, in the experiment with QNodeOS.

Was that a single hub, spoke type
entanglement, distribution setup,

or um, the actual experiment itself?

Did you have a, a multi
hop type topology or

Wojciech: That experiment
was much, much simpler.

I guess the question comes up
because it's inspired by some.

Quantum key distribution networks,
but or, but when, so an important

distinction between the demonstration
that was done at QuTech was that it

involved that the end nodes had a
quantum memory and that significantly

raises the challenge of the experiment.

Arguably, it was a hub and spoke
topology, but really it was two end

nodes connected via midpoint station.

Yes, a hub and spoke,
but with only two spokes.

Effectively, from our point of
view, it was a two node network.

And so the demonstration
Yeah, so it was simple.

And the thing is, it was simple
because this was already challenging.

This is not a very simple setup
to run and maintain in the lab.

It requires constant attention, or
near, or a lot of attention from the

experimentalists to manage it, and to
recalibrate the setup every now and then.

So there, whilst there were originally
intentions to run it on, because In the

lab, they have demonstrated up to three
nodes, but that is really challenging.

So running a stack on top
of that was just considered.

We could already demonstrate a lot with
two nodes and that's what we went for.

Dan: Okay lemme get this straight.

You've got nitrogen vacancy or
equivalent systems on each end and.

How are you entangling them?

Was there a source in the middle?

You mentioned the middle station.

Wojciech: No, that is not how
this particular platform works.

The method you mentioned is a valid
method of entangle, of entangling

nodes, but this is not what we use.

The method used for a nitrogen vacancy is
called heralded entanglement generation.

What happens is that you, the nitrogen
vacancy has an electron spin, has an

electron, which has a spin and you
entangle the electron with both of the two

nodes, you entangle the electron with a
photon timed such that these photons are

emitted in such a way that they arrive at
the same time at this midpoint station.

This midpoint station contains only what
many people call a bell state analyzer.

Effectively, it performs what's
called a bell state measurement.

Physically, it's a beam splitter
with two or more detectors,

depending on what kind of qubit
encoding one uses for the photons.

And what happens is that the
process of detecting the photons

in the middle actually causes the
electrons to become entangled.

With each other and the detector result
will tell you also which of the bell

states your two electrons have ended up
in, hence the name bell state measurement.

So the process is two photons are
emitted from the two end nodes,

they meet in the middle and you end
up with the two, the memories of

the two end nodes being entangled.

Dan: Very nice.

So once you've got a a reading essentially
of which bell state it's in, out of the

four different bell states, do you, did
you then use that as a, because you can

use that as part of your calculation
for teleportation or something.

Did you go that far or did you then
just measure the entanglement and

then that was the main outcome?

Wojciech: Yeah.

So in that experiment, we basically
just did a we did do Pauli

corrections, so we did correct.

for the state very often, but generally
the goal of those experiments was

mostly to generate entanglement to
their stack and perform measurements

and do some tomography on it.

So really what was done is mostly
validation that entanglement generation

did produce entanglement, but we
did use an API that is eventually

meant to be used for applications.

So, So, Yeah, we didn't really
run anything complex and mostly

just use entanglement, but we
still use the entanglement.

Dan: Was there a few firsts in there,
in terms of what you had delivered

Wojciech: So, In terms of physics,
no, in terms of physics, we didn't

do any novel physics, but in terms of
running a combined hardware software

stack, yes, it was very much the first.

We actually ran a general purpose
quantum network protocol stack.

to generate this entanglement.

And so therefore we demonstrated
the first steps towards building

these necessary abstractions for
building up more complex networks.

And that on its own, I
think is very valuable.

And also we just demonstrated that we
are at a stage where we can actually

now start running, thinking about
running applications on these nodes.

These applications will not be complex,
but it just shows that We really have

reached a stage where we're doing a lot
of engineering and application development

rather than fundamental physics.

Dan: It's almost like the, yeah,
the fundamental physics becomes the

resource that you consume, and you

Wojciech: Yeah.

Dan: I was going to say you don't
need to worry about it, but I'm sure

the experimentalists are falling
off their chair as I said that.

Uh, You mentioned the stack, the network
stack, the generic network stack what,

what is that in this type of environment?

Um.

Wojciech: That's a good question.

So, um, From classical networking,
so classical, I use the word

classical, I mean non quantum.

It's an interesting anecdote.

It was a bit, Quantum physicists often
use classical to mean non quantum and

in quantum physics, that's obvious.

But then I started talking to
networking people and they were

like, what do you mean by classical?

Because to most people, classical
means old and conventional in some way.

So I tried to correct myself.

Anyway, a bit of a side anecdote, but

Dan: they think you were
connecting, over a 9600 board modem

or something and that was you?

Wojciech: Yeah, so they were like,
they were, so when I'd say classical

internet, they were like, why are
you referring to the old internet?

It wasn't clear that I was just
referring to the non quantum internet.

so, so, so, So when I say classical,
I just would do want to clarify that.

I mean, Just non quantum.

So The network stack has, so classically
we're used to sending packets.

So data enters one side, the headers
get some, the packet gets some headers,

it gets sent off, the headers get
popped and another one gets pushed

and eventually gets to the other side.

That is not how quantum and the quantum
network stack looks like, at least

the way we are developing at QuTech.

Because data transmission is not our
primary goal For quantum networking, it is

possible, but that's not our primary goal.

The reason for that is, is because
many quantum network applications rely,

rather than relying on a quantum data
transmission, rely on the consumption

of entanglement as their resource.

And the reason why this is a
resource is because it provides

effectively, in very brief, briefly
summarized, it's a source of secure

and secure correlations, basically.

So you've got these two.

Two locations which produce correlated
data and you know, they're also secure.

And from that, you can build up
applications from that resource.

You can build applications,
but on its own, it's not data.

So what you generate is entangled
pairs between two end nodes.

then you consume this entanglement.

One of the things you can do
with this entangled pair is

actually Teleport quantum data.

So yes, you can do quantum data
transmission, but it means that

our fundamental abstraction or
fundamentally unit of networking is an

entanglement, not data transmission.

And so, therefore, the network stack
is built around that concept, and that

was a concept introduced in this link
layer paper from the group of Professor

Venner, and then which proposed this
network stack that did that, and hence

it built it up in various many layers.

And so therefore the physical
layer, so the idea would be the

application receives entanglement.

And so therefore how to build up to
that is the bottom, just like a normal

network stack, one has a physical layer,
the physical layer in this vision is

responsible for the process of actually
physically generating this entanglement.

In the case I described, it's done through
heralded entanglement generation, but

there's other schemes as well, which,
are Should be compatible with this model.

Then above that, you've got a, and one
interesting aspect of this entanglement

generation is that it's probabilistic.

So it doesn't always succeed.

In fact, it actually rarely succeeds.

It's like in the lab, it's like one
in many thousand attempts succeed.

So the vision was that the physical layer
is the layer that is like it attempts

entanglement generation mostly fails.

But it attempts it, so therefore then the
link layer is responsible for wrapping

that into a reliable service as to,
okay, how do we translate these, this

probabilistic process into something
that one can then use in an application.

So therefore a link layer protocol was
developed to translate that exactly

into something meaningful, but also
a meaningful interface and all that.

And then above that, the network layer
does the next step, which is, okay well,

I've got my entanglement on a link.

How do I then How do I get that
to the other side of the network?

Because so far, I've just
limited myself to a link.

And so therefore, I actually have to
first introduce a new concept which

is called entanglement swapping,
which is the idea that the way you

distribute long distance entanglement
in a quantum network is not by.

Sending this entanglement down the
network, but rather by generating an

entangled pair on every link in the
network and then performing what's

called an entanglement swap operation
at the intermediate nodes, the routers,

and this entanglement swap will
actually cause will effectively stitch.

The entanglement together and
result in end to end entanglement

between the two end nodes.

And the responsibility of the network
layer protocol on which I directly worked

on was to effectively, how does one
develop a protocol that manages this?

What are the building blocks?

And I find this very project very
interesting because one of the things I

learned at Metaswitch was about MPLS, the
multi protocol label switching mechanism.

And I found it very interesting because.

If you learn about networking from
textbooks, you learn about the internet

protocol and you learn about packet
switching and how packet switching

is better than circuit switching.

But then you'd go and do networking
with a vendor and you learn about

MPLS and you learn about all these
circuit switching methods now.

And it was felt like a natural
fit between quantum networking.

And so it felt like a very natural
fit because while we have a

resource, we generate on every link
and then we stitch it together.

Why would we not do
circuit switching for this?

Because then we can much more easily
parallelize the work, coordinate

it, and then reuse potentially, my,
my hope was that potentially in the

future, one could then reuse all the
various MPLS knowledge protocols was

so to integrate with it together.

We're not there yet, but
that was my original.

And that's what, so therefore
that's what the network layer does.

The protocol I proposed claimed
that circuit switching is the way to

go for at least this generation of
quantum networking that works based

on heralded entanglement generation.

It may be that in the future, just like
for classical networks in the future that

we should move from circuit switching
to packet switching, but at the moment,

I, in my opinion, is at least that
circuit switching is the way to go.

And then above that, originally there
was also a transport layer proposed.

It was meant to do effect.

It was meant to be responsible
for this teleportation process

of qubit data transmission.

But we found that it's actually just
At the moment, it's just easier to do

that at the application layer and to not
have this intermediate transport layer.

So we don't really have a
transport layer at the moment.

and That, that's roughly
how it looks like.

And then eventually gets delivered to
the application and the application

will perform operations on it.

Running quantum network applications
is a whole zoo of challenges.

Mostly related to the fact that the
quantum memory is very short, and one

has to be very strict on scheduling.

And it's a very challenging problem,
which is also worked on at QuTech.

But I don't directly work on that problem,
but others work on that at QuTech.

Dan: Wow yeah, loads to pick up.

One thing that you mentioned, stitching,
that just cast my mind back to, when I was

a network engineer, buildinM NPLS networks
and stitching pseudo wires together.

To basically jerry rig something up.

It wasn't a very elegant
way of doing things.

And obviously, The technology has
come on a lot further now with segment

routing and there was VPLS for a while
and a whole bunch of other techniques.

Right.

I see the link and the analogy, it
does work quite well, but then of

course you got to forget that there are
tunnels, there's no tunnels, there's no

layers of encapsulation per se, unless

Wojciech: perhaps argue, it
depends on how one constructs.

We're really at the very bottom
of our abstraction layers.

No one can construct more complicated
things, but as an example.

So this entanglement is quite
flexible and one can potentially

start constructing sort of tunnels.

One does effectively
have some form of tunnel.

I'm really going into like very
hypothetical thinking here, but, or

being very creative with what I'm
saying or using my words, which is

that if you have entanglement between
the two end nodes and you do, and you

quantum teleport a qubit of data from
one node to the other, that data you're

teleporting never enters the network.

So it's effectively
going to the other side.

And so in a sense.

It is a tunnel.

It's, I wouldn't really call
it encapsulated, but yeah.

Yeah.

Dan: it either way, couldn't you?

The fact is you're putting some data
in and you're getting some data out.

Surely that's what a tunnel does, but
then there's no encapsulation per se.

There's no layers of headers and so on.

Anyway, very interesting
to talk about that.

What about the entanglement generation?

You said one in a thousand.

Obviously that's quite.

a very small number, but,
over what time frame is this?

And actually, are you thinking,
actually, Dan, that's quite good

compared to uh, you know, whoever
was experimenting before you.

Wojciech: So I'm going to first put a
caveat, which is that I'm not a hardware

person, so I'm just going to say what
I know based on my experience, but uh,

yes, so This the probability of success
depends first of all, on the platform

you use and the distance between the
nodes, because the primary effect, as

you keep extending the distance, the
primary source of loss is actually the,

you're losing photons on the fiber.

You really are sending, like
classically, you're sending a whole

massive, powerful signal containing
multiple photons down your fiber.

In quantum networking, you're
sending individual photons down the

fibers and the photon can get lost.

Just scattered or absorbed or something.

And that's a big source of loss.

And so therefore, as you extend
to larger, longer and longer

distances, it does impact your rates.

I, there's been now actually literally
just this Wednesday, there was a

paper from about an experiment with a
different platform in Boston, and there

was actually a month ago, a paper from
about an experiment between Delft and The

Hague from the group of Ronald Hanson.

I don't know what the rates there
were that there were, but I'd imagine

there, They're not good enough to
run an application, and actually

no, one in a thousand is pretty low.

One cannot really run
meaningful applications on this.

And one can see that because for
example, when we compare it to

quantum key distribution networks,
we're already talking about, I

think, kilobit of secret key.

And for each secret key, you
do need a qubit effectively, or

something equivalent to a qubit.

And and a quantum key distribution network
can achieve this because they don't

use quantum memories, they just emit.

They're photons and they're measured.

And so therefore, no,
the rates are really low.

And they're not high enough for meaningful
applications, and you're hitting just

another barrier, which is that if you're
generating your entanglement very low,

and your quantum memory's lifetime
is very low, you're very unlikely to

ever have multiple entangled pairs
at the same time, and you do need

that for more complex applications.

There's still a long way to go.

It's very challenging.

Thanks for tuning.

It's a challenge for
experimentalists and yeah,

Dan: It keeps all the physics
departments going worldwide.

Um, yeah, Yeah.

I mean, What we've discussed so far is
one element at the core of the way a

quantum network would work, but ultimately
there's many other challenges around it.

In hearing you talking, I was
thinking about the actual way that

you're generating these photons is
through a a vacancy of some kind.

If you were to somehow, if you wanted
to do some computation across that

with, Qubits which are more fixed or at
least controllable, then again, you've

got another layer of issues in terms
of how you transfer the entanglement,

how you transfer the state, how you
move, how you consume the entanglement

with a local qubit of some kind.

Wojciech: Actually I would do want
to make a point about it because this

is the advantage of this platform
that Delft has been developing.

So there's generally been other platforms,
which I believe would have had better

rates or potentially better quality
of entanglement, but the advantage of

the platform developed at Delft was
always that it allowed for exactly

this ability to process these qubits.

So there is There's different
axes along which one can

progress in quantum networking.

One can work on the distance, which is
very important, but one can also work

on functionality, as in increasing the
ability of what we can do on these nodes.

So we call these nodes that have
these capabilities of processing

the qubits that belong to this,
these qubits that are entangled with

the other node, processing nodes.

And these vacancy, these color centers,
So there's nitrogen vacancies at

color center, and these color center
platforms actually allow you to do that.

And that's why they're very powerful.

And that's a very important to note.

And I guess what you may, might be
referring to is that there's also

these devices, which we call quantum
repeaters, whose task is mostly to

stitch this entanglement together
to do this entanglement swapping,

and they're optimized for distance
and speed, but they generally don't

have this processing capability.

And this is actually distinguishes
these two different platforms.

And I'm pretty sure this is now.

Why generally accepted consensus in
the field that the platforms used

for stitching entanglement by the
quantum repeaters are going to be

different than the ones we used for
the processing and end nodes, which

actually then execute the applications.

Dan: right.

Interesting.

Yeah.

I guess the requirements are
very different, in terms of the

rates and also how long you need
to store states for, if at all.

Wojciech: Mostly about
capabilities as well.

It's just it's not.

It's not just because you have a
qubit doesn't mean you can actually

manipulate it in any way you can imagine.

Many quantum repeater platforms
are actually mostly just capable

of storing that qubit and then
doing some simple and performing

an entanglement swap effectively.

Whereas these processing nodes
have now more capabilities.

perform quantum computation
gates on these stored states.

And this is very important.

And the thing is, and usually the
trade off is, the more capable

your node is, the more capable of
various gates it is, the less good

it is at rates and doing it fast.

So yeah, so it's the less capable is it
of rates and doing it over long distances.

So it's a fundamental
trade off in this field.

Dan: Yeah.

So in terms of the quantum networks as a
whole right, the whole industry I've heard

the term next generation quantum networks
as a way to describe networks which aren't

QKD, which are typically point to point,
and I struggle with that because it's not

really a next generation network, it's
really a first generation quantum network.

FGQN, what are your thoughts on that?

Wojciech: I actually
would consider quantum key

distributions a quantum network.

Fundamentally, they are quantum.

They're already doing something that is
quantum and quantum key distribution will

essentially always be a basic application.

It's a basic, it will be one of the
applications of quantum networking.

And one of the reasons actually I am
keen to call quantum key distribution

networks quantum networks already is
big first for many reasons, actually.

And I'm very excited about all of them.

One, which is that a lot of.

In Europe, there's many operators and
countries deploying these networks,

either as part of their national research
and education network, or sometimes

even commercial telcos, and they're
learning a lot of important lessons,

which will apply to These next generation
networks such as because you need to

transmit single photons in both cases.

And so therefore there's already a lot
of lessons learned about what it means

to have single photon transmission.

There's many interesting lessons to
learn here, such as like the prime,

I think one of the, so I'm not too
familiar with operators really, but

my understanding is that operators
would usually talk about distance.

Between points, whereas
physicists would always like, I

don't care about the distance.

What is the loss of that fiber?

Because there's they would usually
say I can deal with any fiber as

long as the loss is below this limit.

And this was something
that was a bit of a.

Barrier and they had to translate
between themselves and get to that.

So in that sense, there are
very many valuable lessons.

Another reason why I find it interesting
is because I talked about stitching.

Quantum key distribution networks
also have a concept of stitching.

For example, if one worked to construct
point to point networks, yeah,

the one doesn't do any stitching.

But what happens if you want to
transmit quantum keys over a distance?

Then these intermediate nodes
need to somehow be able to Then

what happens is that one basically
generates secret keys on each link.

And somehow from these, all of these
secret keys must translate that to a

single key being owned by end nodes.

So what happens is also
effectively a stitching operation

on all the intermediate nodes.

Effect what's really done is you
encrypt one of the keys with the

other key, and then you transmit it
and you keep re encrypting the key.

So it's, but it's a very similar
operation in some senses.

Some sense to entanglement swapping,
but from the point of view of control

and management, it's very similar
because effectively it's again, circuit

switching to some extent, not to a
large extent, actually a lot of the.

Protocols, the control and
management later might be shared.

A lot of the management
information will be shared.

So there's all the information about
fiber, your emitters, potentially, how

do you manage a network, how you debug
such a network, an interesting question

will also be, it's something, how do
you make sure that what you're doing is

actually secure and so on and so forth.

So there's a lot of lessons to be learned
in this area and they will translate.

To the next generation networks then which
follows on to my next reason why I find

this interesting and why I would still
call quantum key distribution networks

quantum networks, which is that they will
evolve into entanglement based networks,

because the fiber is already there.

The device already there, the
expert expertise is already there.

It really makes sense to just
evolve this rather than building

another network side by side.

And finally, a little bit of
a pitch for a technology that

spun out of Delft, which is.

Measurement device.

Independent quantum key distribution.

Which is a different protocol of quantum
key distribution, which instead of relying

on photons emitted from Alice and received
at Bob, in this case, Alice and Bob

both emit photons, which then meet at a
midpoint station, which is usually called

Charlie, and they, and then and then from
that, they are able to derive a secret key

between Alice and Bob and the physics Of
this measurement device independent QKD

system, MDI QKD is very similar to the
entanglement distribution that I've just

described with nitrogen vacancy centers.

So therefore, they provide a natural, if
one were to deploy these MDI QKD systems,

they provide a much easier way to upgrade
to the next generation quantum network.

And this is like another reason why.

I would either call them the already
quantum networks or one, if one

wants to debate this point, one can
call them proto quantum networks.

But in, in every aspect, I,
it's going to be an evolution.

Dan: Yeah.

I'm trying not to get too hung up on it.

I'm having a debate with myself in
my head and it's not very healthy.

But yeah, you're referring to the one
time pad type approach, aren't you?

Extending the keys
across a series of links.

So it's a single application
of quantum networks, isn't it?

Rather than a quantum network in a
traditional classical way of calling

something a network, it can have, it can
serve multiple applications generally.

Wojciech: Yeah, correct.

Yeah.

It said application specific though.

There are some people are in principle,
if one could find applications that

use these secure correlations in a
different way, one could reuse these

quantum key distribution networks,
but the moment the quantum key

distribution is the application for this.

Dan: Yeah.

And the, hey the algorithms and everything
for the different QKD implementations

have been around for decades

and, uh, it's still, there isn't yet
another application that uses the

correlations in that way.

Great.

So let's talk a bit about the controller
management layers software stack.

And you did mention to
me a project with SURF.

So that's coming back, into the
experimental world in some sense.

Why don't you tell us about that?

Wojciech: Yeah.

That was a very exciting
project I did with SURF.

So it started, I think in 2020
and basically it was just, I

think this was SURF's first
foray into quantum networking.

SURF, just for context, SURF is the
operator providing the national research

and education network in the Netherlands.

And they, as part of their work,
they do explore novel technologies.

And I was performing, I was on this
project with one of their advisors.

And what our goal was effectively
to figure out how would a network

operator run a quantum network.

And so therefore it was very exploratory.

In the sense, so we discussed like
how these midpoint stations could

be used by the different in a how
a telco operator could see these

midpoint stations and how does one
deploy these and so on and so forth.

So that was a lot of like discussion,
but one of the more interesting things

we did eventually went, got down into
practical work after doing a lot of

just like, how would we do things?

What applications are there?

We did as part of that
also identify two key.

Distinct services an operator might
want to provide for their users, and

mostly the services were very low level.

So we basically said either the
operator, either the user is only

interested in correlations, so
therefore QKD like services, or

they're interested in entanglement.

And the distinction between
these two services is that.

If you're only interested in correlations,
you're probably, you can tolerate

probably a lot of jitter, you can
tolerate delays between the different,

between subsequent correlations,
entanglement generation, simply because

you measure your qubit immediately and
then you store that as classical data.

So therefore you're not subject to this
limitation of quantum memory lifetime.

Whereas if you're interested
in correlations, Entanglement,

you're now subject, you now have
to race against decoherence.

And so therefore you have
very strict timing limits.

And then you really need at the moment
with our technology, you would really

need your resources reserved ahead
of time and everything delivered

to a certain quality of service.

So we identified that.

Then we dug into some
interesting projects.

So SURF has a workflow
orchestrator, which is open sourced.

And they, we were just.

Let's just try and integrate this
workflow orchestrator with simulation.

And we did, and that was
actually very exciting.

The guy from SURF actually added
all these various concepts to their

inventory management system of what
does it mean to have a quantum?

There's a quantum node that there's
this heralding station and there's an

end node and you configured everything
in this orchestrator and this GUI.

And then we made that issue req, then
I implemented the simulation side

of things, which actually had like a
simulated controller and simulated nodes.

And that would issue this
workflow orchestrator.

This actual workflow orchestrator,
which they normally use in

production, would issue these
requests to the simulated network,

simulated and return some results.

Didn't really do anything.

Particularly useful, but we did have an
orchestrator run a simulated network,

which on its own was interesting.

It was an interesting learning experience.

It was a nice demo, but also I
used it as a chance to explore

something we can discuss later, but.

I implemented the simulated network
using P4 actually for quantum.

So part of the exploration we did in
this project as well was how does one

actually design these protocols and
how does one implement a control plane?

That, because in fact, for this
orchestrator to talk to the network,

there needs to be, there had to be some
kind of controller, which had a control

plane, which understood how to install
these various rules into the nodes.

And that's what and we did that with P4.

And

Dan: hold that thought for a moment.

Wojciech: okay.

Dan: You reminded me at the beginning
of what you're saying there about

the education and research network.

In the Netherlands, SURF.

There's a, it just reminded
me of the one in the UK, JISC,

which has a network called Janet,
which always made me chuckle.

Wojciech: Janet.

Yeah, I'm familiar with that
'cause I did my degrees in the uk.

Dan: There you go.

Yeah.

I guess most countries have something
similar and yeah, they're often a

hotbed for uh, innovation, aren't they?

So yeah, what you described there was like
a service, service delivery orchestration.

Wojciech: Yeah.

Dan: Maybe you had some life
cycle management in there.

I know we're going to talk about
different standards and activities

in the industry on that front.

But it made me think of MEF, and I
expect at some point in the future,

MEF may want to, there may be a working
group on, on, on quantum services.

Perhaps this is way down the
road because they focus wholly on

service orchestration and assurance.

And, that's way down the road once
the technology actually works.

So it's way too early to do that yet.

But yeah what we haven't,
Talked about in detail.

Yeah.

It's the QIA and you've dropped
the name of a couple of times.

So what is it?

And what's your work in the Alliance?

Wojciech: So the Quantum Internal
Alliance is a pan-European collaboration

of about 40, 42 partners across Europe.

It's goal is to develop the quantum
internet in Europe, or the goal really is

a global quantum internet made in Europe
and So we hope that by the end, by about

2029, the end of the decade, we will
manage to develop technology to build

a prototype network, which connects to
metropolitan scale networks over a long

distance backbone of over 500 kilometers.

So that's the ambition.

And not only that, and then likewise,
these goals sound very physical there.

The goal is that this network is
actually capable of executing.

Applications, so actual platform
independent software applications

executed at the end nodes, where
the connection is established by a

control plane and managed by protocol
by a protocol stack in between.

So this isn't so it's not an ad so
that it is not an ad hoc physics

experiment to demonstrate the physics.

So the goal is really to go for
a full stack quantum network.

So as the goal, it requires a lot
of effort on the processing nodes

and these quantum repeaters and on
the software and our protocol stack.

So I'm mostly involved in the, I am
involved in the software and our protocol

stack mostly through the team at QuTech,
where we actually develop these systems

on the nodes for the nodes as well.

And we've already demonstrated it once.

And we hope to demonstrate it on
a very, through various milestones

throughout before we finally
demonstrate the prototype network.

But that's where we're at right now.

Dan: Yeah, that's pretty exciting to
hear, especially with so many different

organizations and countries involved.

Um,

Wojciech: Research and
research organizations like

universities, RTOs, and startups.

And it's just, it's difficult to work
together because it's just difficult

to have so many partners who have very
specialized expertise to work together.

So it's very challenging, but
it's very rewarding as well.

Dan: I guess it's a a
real task for the team.

To to govern it and manage it

Wojciech: Yeah.

Dan: One thing that there's a few
things coming together here, I guess,

in that you would the experiment
you did with SURF that concept, is

that similar to what you're planning
to apply into the QIA in terms of.

Bringing up services and
managing them in life.

And also it made me think, you mentioned
fiber earlier on and the need for less

loss on fiber for entanglement services,
did you bake into that some of the

variables of the physical hardware so
that perhaps, and this may be something

to think about as a, as a, as something
to add at a later point, is that if you

can sell, if you can have records of the
loss and the quality of the fiber either

from OFDMA type checks, or whether you've
got some measurement on the transceivers

themselves on a link by link basis, and
then bring that into the decision making

process of the orchestrator to use the
best fibers for the entanglement links.

And the perhaps the slightly
more lossy ones are more

likely to have the QKD service.

Wojciech: That's pretty much it.

Very ambitious and no, we're
not going getting that far.

No, the goal for the prototype
network is, okay, I say mostly to

work, which makes it sound simple,
but that's already quite difficult.

So now the prototype network
will still be in a sense, just

an experimental demonstration.

Rather than a fully functional system
ready for an operator to take over.

We are aiming to try and make, as the
collaboration is aiming to try and

make some of these systems more ready.

So there is a goal to make some of
these nodes like data center compatible

and so on, but overall the network
and the technology won't really be

ready for an operator to take over.

And the thing is that the way we'll
deal with losses is just try to reduce

them and hope for the best, to be
honest, and then just live with them.

Because there won't really
be much of an alternative.

Fiber usually and we're not
going as far as orchestration.

That was an interesting project
we did with SURF, but at the

moment, the focus is more on just
developing a basic control plane.

What kind of elements do
we need in a control plane?

Because it's not really obvious.

It'll be, I think it'll be a very
challenging demonstration to show.

So we've not yet really demonstrated an
interaction between a control plane and a

data plane protocol in a quantum network.

There are some demonstrations in other
places in the world where they do have

a control plane, but that's mostly
to manage the optical infrastructure.

Dan: Can I just check here?

When you talk about control
plane, you talking about

individual node control plane?

Or are you talking about a software
defined control plane across?

Wojciech: talking more broadly
of the control plane which can be

implemented as either that or a
software defined control plane.

So I just mean about the entity that
performs tasks that are not That are

not directly manipulating the qubits.

So I would define data plane as the
part of the protocol that the data

plane protocols that directly manipulate
the entanglement to deliver it.

And the control plane being the entity,
be it distributed or centralized.

Coordinates this process by
installing rules into the nodes.

And so therefore what we're
aiming for is to have some kind of

interaction between these things.

So for our demonstrations, we
effectively have a static control plane.

We just installed these
rules ahead of time.

But for this demonstration here,
we hope to have something a bit

more dynamic and to the number one
challenge this control plane will

solve is effectively scheduling.

As I said, quantum memories are very
short lived, which means that if you want

to have, Entanglement between two nodes
over multiple hops, then the entanglement

generated on each individual link must
be generated very close in time, and the

entanglement swapping must be done as
soon as possible so that the entanglement

you get at the end nodes is still of
good enough quality for the application.

So we're, you've pretty much, with the
current state of technology, we anticipate

that for a while, for quite some time, you
will need to be, have to basically reserve

the entire pathway for some amount of time
between a pair of end nodes for the end

to end entanglement generation to succeed.

And so therefore that's what we will
have this control plane doing and how

we plan to have that manage the network.

Dan: Fascinating.

I was thinking about was the fact
that you're doing this entanglement

generation perhaps you could help
the, me and the listeners understand

in terms of timing, what kind of
first of all, accuracy is required.

On clock rates on endpoints to ensure
that measurements and everything are

performed at the right time and the right
photon is being used or is it always

at this point in time that you're just
sending one at a time and you consume

that one and then you wait for the next
one because I guess in terms of quantum

memories you're limited at the moment
in what you could build into the node

Wojciech: so it's a good
question about timing.

Now, there's a lot of, it's a very
complex subject and I won't be

able to really give it justice.

But I'll give a few notions
of where timing is important.

Dan: give it a go.

That's

Wojciech: So first I already mentioned
earlier is that if you do heralded

entanglement generation, you need to
make sure your photons arrive at the

midpoint station at the same time.

They really have to be
there at the same time.

The whole process relies on the photons.

basically being indistinguishable and
that means arriving at the same time

and that requires a lot of precision
between any pair of neighboring nodes

and the precision that's used in the lab
is often, that's often quoted to me as

nanosecond level, sub nanosecond precision
with like nanosecond level jitter.

That's the level of precision
you need at the physical layer.

Then, as you go to the higher
layers, you still need timing

precision, but it's not as strict.

I've mentioned the
scheduling across the nodes.

And then, effectively, you do want
some precision, because the more

precise you are, the more Closer your
entanglement, you can schedule your

entanglement generation to each other.

At the moment we don't have, I don't
really have an order of magnitude

that we use, but I would go and
say probably microsecond level.

You want that, a microsecond level
precision across all the nodes.

You could probably do away with worse.

But at the cost of efficiency and
then the end nodes do also need some

timing precision and for the reason
that they need to be able to react

to this entanglement to coordinate
with the schedule effectively

to execute its applications.

As soon as they get these qubits
and coordinate their actions.

And often the quantum network
applications and like quantum

computing applications require
coordination between the end nodes.

So you really got to get things.

Optimized timewise, but then the
precision is, I'm not yeah, you

do you will need some good level
of scheduling and precision.

Although I'm not going to quote
an order of magnitude here

because I just don't know.

Dan: No, that's fine,
that gives me a good view.

having a sub nanosecond accuracy
between end nodes, I think that's

easily done with existing protocols,
but the nanosecond jitter, is that

jitter on the link or is it the do
you mean the the drift of the clock?

I guess you probably mean the actual
transmission of the photon, right?

Wojciech: now that you're asking me in
more detail, I, Don't actually know.

I, like, all I know is that they,
that's what they do in the lab.

They use basically, yes, you're right.

They use conventional technology.

As far as I understand, most of what
they need is achievable with WhiteRabbit.

The WhiteRabbit protocol
running between a pair of nodes.

But beyond that, I don't really know.

I'm not really an expert on
this level of timing precision.

Yeah.

Dan: Okay, no problem.

I found something that Wojciech
doesn't know in quantum networking.

I've achieved something today.

So yeah, lots of barriers,
lots of challenges.

Lots of, lots more work
to go, I guess, is the

high level.

How confident are you in hitting the 2029?

And I know that's like asking Uh,
how long is a piece of string or uh,

those kind of questions, but based
on the progress that's being made

and the resources that are being put
in and the money that's available,

you can't overlook the fact that the
cost of this what's your gut feeling.

Wojciech: It's an ambitious goal, but it
was set with the idea that it's realistic.

So at the moment I don't, I wouldn't
say have a hundred percent guarantee.

It's like, it's going to be hit
because there's still many years to go,

Dan: I wouldn't ask that, no.

Wojciech: but I'd say the.

The quality of the partners and the
quality of the work done so far combined

do match the ambitions, I feel, and
I think it's very much an achievable

goal and it's a matter of just working
through the challenges and getting there.

There will probably be a bit of a
checkpoint, I guess, at 2026, like

midway to see how realistic that is.

And I think then the one would be.

be able to give a slightly
better estimate of whether that

goal will be achieved or not.

But at the moment, I would say,
yes it's ambitious, but realistic.

Dan: And sorry if you mentioned
this earlier on, but does the,

the goal for the 2029 include the
implementation of an application or

Wojciech: Yes.

So I mean, application,
the nodes will be simple.

So yes, the goal is to demonstrate
an application, a limited one.

It will effectively be a toy
application, but it will demonstrate

the elements of an application called
blind quantum computation, which

is the idea of executing a quantum
computation on a remote server without

that remote server knowing what that
computation is, its input or outputs.

The computation will be simple.

I believe it's going to be some kind
of rotation of a qubit and measurement.

We're not solving yet finance problems
or quantum chemistry on a remote servers,

but the hope is to eventually get there.

Dan: Oh, that's fascinating.

That's a real achievement.

If we get there when we get there
I had Harold from Inria on in a

previous episode, and we were talking
a lot about blind quantum computing.

In a very theoretical sense and here
ultimately there's a goal to do it in

the real world, which is pretty exciting.

We'll be at a very fundamental level.

Okay.

So what about other standards?

And a lot kind of industry alliances
you working and I'm familiar with

the but I think you're actually doing
something in the IRTF, aren't you?

Which is the research
part of the organization.

Wojciech: Correct.

So I co chair the quantum internet
research group that is part of the

IRTF, the internet research task force.

And so therefore as a research
group in that organization, our

goal is to foster collaboration.

So unlike the IETF, the goal
is not to develop standards.

In fact, Don't even think they have
the mandate to but instead it is

to foster research collaborations.

And as part of that, you can publish
RFCs, but they're going to be

informational or experimental RFCs.

And so that's what we do.

We try to, as a co chair together with
Rodney Van Meter, we try to foster this

collaboration by trying to organize
the occasional face to face meeting at

an IETF meeting, try to get speakers
to talk about some interesting work.

Or we actually did a lot of work
and produced an RFC on the quantum

internet which was an RFC 9340.

It was a very ambitious thing.

I started just as I joined
QuTech, there was an IETF meeting.

I was like, I'm just going to write this
RFC draft or internet draft at that time.

And I thought I'll be ambitious and then
we're going to propose an architecture,

but I very quickly learned that.

Most people in the IETF don't really
know how quantum networks work.

And so therefore proposing an architecture
is just not, cannot be a goal.

And I try and convert it into a document
that's mostly educational and informative.

And I'm very happy how it turned
out because it does really present,

is a really good introduction to
the subject for networking people.

And I do recommend it to people who
want to dive into the subject and are

well familiar with networking concepts.

Well, That's the kind of work we do.

There's now a use cases draft being
on the, but it's now being on the

track to be published as an RFC.

And there's another internet draft
being worked on, which I'm quite very

interested in because it's about the
lessons learned in the European QCI.

quantum communications infrastructure
work on QKD networks and how those

lessons can be used for building the
next generation quantum networks.

So that's currently ongoing work.

So it's not standard, but this is
the kind of research collaboration

that we hope this will foster.

Dan: Yeah, and it's nice that
it's in the public domain in a

way that the IETF works, you know.

I would like to concur with your comments
about your first paper that you managed.

When I first started reading about
quantum networking, the IETF was

somewhere that I went to because I
was familiar with quantum networks.

From the classical IT world, it's where
a lot of the original papers for a lot of

the main routing protocols for networks
are developed and hosted and so on.

So it's one of the first places I
went to, and I did find that paper and

Looking back, I realized it's quite
high level, but it was really useful to

just get that snapshot of the overview
of all the different aspects of it.

And yeah, I'm looking forward
to reading the use cases one.

I guess as a draft, I haven't
actually looked at it yet.

But I would think that's also going
to be interesting as well as this

third one that you just highlighted.

So yeah, it's good work.

Keep that up.

Does that take much of your time?

Hmm.

Wojciech: It used to.

Now it's a bit less because I feel
like it's got a momentum of its own.

I think that when I was working actively
on the draft, there was a lot of

work and every now and then it would.

Admittedly, I do try to put in, I
do put in more work for the European

meetings because especially now
that the EuroQCI projects are quite

advanced, I do try to pull in the
EuroQCI community into the IETF.

And I think that's worth the effort
because a lot of the people in

EuroQCI aren't really monitoring
or active in the IETF community.

Some are, and it's really great to see.

And I do feel like this connection
between the networking community and

the EuroQCI community could result in
something very interesting and very

productive, and I'm very keen on the
EuroQCI community sharing its lessons.

Because they're incredibly valuable
because this is actually field

deployments and real experience.

Dan: In, in terms of their lessons
learned into the public domain.

Is this the only place to look
for it, or will they also be

publishing their own Euro QCI papers

Wojciech: I imagine they'll be
publishing their own EuroQCI papers.

I imagine many of the, at least the
research organizations will definitely

be publishing academic papers.

I imagine so.

I imagine the startups involved will
be more like publishing news articles.

Some news

with their, Yeah.

white papers, news releases
with their partners.

No, at the moment, there's, at the
moment, the only activity of the EuroQCI

lessons is through this draft I mentioned.

I would hope eventually for
there to be more but it's a

bit spread out at the moment.

It's just also just to be perfectly
honest, because there is more

activity on the Quantum key
distribution standardization in other

organizations such as ITU and ETSI.

Dan: ETSI.

Yeah.

Wojciech: But that's because they
do standardization and the QIRG

as part of the IRTF by definition
does not do standardization.

So it is quite a bit of a separation
of responsibility and we actually

by design in the IRTF, the QIRG try
to avoid being QKD too QKD specific.

So when we bring in the EuroQCI
people, we do tread a bit of a line

because we don't want the topics
to be dominated by QKD discussion.

But at the same time, these
are useful lessons for the next

generation of quantum networks.

So Yeah.

So there's different places to
look for the lessons learned.

Dan: And in terms of the future
standards, I would think considering

the work that ETSI have put into the QKD
technologies that they will be looking

at as you put it, next generation quantum
networks in the future and probably

taking the stuff that's published
now and in the future through the

QIRG as a kind of core driver, right?

Are you very close to the folks inside the
ETSI organization that will be doing that?

And

just wondering how joined up it is.

Wojciech: Not at all, really not to
the extent I am aware of, really.

I think many people are aware of both
organizations and they look at both, but

there is, I tried I have communicated
like these QKD and next generation

networks are very close to each other.

Practically, they're still very
distanced in terms of their communities.

And for very practical reasons,
these quantum key distribution

networks are being deployed today.

You can actually go to
a vendor and buy them.

You can buy them from Toshiba, you
can buy them from ID Quantique, you

can buy them from Qbird.

So,

You can actually go and buy them.

and their distances and rates they have
achievable are very, are far better.

greater.

And so therefore for practical reasons
they do a lot of work and they don't

really keep that much eye on the
next generation networking, but at

the same time, depending on what
conferences one attends, one may hear

that a lot of these companies are
eyeing, are keeping an eye towards the

next generation of quantum networks.

Qbird definitely does eye, does keep
an eye on that simply because their

technology is based on MDI QKD and they
are part of the quantum internet alliance.

And admittedly, the work we're doing
in the QIRG it's only now we're

exploring this lessons learned from QCI.

So it's yet to be seen how useful
that will actually be in practice.

So I do hope, the partner contributing
to that draft is, my partner, the company

contributing to the draft is Telefonica,
who are very active in their Spanish QCI.

So I would imagine they will be
definitely using those lessons learned.

Dan: Yeah, no doubt.

And I guess the lessons learned can
come from multiple areas, right?

There's the physical implementation.

Onto it, onto the fibers, onto the
traditional network, let's say, in

terms of the, the links between nodes,
but then there's also the lessons

learned from interoperability perhaps,
or maybe, in fact, that's probably

not a fair thing to say, because I
don't think any of the QKD systems

will be interoperable with each other,

Wojciech: Not at the moment,

no.

Dan: perhaps on the access side, key
management and that type of thing.

And Do you think there'll be any
lessons learned in terms of the

actual, by the vendors, in implementing
their QKD onto the networks?

Wojciech: Yes, and I think
there are a lot of lessons.

One thing I see, and so this is a bit
of anecdotal, because there's just

to be clear, is that quantum key, QKD
devices are mostly developed by people

who come from a physics background.

They're physicists for most of
their careers, or, and they're

trying to sell networking equipment

in an industry that's been dealing with
networking equipment for several decades.

So it's not a new industry at all.

And they're hitting,
they're learning a lot.

about what it means to
do to have a network.

And so therefore, and there's a lot
of lessons they're learning from that.

I often witness just discussions between
somebody from more from a networking

background, talking to a physicist
from a QKD vendor, and it's like.

It's there's a lot of cons that
have to be conveyed both ways.

The QKD people have to explain the
physics and the security too, and how

things work to the networking people.

The networking people have to explain
well, yeah, but yeah, they learn all

that and then they have to explain it.

And then when we run networks, we want
to run them this way and not that way.

And that often violates some
of the assumptions they may

have built into their devices.

I, because a lot of these QKD vendors
are only just, starting and a lot of

these devices were only used in really
ad hoc experimental demonstrations.

So yes, there will be a lot of
lessons learned by these vendors.

A lot of these lessons are simply
how to sell networking equipment.

What does it mean to build
networking equipment?

And that's an interesting
lesson to learn on its own.

Yeah.

Yeah.

Dan: of different mindsets.

And, yeah, I guess, you know, when you
build something in the lab, or even just

testing it on, university owned fibre or,
Some kind of public sector fiber service.

and then calling that a product.

There's still a lot more that
needs, there's a service for apps.

There's the ability to work in
different network environments.

There's perhaps something around the
optics and wavelengths and so on.

Yeah, loads of things
for them to think about.

And there's such a uh,
heterogeneous internet out there

basically that, uh, Okay.

Wojciech let's go onto the, your QuIP
paper you're going all the way back to

your mention of P4 at the beginning.

I'm conscious we need to get onto
that because I did read the paper and

actually I was quite fascinated in it.

So what, why don't you describe P4
is the programming language for

the packet forwarding, right?

It's the data plane.

Tell us what you developed
in that paper and

Wojciech: Yeah.

So first, the motivation that
came about for doing this was,

came from the idea that like.

We should build SDN networks
for quantum networks.

And the motivation for SDN
networks is just very simple.

It's, it allows for
faster rate of innovation.

And at the stage we're at with
quantum networks, a faster rate

of innovation is trumps most
other arguments, in my opinion.

It's like one could argue about.

SDN has some, has criticism, but I think
the rate of innovation that enables really

is it's selling point for a technology
that's basically heavy research.

Dan: And it's a disaggregated
nature that allows that, right?

Ultimately

there's a, yeah, the systems on
the node, the potential middleware,

the controller, the different
components within the controller.

There's the

decision engine, there's the
database, there's the APIs and so on.

Yeah.

Wojciech: precisely.

And I think that's really valuable
for quantum networks and hence why

actually you can see this all QKD
vendors are following the SDN paradigm.

Everybody's doing SDN in quantum.

And so we're doing SDN also in.

QIA.

And so that was the interest
of exploring these things.

And within SDN, you've got
OpenFlow and then you've got P4.

And I got interested in P4 because I was
like, not only does it, it also allows

for something a bit more powerful than
just a control plane innovation, because

it allows also for data plane innovation.

And we also need that
for quantum networks.

We, I said, we've proposed a link
layer, proposed a network layer, but.

That's just proposed at a research level.

And already when we implement
them, things change.

Things are not implemented as
they were described in the paper.

So therefore, we need to have this ability
to explore changes to protocols, explore

new mechanisms for these protocols,
and have a good ability to share that.

And that's what I think
evaluate and share that.

And that's what I think P4 really allows.

And it allowed me to build a little SDN
network and simulate in a, in simulation.

Now what I would hope that could result
from this paper is actually quite,

Broader than this, which is in the
sense that so one of the achievements

I did in my paper was one can first
I showed that one can use P4 to

describe quantum network protocols.

The way it's enabled by P4 is because
P4 is actually pretty abstract.

It defines very little in the core
language and mostly define, and it

mostly sticks to having, you define
an abstract architecture of your

device, which is basically your API
between the device and your protocol.

And that can actually be, that's
expected to be defined by the vendor.

Now, as a researcher running things
in simulation, I'm my own vendor.

And also in QIA, I'm also my own vendor.

So I get to set my architecture file.

I get to set my API between the protocol.

And the device, and that's what allowed
P4 to be used for quantum networks.

Dan: Sorry, can I just jump in?

You're using the term QIA.

Do you mean for the, is that
Quantum Internet Alliance?

Wojciech: Yeah, sorry.

I When I say QIA, I mean
Quantum Internet Alliance.

I, it's how we pronounce it.

So

Dan: Yeah, that's the first I've heard.

First I've heard it, yeah.

So it's probably the same for others.

Wojciech: Yeah.

Okay.

Sorry.

And.

Yeah, so my hope is, so one thing
that was a result from the paper is

that one can define an architecture,
one can define a protocol against an

architecture, and then one can actually
compile that protocol and run it in

simulation with some work, and if you're
defining a new architecture, you have to

do some implementation in the simulator.

But if you're not defining any
architecture, and you're using,

say, the one I proposed in the
paper, you don't actually have to

do any simulated implementation
yourself, you just write the code.

The protocol, and then you can
go and evaluate it in simulation

because it will compile to JSON and
then JSON can be run the simulator.

Now, what I think this will enable,
first of all, is a very nice result,

which is the ability to share
protocol spec independently of the

different simulators that exist
in the quantum networking world.

And I think that'll be very valuable
on its own because I personally find

it very difficult to figure out what
the actual protocol is from reading

my own paper even, to be honest.

And it requires a bit of
digging and surfacing.

thing I do hope it will enable is
that, Hardware is very limited.

One cannot really run on
hardware very frequently.

So we need simulations to evaluate
changes to the protocol stack.

So one thing I would eventually hope
this enables is that we don't have this

yet, but one could express the network
protocol stack that we exactly have.

Running on our hardware in this P4
and then run it in simulation, because

what that could then enable is that
let's say somebody has a proposal

of how to make it better, great.

Modify the P4 spec, compile it and run it
in simulation, evaluate the difference.

And then if it works out, then
one can go and then implement that

difference in the real experiment.

In the ideal world, that would actually
be a compiler from this P4 to the hardware

implementation, but we're not there yet.

At the moment, we're using
human compilers for that.

So that's my hope.

And of course, because it's P4, it also
allows one to implement a control plane.

Because P4 allows, also at the same
time as you define the data plane

protocol, defines the interface between
the data plane and the control plane.

And so therefore one can also then
explore control planes written against

a particular data plane specification.

And so therefore that's
overall what I hope.

This paper enables is the ability to,
first of all, share protocols, share

this, have this ability to share them
independently of the simulator and have

this ability to enhance the ability,
this innovation speed and improve the

ability to translate academic proposals
into actual implementations on hardware.

Dan: Yeah, it's very nice that
you get to play with both the

data plane and the control plane.

And you basically, you can tune
the whole thing yourself in your

simulation using whichever simulator
you want underneath, right?

Providing that it's got
the right interfaces.

My question is, and I appreciate
that in that case, it's really good

for sharing because you're using
a standard nomenclature, standard

language and potentially people
can share their protocols for

testing and further development.

What's your, what are your
thoughts on the hardware side?

So if let's say a.

Over the next couple of years, you come
up with an amazing control plane protocol.

It's developed in P4 and it has certain
hooks up to, sorry, a data plane protocol,

and it has hooks up to the control plane,
perhaps, which you developed yourself.

For a hardware vendor to use that, does
that mean that they need to implement

P4 in their system, or can they reverse
engineer and put it into something else?

Wojciech: No.

So this is what I like about P4 is
that It's, you can use it to whatever

extent you really want to, and what
is key is, actually, I think I missed

really explaining this in my previous,
the previous step, which is that

this architecture file that describes
this API between the device and the

protocol is pretty key here because
Effectively, you're writing a protocol

spec against that architecture, against
a particular device architecture.

And so therefore, a vendor, if they want
to implement that protocol, they need

to have their device needs to be able to
conform to that architecture, abstract

architecture specification, primarily.

And then what they can do is then
just by hand implement the protocol

specification on their device.

So compilers are always nice, but
compilers are difficult to implement,

to be honest, and one can always You
know, one can always add a backend to

the open source compiler, but then you
also need to have a hardware that can

understand, that can actually do that.

At the moment, I would think that actually
implementing by hand would be easier,

but then you actually have a spec from
which it's much easier to implement

compared to implementing from a natural
language description of a protocol.

And so that's where I see,
admittedly, I do actually see

the process slightly inverted.

Really?

I think the better process would be if a
vendor or research group or organization

proposed said this is the devices we have.

This is their abstract
architecture, defining their

capabilities and the APIs offered.

This is the protocols we
currently run on them.

And then it would, this should
allow researchers and to explore

either completely different
protocols on that architecture.

Or changes to those protocols based on
the current spec and then evaluate them.

Dan: Thank you.

Yeah, it's a very nice paper.

You're even looking at the kind
of architectures and the different

layers of the system that are required
for manipulation at each point.

For an application endpoint,
it's different than a

repeater or a heralding node.

And you draw an analogy between the
OSI model, which I've seen multiple

times done many different ways.

I think this is probably the best way that
the physical is where you're, we've at the

beginning of this discussion we've spoken
a lot about physical layer, but then

You've got the link layer, which is about
making the entanglement generation robust,

and I guess managed and controlled.

And then the network layer
is going multi hop, right?

A bit like layer two and layer
three in classical networks.

And that kind of makes sense to me.

And that's where the P4
programming sits, right?

Um, in those two layers.

Wojciech: Yeah, precisely.

Dan: So it, that does feel
like a good fit as a network

and as a X network engineer.

But one thing about quantum is.

It behaves in ways very
different to the classical world.

Look at the algorithms
that have been developed.

Look at the, when you start looking at
quantum mechanics, you realize it behaves

very differently to the classical world.

What about the networking?

Do you think we need to think
a little bit differently?

We've, you've spoken about
the entanglement generation

and the entanglement swapping.

And that I think is a, we were
comparing that to MPLS again, right?

It's a bit of an open question,
but the thing that's a I don't

know, what do you think about that?

Do you think there's a more crazier part
of quantum networking that we haven't

really explored yet that leverages the,
I'm asking you to look in a crystal ball,

but leverages the aspects of quantum
mechanics perhaps in a different way?

Wojciech: Yes, I think there's
a lot of space for that.

So first of all, there, one does have
to have a slight mindset shift to do

quantum networking because you're no
longer, because as I've already mentioned

earlier, it's not about transmitting
data, but about distributing entanglement.

It's very different because it's not data.

Second of all, there's Two qubits always
to every entangled pairs and you've,

and you've got to keep track of them.

So now your network has to
keep track of state that's

distribute, physically distributed.

So it's, it is a mindset shift.

I think I sometimes hear it described
as if you have classical networking,

your state is physically isolated.

But logically distributed, whereas
with quantum networking, your state

is physically distributed, and then
you have to logically somehow extract

the individual state from that.

So that's a challenge.

And that is a bit of a mindset shift.

And in terms of what we could
leverage from quantum, I think

there's a lot, but it would require
a lot of advances in technology.

So I think one of the cool things
about entanglement is that once

you distribute entanglement.

You can cut the connection, the quantum
connection, at least you still need

the classical communication channels
in between and and then you can use

that resource and whilst maybe the
connection is not the most interesting

use case of it, but one of the interesting
use cases of it, I can imagine is one

can buffer a lot of entanglement ahead
of time in anticipation of demand.

So with classical
networking, you can't really.

transmit data before the demand
arises, like you need that

data to respond to the demand.

But with quantum networks, you can be
like, Oh, you want five entangled pairs?

Look at that.

I have them with a particular
other end node you already have.

And there's these concepts
also already applied to quantum

key distribution networks.

Like one can actually pre
distribute Pairs of keys.

I mean one can already do
this classically with a

quantum, but that's just an and one
can already have these keys But one

can then do that with entangled pairs
for general purpose quantum networking,

and I think that's really cool.

Dan: It is.

It is indeed.

It's a total different
way of looking at it.

So a buffer in the classical world
is just dealing with the stress

of load at that point in time.

A buffer in the quantum world is
something that you can put in your back

pocket and use it when you need it.

yeah.

And if you think, if you extrapolate
what that could mean, In terms of

needing to communicate in, obviously
there's a element of it, right?

You could both being useful to send
information without it being accessible on

the link, or even needing a link between

endpoints.

It's also that is a risk in
its own right as well, that

the entanglement does have a.

an ethereal link if you like that
doesn't it doesn't need to send any

data across but it needs to send some
if you're going to teleport you need to

send some classical bits but the fact
that there's a connection to entangled

photons or qubits outside of the network
in a very closed environment like a um

like an air gapped type environment for
a high security or military use case for

example it's going to need some different
security controls perhaps for that

Wojciech: Perhaps.

Though one always, one always
needs classical communication

to make use of entanglement.

So if that can be implemented somehow I
think actually that use case might be a

bit more limited because entanglement,
it's by its nature already secure.

I think one would have to think
about that use case a bit.

Yeah.

Dan: yeah, accessing the
class call information doesn't

help you in any way, does it?

Because it's just telling
you what the bell state is.

Wojciech: When you're doing applications
you're doing a lot more than just

comparing Bell states or doing that.

When applications very
often actually just.

Compare measurement results and
actually they have to do that in a

clever way without to compare these
results without revealing them.

Hence, likewise, quantum key distribution
has a lot of work on post, has a

lot of post processing logic where
one effectively compares a subset of

the generated bits to check if the
errors are below a certain threshold

to make sure there's no eavesdropper.

And most quantum network applications
require something of this sort.

Dan: Let's go real sci fi
now, just for a minute.

I'm thinking interplanetary
travel and needing to communicate.

You're still going to need to send
those classical bits somehow, but

they're perhaps, I know there's a
deep space optical network and those

technologies are advancing very quickly.

So maybe, there's less demand on the
classical network if you're using

entanglement as well, because you're
just sending the limited number of

bits rather than all of the encoded

Wojciech: I.

Don't actually think you will be able
to get a better bandwidth in general.

So this is an important actually
point you raised to be honest, though.

Quantum networks are not really
going to, as you already pointed out,

they're not really going to enable
you to communicate faster than light.

They're also unlikely, I think.

And in fact, maybe there is a proof.

Don't quote me on that, that
we won't have larger bandwidth.

Quantum networks are all about
adding a new functionality.

That isn't possible otherwise.

So it's not about faster or more.

It's about completely new
things you could not do before.

And that's an important mindset to
have for these quantum networks.

Dan: Yeah, that's a very good point.

Bandwidth always comes up, especially if
you're talking to the network engineers.

And this is a, how do you, how
would, do you think you would

measure that in a quantum network?

Because you have both the
consumption of entanglement and

the need to send classical bits.

It's a probably slightly more
complicated metric to, to build, which

I guess doesn't exist yet, right?

Wojciech: Oh, at the moment, the most
obvious one is the number of entangled

pairs per second one can generate.

It's because that's the fundamental unit
one uses in applications at the moment.

Dan: But then how many can you use, right?

When in a, yeah, I guess there's
throughput of the available link.

So that's how much entanglement there is.

Then there's the use
of it, the application.

Consuming X number of, thousand
entangled pairs per second or whatever.

Yeah.

Wojciech: Oh yeah, that's a good point,
because also these entangled pairs have

a quality, and the worse they are, the
more iterations of your application

you have to do to get a good result.

Dan: cool.

Okay, great.

Thanks very much, Wojciech.

Anything else you'd just
like to wrap up with?

Any other projects or milestones
or news you'd like to highlight?

Wojciech: No, thanks.

I think this is thanks for inviting
me and thanks for having this chance.

I think the only thing I'd highlight
is this is an exciting time for quantum

networks, because there's quantum network
activity in the USA, there's quantum

network activity in Europe, there's
quantum network activity also in Asia.

And so it's a very exciting time.

And I look forward to seeing real
quantum networks this decade.

Dan: Yeah, me too.

No doubt we'll be able to catch
up again, perhaps in the future

to see how things are progressing.

Yeah.

Thanks very much Wojciech.

Wojciech: yeah, thanks.

Dan: Thank you.

I'd like to take this moment to thank
you for listening to the podcast.

Quantum networking is such a broad domain
especially considering the breadth of

quantum physics and quantum computing all
as an undercurrent easily to get sucked

into So much is still in the research
realm which can make it really tough for

a curious IT guy to know where to start.

So hit subscribe or follow me on your
podcast platform and I'll do my best

to bring you more prevalent topics
in the world of quantum networking.

Spread the word.

It would really help us out.