**Session Date/Time:** 16 Mar 2026 01:00

This is the verbatim transcript for the QIRG IETF 125 session.

**Rod Van Meter:** Ah, let's see. So Oscar, if you can turn your camera off while you are not speaking, but because at the moment you show up on the big screen up here. Um but while you're there, just test your mic and make sure your mic works before we start.

**Oscar:** Eh, good morning everyone, this is Oscar and this is an audio test.

**Rod Van Meter:** Perfect. All right, now if you can turn off your camera for for the next little bit. Thanks. All right, it's now one after, so it's Hammerin' time, or Quantum Internet time or something. Um we've still got a a handful of people coming in here, so let's give people about another 30 seconds or so to get into the room and get settled. I can see people milling about in the hallway figuring out uh which room is which. All right, welcome to QIRG, the Quantum Internet Research Group meeting. I am Rod Van Meter, I am one of the co-chairs of of this meeting. Um I am in Shenzhen in person. My co-chair, however, is not. Uh Wojciech, say hi.

**Wojciech Kozlowski:** Hi everybody. I’m I'm Wojciech, the other co-chair.

**Rod Van Meter:** Yes, so so we have a pair. Um all right, so let's get started. Let me run through the chair's slides here. So first off, uh the this is Monday morning so it behooves all of us to to go through these standard slides um very carefully here first thing. So first up, [note well](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-qirg-chair-slides-00#page=2) the intellectual property. The IETF follows, ah sorry, the IRTF follows IETF intellectual property rights disclosure rules. By participating in the IRTF you agree to the following processes and policies. Um and I think you can read those there, but basically um if you are holding IP on any of this stuff, it's incumbent on you to to share that, share that fact with the rest of us. So if you're aware of any IRTF contributions covered by patents or patent applications that are owned or controlled by you or your sponsor, you must disclose that or not participate in this discussion. IRTF expects you to file such IPR disclosures in a timely manner. Um IETF prefers the most liberal licensing possible and more details are available in the RFCs cited there. All right, um as always with uh IETF and IRTF, um we do make audio and video recordings. The IRTF routinely records online and in-person meetings, including audio, video, and photographs, and publishes those online. If you participate and choose not to wear a red "do not photograph" lanyard, then you consent to appear in such recordings. And if you speak at the microphone, appear on a panel, or carry out an official duty as a member of IRTF leadership, um then you consent to appearing in recordings of you at that time. If you participate online and you turn on your camera and or your microphone, then you consent to appear in such recordings. Privacy and code of conduct. This I think is especially important. As a participant in or attendee to any IRTF eh activity, you acknowledge that written, audio, video, and photographic records of meetings may be made public. Personal information that you provide will be handled in accordance with the privacy policy at the link there. And you agree to work respectfully with other participants. Um there is an ombudsteam, the ombudsteam with a link there. If you have any questions or concern about this, then don't be shy about uh contacting them if you have any concerns about anything. Um IETF, let's see, so see RFC 7154, IETF Code of Conduct and 7776, the Anti-Harassment Procedures. And especially the brand new RFC 9775 uh by Colin of the new IRTF code of conduct. All right, so the goals of the IRTF, um IRTF focuses on longer-term research issues. We are not building standards for the internet here. Um and so IRTF conducts research. Um we can publish informational or experimental documents, and we have quite a number of those to talk about today. But the primary purpose is to promote development of research collaboration and teamwork in exploring research issues related to internet protocols, applications, architecture, and technology. All right, um as always this meeting is being recorded. Make sure you have signed in to the MeetEcho system or the Data Tracker system to record your presence here today. Keep your audio and mic off if you're not if you're not actually speaking. Excuse me. Um and here's uh a view of where you can find some of the tools if you need them. All right, so [today](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-qirg-chair-slides-00#page=7), eh we actually have a a lighter agenda than usual, but we have a lot of actual group documents to look at. And so the the agenda here is set up currently as follows, but the eh we can afford to be a little bit more lax on the time this time compared to last meeting when we had a ridiculously full agenda and had to and had to cut off some interesting discussion at a couple of points. We're already a little over the five minutes allotted for adminis-trivia, but the first issue eh up after that is going to be Diego's current draft um and then after that the new draft by Oscar and then the new draft by Michal, which will actually be presented by Mone, and then a presentation by Ammar on multiverse. So eh [document status](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-qirg-chair-slides-00#page=8), we have published eh two RFCs, we have one eh internet draft that has been adopted by the RG, and we have four active eh individual drafts. Actually I think we now have five as of about 10 minutes ago. [The status of the current active ones](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-qirg-chair-slides-00#page=9) um Diego Lopez is the first author of a multiplane architecture proposal for the Quantum Internet. It was adopted by RG, eh by the RG, by QIRG following the Montreal meeting. We'll have a presentation on that today, it's coming up in a in a moment. Um draft by the the University of Pennsylvania team, Quantum FWM Control Protocol for Optical Environments. The document itself has not been updated since October and so the current draft is scheduled to expire in May. Um I did actually exchange mail with the with the authors yesterday. They say they are actively working both on the system and eh on the document and they expect to actually update the internet draft. They have no presentation today. Um Vander Venter eh RFC 9583, Clock Sync is not a valid Quantum Internet Application. This eh appeared in the Data Tracker at the end of January, and so the I-, so it's a very active draft. It has been discussed on the mailing list, this will be the first time it will be presented in front of the group here today, so um by all means um listen and contribute to that conversation. Then uh the Angela Sara Cacciapuoti and Marcello Caleffi have the Quantum Native Architecture Tenets and Philosophy for the Quantum Internet, which is also due to expire in May. It has not been updated yet, but they have promised an update to the document um coming soon and expect to appear in person at IETF 126 in Vienna, but they're not with us today, so no presentation today. And then eh lastly, draft-hajdusek-qirg-timing-physics, Timing Regimes in Quantum Networks and their Physical Underpinnings, presentation today by Mone Tokuyama. And I think that's it. So um any eh any comments or questions on the agenda before we go move into the presentations? If not, anybody who's not who has not signed into the Data Tracker yet, please do so. And eh other than that, Diego, you are up next. Here we go. Let's see. Hang on, I've gotta hand the control to the clicker. Fast control to the clicker. Does it work anyway? I mean those of you from away- uh doesn't seem like the mic's on. Yes. Now yes.

**Diego R. Lopez:** Okay, this is a an update on [the draft](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-draft-irtf-qirg-qi-multiplane-arch-a-multiplane-architecture-proposal-for-the-quantum-internet-00) that we made some time ago and started to work some time ago on this multiplane architecture and that eh well was recently adopted like some some discussions, uh well it was a almost a whole day discussion on on details and then we we have been trying to to improve and although not everything that was that we was expecting to have ready by the moment when we met in Montreal is has been completed, it's it's some sort of ongoing work. Um first of all is why we're talking about an architecture framework and this is something that let me insist on something that is basic here is that we're not talking only about or not talking about the the architecture of quantum of the Quantum Internet, but about how we can build a quantum-enabled internet. This is how we connect what we're what we're building right now or what we're discussing here, the different pieces and how we can provide eh a framework that can be used for referencing and for reference to validate the different proposals and to play with them and how this integration with existing internet is going to happen. This is something that well in the introductory part of the of the draft is discussed in detail, it’s about the the idea that having a separate classical internet and a separate quantum internet doesn't make that much sense and that we should be talking more about eh quantum-enabled internet in the idea with the idea that you will the same way that you have optical enable internet that is and you can use copper and fiber etc. the idea is that you could use quantum mechanisms whenever is required and for sure for the clear quantum cases but then there is a lot of probably, I don't know how to call it, edge or fringe uh cases that are would be equally important and it's important that we are able to share this. One of the things that we insist very much is about precisely this coexistence or transparency of the Quantum Internet with related to the with relation to the existing one. The eh the idea is let and is something that I insist very much is not that we are proposing a particular set of protocols or we're proposing a particular set of architectural concepts, it's about how we define the framework in which you can play with them and with the different interactions. We are trying to to leverage basically SDN, which has been the mechanism for controlling and defining network services in the last 10-15 years. And eh well, try to leverage to some extent the previous experience we have have with QKD interfaces infrastructures. It's true it's a very very it's a corner case, is very focused on on a particular thing, but it's the first case in which we have been experimenting the experiencing this integration between the existing network services and the coming network services coming from the from the quantum research. Um so as Rod said, yes we went for an adoption call just after Montreal, has been adopted, so now we change name, there was my name there somewhere in the in the string naming the the draft. And now what we have is something that is the first the 00 version once adopted is exactly the same and let me insist we're talking about this framework for reasoning about how the interaction between the current internet and the future quantum aware or quantum enabled internet would be. The document has been reshaped basically part of the adoption call and the discussion we have for the adoption call was very much related about the about basic concepts that needed to be improved and and we have been talking about this and and how these these base concepts should be reshaped and avoid something that was a well perception that there was too much emphasis on QKD. We wanted to justify this and well look, this is the story of how we started working with the QKD, how QKD started to be applied and helped us in understanding certain design patterns, but it was well apparently the impression that we were giving and probably it was right it was no, we invented QKD is the base of everything and we're going to put this on top. It was not intended to be the case because QKD is very very specific in insist in certain aspects like for example the quantum forwarding issue. That is something that in QKD you always have an Alice, you have a Bob, you want the key to be from here to there. There is a clear directionality in that relationship when you have you have to consider a quantum network, a generalized quantum network is not the case and we we try to to avoid that. So uh the when dealing with the framework and and what the framework is is this conceptual reference system, we have uh tried to make a much more stronger emphasis on that we are considering regarding SDN principles, virtualization principles, how this can be applied, how we can generalize this from the current classical network practice to the to the future Quantum Internet practice. And uh talking about uh refinement, well we got a number of comments, some of them very much detailed and uh we tried to to address them. One is that the the document deals with three main principles and and one of those principles is about transparency, this idea that you can interact. The availability of a Quantum Internet should not impact the existing one and should be something that is an enabler for the for network services. We are we were noted that coexistence was a much better way of terming them so what we have is combined them. Forwarding as I said, we decided after some discussion to forget about the idea of forwarding and the idea that this is about that we're talking about distribution and we're talking about quantum distribution all over the context of the document, reinforcing the idea that we're talking about shared state on the one hand and supporting the multipart mechanism eh implicitly assuming that eh well implicitly and explicitly assuming that there will be multipart entanglement. So directionality, at the end you have directionality always, you have someone that that is initiating or is willing to initiate the communication and someone that is eh well someone or some ones that are going to be incorporated to the to the communication. So the directionality now is only limited to who is starting the control actions, who is going to say I want to start this this communication. And we have refined as well the concept of eh of service units. When talking about service units, think think about and this is something that is discussed in the paper is about the same concept that is eh is an end-to-end relationship that is providing the service. It's very equivalent than a transport flow in the current internet. It's what is defined by having a IP address and a port and a at this IP address and a port at the other at the other end and then you the network guarantees that there is this mutual relationship by the two endpoints is there. We're talking about when talking about service units, we're talking about precisely those, if you want to call them quantum flows, but we're trying to use a very neutral term precisely because it's not a flow, it's not directional etc. And and when we are trying to, the original concepts around service units were directional and were by including some eh a pair relationship, we are trying to generalize it so it considers the multipart and the non-directionality and we start considering as well all the challenges regarding the aggregation. How you aggregate when you have pairs is reasonably easy to conceive how you aggregate addressing and how you aggregate mechanisms when you have many at the same time, it’s something that is a little bit more complicated. And then we have added as well some link so so some ongoing standard activities so the document provides some uh more useful references. So since the the idea of this is providing as I said a framework in which we can play uh and validate concepts, compare concepts and try to see whether those concepts are compatible. With this in mind we are we have decided to uh well to start the exercise with this list. You have this eh this draft from Marcello and Sara which is on the quantum native architecture, which is very much for those of you who are familiar, Rod was telling me that he was going to wanted to run a poll on the who has read the document or not. We talk about several strata, this is the quantum fabric strata in which quantum things happen, but we consider two other strata that have their own control planes and data planes etc. and well, whatever it has to do with this quantum native architecture we believe belongs to the quantum fabric to the control and the resource planes what is traditional SDN the control plane and the data plane. And well they propose entanglement service providers and entanglement data controllers etc. The idea is to see how they fit there and how they how they define the interaction with the other strata, with the service strata that is the one that connects with the applications outside and with the what we call the and with what we call the connectivity stratum that is the how you deal with the physical stuff that you have to prepare. Then very recently this eh this draft from Michal, Michal it is the way, from Michal appeared, which is has been quite quite interesting, we have been discussing about how this fits because all the physical measure that are analyzed there and all the timing implications are quite interesting, they are very much related to something that is for sure it’s a resource plane inside the quantum strata and how you are going how would how we deal with telemetry at the at the quantum fabric. What is what makes sense to be metered in an environment if you meter make the well you somehow spoil the the whole system and how you can you can exchange them. And something that I found going into into the document in a little bit more of detail, there are some things that are have a connection, a clear very clear connection between what is the classic classical domain of establishing the path across the different eh optical switches and the and the optical fabric and the measurements that you want to run on the on the quantum aspect. So we have started with this and during this discussion Joaquin Chung made some comments to that reference the title was very long so I decided to use the archive eh link in which they it came from the from the discussion on the discussion that we had uh with him on the on the concept of service units etc. which is about this Joaquin was looking at the service units or as a some microservices and how they could be applied. This is something that can be extremely interesting if we want to go in more depth with the virtualization patterns, and how virtualization could imply could be useful in the in the quantum environment and about identifying orchestration steps. So this is something that is in our to-do list. Apart from that this very morning uh we got a new draft on an on architecture proposal that we want to include is not included here because according to the rules you have to reference what exists. And sometime ago I I run over this I had it open uh an analysis that is quite curious and it’s we have some plans about looking at it on on P4, the use of P4 the programmable data plane in eh in the quantum eh in a quantum environment, that is something that will be will be considering in the next period. Uh well just to finish, what we're doing? Well we are we're moving forward very much focused on this that I call the technology mapping, is about taking the pieces that we are aware of and trying to fit them and see whether they fit well eh how they fit inside the framework and one with the with respect to the other. In the connectivity stratum, what we're talking about, the the pure physical who establishes optical paths before you can make any quantum interaction, we are thinking about how we can define quantum or what we is there that can be used to define or explore quantum aware optical paths. On the quantum fabric stratum we are we have the essential problem of of the of the quantum addressing because well until we have something that is that looks like an address, even not I would not say even an address but something that looks like an address we would not be able to talk about routing, really. We can have intuitions, ideas but not eh very much. And what has to do when you have issues that it's not a directional environment and this multipart by nature etc. what implies when you're trying to aggregate addresses to build to build routes that are that scale etc. And on the service stratum, that's where probably is easier, uh the the most eh specific part of this draft, which is the relationship with applications and with the rest of the internet. We're we're thinking about how service unit, this idea that is the connection, the relationship between two any number of entities sharing state, how we can aggregate them, how we can parameterize them to identify them and to go for something that is as close as possible to the famous internet five-tuple of the source and destination addresses, source and destination ports and the protocol. Looking like that, probably we will be talking instead of five things, maybe we're talking about 25, I don't know, but this is something that we we want to- and something that we from Montreal we we started a discussion with some people in in a couple of of universities and companies about telemetry, about how you meter, how you exchange information, how you can make this happen without destroying the whole state etc. There we had a interesting discussion on weak measurements recently on this. And what we are planning is that we have started to consider the that we could try to make some practical demonstration of what we have in mind and and show how this the framework at work etc. and why this is important um and why it can be used to derive certain certain eh certain properties and ideas and to do it eh well with the quantum with this synthetic network environment we have been working for a while that we have already used for derive some intuitions and ideas and that we plan to bring to Vienna in a few months and have something to show. Um that's all, yes that's all.

**Rod Van Meter:** All right, thanks Diego. So I neglected to say at the beginning that the the the time I gave was was including Q&A and we're running a little tight on time, but like I said, we have a sort of a loose agenda today today, so I think we can take an extra few minutes. So if you have comments or questions, please as- okay, Rod's got his hand up, so let's uh go to Rod first.

**Rod Van Meter:** So I have read the draft and the- eh wait a second- oh wait. He's at the mic and his face is on the big screen, and that's confusing. [Laughter] Rod Van Meter, speaking at the mic. Um I have read the eh document as of last week. It's nice, but it feels like there's a disconnect between the 3 layers and the 4 planes. I'm sorry, I forgot the- planes, levels, stages, there's the 3 somethings and the 4 something elses and I can't quite get them matched in my head.

**Diego R. Lopez:** Um I'll- level and stratum was the terminology we use, level- level is one plane is another one, it’s basically- it's multiplane architecture. Is the is the idea. And there is a level which- this has been- we tried to keep the vertical and the horizontal- standard terminology. But yeah, this is exactly what the feedback we need, is what are those things that are confusing. And by the way, I think it was Marcello who suggested using stratum instead of layer to not confuse with OSI or whatever other protocol layer, protocol stack layers.

**Rod Van Meter:** Yeah and I think that's good- I think that part was good. Okay.

**Wojciech Kozlowski:** Rod, let me check. I put a hand up.

**Rod Van Meter:** Yeah, Wojciech, go ahead.

**Wojciech Kozlowski:** Yeah, and I see Oscar also put it up. I put it before him. Um Diego, eh in your slide number eh 11 where you talk about the service unit and the aggregation, do you mean by that eh some eh some like some concept equivalent to to classical internet where you want multiple services or users sharing a pool of qubits? Or or what what do you mean by aggregation?

**Diego R. Lopez:** By aggregation I mean exactly what is what's happened right now when you classify or when you apply policies to classical flows, and then you- you try to address them by groups. When they are from the same source, the same subnet or they they provide the same destination etc. The equivalent the equivalent grouping in the in the context of the of of the Quantum eh services, that would be for example and all those things related with the same application or using the same the same specific resources along the way etc. The classifications you make on Top of on Top of the resources so the end is about managing the the whole bundle instead of trying to follow every qubit along the way. That's- this is this the point, how can we have a bundle identification of bundles instead of identifications of particular instances.

**Wojciech Kozlowski:** Okay, that's clear. Thank you.

**Rod Van Meter:** Oscar, you're up.

**Oscar:** Eh hello Rod, thank you and hello Diego, thank you for the interesting presentation. I have a brief question about slide 11- the telemetry and you mention weak measurements there and for me this this is super sensitive information. You say you talk you take week measurements such that you don't break the actual signal qubit. Is that correct?

**Diego R. Lopez:** That's that's the idea and it's what some researchers in in a few universities are working on. And it's true, as as I said, we have been running some initial explorations on whether we could translate and provide support to the telemetry functions with this kind of information, using this kind of information. But as I said, the main the main goal of the draft right now is how we could relate this. Is how we can how can we- what is the relationship between this telemetry telemetry functions with the with the with the overall management system and how they provide the relevant relevant metadata so you can make effective traffic traffic classification, the bundles for monitoring etc. So this is exactly part of what we want to to try and make it a more specific proof of concept by Montreal- by Vienna, sorry.

**Oscar:** Okay, very clear, it sounds challenging. I'm very much looking forward to what you have there in Vienna. Thank you.

**Rod Van Meter:** All right um with that, I think we need to move on. Um thank you Diego. Um there's still lots, you know the- I think we can have a lot more detailed discussions on this because the the the draft is getting pretty close to to to the point where where we want to start thinking about publishing it. So um Oscar, can you hear us? I saw video from you briefly.

**Oscar:** Yes, eh I can hear you and if you want I can even share my screen.

**Rod Van Meter:** Aha, here we are. Um the- so I will share the the slides from here. The- let's see. Oh well, so you're asking to share slides, um hang on. Let's see. Re-ask to share to share your slides. Click that again. Oh sorry, eh this is ask for screen share, is that correct? Yes, hang on, I'm trying to find the right button to click to make that happen. There we go. Not coming up yet, but here momentarily. Okay, drumroll. Maybe. Hopefully you can see my screen now.

**Rod Van Meter:** Okay, all right, okay we see we see your slides here in the room. Um the- you have 20 minutes including Q&A and uh let's try to keep it uh on time for this one because because we have actually managed to fiddle away some of our margin.

**Oscar:** Will do, Rod, and eh thank you and eh yeah, sorry I couldn't meet you in Shenzhen. Hello, I'm Oscar and the title of my presentation is [RFC 9583 Clock Synchronization is not a valid Quantum Internet Application](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-rfc9583-clock-sync-is-not-a-valid-quantum-internet-application-00). It's a somewhat provocative eh title, it's about quantum clock synchronization and during the past year eh my colleagues and I we have looked into a lot of eh quantum internet applications, quantum clock sync being one of them, and when we studied them we ran into some problems that we want to share with you, and the purpose of my presentation is to check whether there are other people interested in this and getting the arguments uh tuned. But anyway, let me eh get started. Eh first of all, um we need to have eh some terminology because the first place where this thing eh eh gets confused is with the terminology. So on the one hand there is so-called phase locking or frequency synchronization, and that is when you have two oscillators, you want to make sure that they run at the same frequency. And eh this is sometimes called phase locking, sometimes it's called syntonization, um but there is also the term synchronization and that eh means that eh when my clock says is it's 10 past 10, then your clock is also saying it's 10 past 10. So it's getting the hands of the clock eh synchronized and it's actually this meaning that is used in RFC 9583. So just eh eh to repeat because many people, even in the scientific literature, confuse the one with the other and confuse experiments for the one with the other. So we are talking about time synchronization and getting our- the hands of our clocks right. So the context eh that we're talking here is RFC 9583, and this is the beautiful RFC by the Quantum Internet Research Group in which quantum internet applications are described, and there are many eh applications and one of them is quantum clock synchronization. So um going into the literature eh um two ways of synchronizing eh synchronizations are eh most popular. One of them is called Einstein synchronization and that is when Alice eh sends a pulse or multiple pulses to Bob, and Bob sends pulses back. And by sending pulses up and down, eh Alice and Bob know how far in time they are away from each other and they make the presumption that the delay in one direction is identical to the delay in other eh in the other direction. And eh based on that eh assumption and they they can get their clocks eh eh right even though they are at some distance eh from each other. Then the second one is Eddington's slow clock transport protocol and this is where Alice eh eh has two clocks and she sends one clock very slowly to eh Bob, and the reason for eh sending it very slowly is that we have relativity, you all know eh Einstein more than a deca- uh more than a century eh ago. And eh because of eh special relativity if you go too eh fast your clock goes slower and we are in a domain where it matters. Well now comes the eh special one, the third one, quantum clock synchronization and again I'm using it in the same meaning as RFC 9583. And this is where we use qubits and we all know those things like entangled photon pair sources, eh Bell state measurements, quantum repeaters etc. Eh but anyway eh we have all those beautiful systems and at some point in that system we make a cut and on that cut there are qubits going from one side to the other. And eh we call the one side Alice, we call the other side Bob. So this is eh very important to understand, we are talking about sending qubits from Alice to Bob and it's unidirectional. So as we all know eh eh Quantum Internet, the establishment of entanglement has no eh direction, but between two nodes eh there is a direction because that's the direction in which you send the photons. So we are talking about photonic qubits. Moving on, and here we eh run into the fundamental issue. The fundamental issue is that photons do not carry time. So here we have eh Alice and Bob, and of course they are eh simple squares in this picture, but obviously we know that there are very difficult eh technologies on both sides. And we have a similar system with Alice and Burt, the only difference is that Burt is slightly further away from Alice than Bob. And since eh photons do not carry time, suppose if Alice managed to get eh synchronized with Bob, then Burt would also be synchronized with Bob, but a eh a little bit behind. So if Alice and Bob's clocks are eh at 12 o'clock exactly at the same time, then Burt will be lagging a bit behind. So this is a very fundamental insight. It doesn't depend on what type of Quantum Internet you have etc. and there is- I make the comparison with the law of conservation of energy. So we know that eh eh centuries ago people patented eh perpetual motion machines and none of them worked, and the reason was eh the law of conservation of energy. And of course if you know the law of conservation of energy it's very easy to debunk eh perpetual motion machines, and similarly if you know that photons don't carry time, that they're just frozen wave packets moving through space but not through time, then it's easy. However, eh if you are not allowed to use that law, then well eh debunking perpetual motion machines is actually a very hard thing because if you can't use the law of conservation of energy you need to check like okay, eh we have forces here, we have levers there, we have the hydrostatic pressure and etc. And one of the things that we learned from reading the literature on quantum clock synchronization, again the type that I just mentioned, is that there is a lot of confusion. First of all, there's confusion when you're talking about the lab time framework, the rotating time framework, and also some circular reasonings like okay, presume we have two entangled qubits, then etc. but how did you get the entangled qubits, for that you needed synchronization. What we also noticed by studying literature and eh connecting with eh experts is that there is a language confusion. We have mathematicians, we have physics physics theorists, we have experimentalists and they all use a slightly different quantum dialect, which means that things are somewhat hard to reconcile. And instance mathematicians, eh some of the work of eh the RFC eh refers to mathematical work, it's beautiful mathematics but it's not exactly modeling the physics. And getting already to my last eh slide, um that is about getting scientific consensus. That is really hard in this eh case because yeah, I've spoken with some researchers, I have to admit also in my own organization, and we have a very vested interest in attracting eh in attracting money. And the quantum clock sync is a beautiful use case and if you eh believe in it and you can inves- eh convince your investors then it will get you money because yeah it's such a beautiful use case. We contacted eh one of the original authors and okay, I'm now paraphrasing but it was yeah eh quantum is that magic, trust me, shut up and calculate. And of course if the mathe- if there are some fundamental errors in the mathematical premise then yeah um that's not really um an argument that holds, but still we haven't managed to convince the original author that there is a fundamental flaw. Um I've also spoken with quantum and relatively- relativity experts, those people eh eh- this is from a German institute, they look at what happens at qubits eh in the well classical relativity domain. So we are not talking about black holes, but we are talking about gravities that we have on earth and we are talking at speeds that we have in and around earth. And they say well there is no global time frame, so they say well the very funda- fundamental is wrong. I've spoken with several eh eh clock experts and eh they say well, we really don't care about quantum clock sync because classical clock sync Einstein synchronization is more than good enough. Um we have checked with the entanglement experimentalists who have actually achieved eh entanglement on quite a distance. As you can hear from my accent eh I'm Dutch, and in Netherlands we have done some impressive eh entanglement experiments, not myself but eh people in our neighborhood, and what you see is that they don't mention the quantum clock synchronization application at all. And then finally, um I had a sponsor eh um for the project that I was doing, then we came to this conclusion and I said well eh I want to present my conclusion at QIRG and then my sponsor said well the equivalent of why should we invest in debunking. So actually I found a different sponsor eh to at least be able to sponsor to give you this presentation. And all of these eh are paraphrased. So here is my call to action to you. Eh first of all, um we don't have scientific consensus yet. We're very sure that what I've- I'm very sure that what I've presented is correct. However, if you are referring to RFC 9585 quantum clock synchronization, do your own due diligence and don't blindly quote it. And there is some moral hazard here because yeah eh if you quote it to get investments then you have a challenge. And finally, eh please let me know if you are interested in the topic. Eh you have seen eh the internet draft and of course our eh arguments need refinement. They need to be accessible to all three categories of interested parties, that is to mathematicians, to theoretical physicists and to the experimentalists, and I really need help to improve this. And I think eh with this last slide I already eh thank you for your time and eh please let me know if you're interested.

**Rod Van Meter:** All right, thank you Oscar. Um the- I should also thank you like I- like I thanked Wojciech, I should thank you for getting up at 2:00 a.m. or 3:00 a.m. or whatever time it is eh where you are. Sorry you guys both drew the short eh short stick this time around. Um discussion from the floor, any comments or questions please? Eh Rod's raising his hand here as well. While people are considering this, and I hope we will have some comments or questions from the floor. Um while people are considering this, Oscar let me ask what the- what do you what do you want to do with this document? Um the this eh, you know IRTF is not normally the venue for new research results, and so the so the- eh if this is original research in terms of of debunking clock synchronization, what's the right venue for getting the right eh getting the right level of expertise uh on reviewing this?

**Oscar:** Hi Rod, eh your question is totally fair and if I had a sponsor that would allow me to go beyond eh QIRG, I would be very happy. So what I'm looking for right now is other people that are interested in the topic, eh that can also invest some time in getting all the arguments correct and eh it would be great if we could do a joint publication. For now eh yeah my research has stopped because I've come to this conclusion and my sponsor is no longer interes- interested in sponsoring the topic, which means that I need to do it in my spare time, maybe in my spare eh overnight time um so for the time being is getting the eh arguments correct eh updating the internet draft to get the arguments improved and obviously if I can find a scientific partner that can help with publication, I would be very happy with that.

**Rod Van Meter:** Okay, thanks. Um Diego's in the queue, Diego?

**Diego R. Lopez:** Just a couple of comments on this. First is that for sure working in a network operator, this idea of the clock synchronization has been extremely appealing and this is one in our top eh top use cases or or well or the or the lowest hanging fruit that we want to consider in the light of eh of your document. This is something that we have started to talk and discuss. I would say that probably we have a draft, is a draft or is an RFC on on use cases? Probably updating that, probably with a part of- not necessarily the whole document, but part of it could become part of the of this document as well, eh a discussion of the feasibility of such synchronization. And when you ask for some help, well I wish I could say I am representing a strong academic partner but I can I think I can find someone that could be interested on this. Let me let me get back home and contact a couple of people because this the implications this have for example for the this eh this work that we plan to do on the quantum eh quantum location etc. is something that probably because it's based on on time as well and this is something that we have to analyze.

**Oscar:** Thank you Diego and eh we have each other's email addresses so eh we'll keep in touch.

**Rod Van Meter:** Eh next up we have a eh someone in the queue with a Chinese name that unfortunately I can't read. So can- can- can you give us the reading for your name?

**Shenyudong:** My name is Shenyudong.

**Rod Van Meter:** Thanks.

**Shenyudong:** Okay, um I just ask a simple question. Um I'm curious about the practical implication of shared quantum entanglement. The draft argues that that establishing the unitary measurement basis without already synchronized clocks leads to circular reasoning, since the bases seem to require us to know the delay before we can measure it. So how do you how- how do you correct experimental eh demonstration actually know this delay in advance?

**Oscar:** Eh Rod, I'm not sure whether I fully understood the question, the audio is less than perfect. Eh one of the questions- one my interpretation of the question is how do you know the delay in advance? Eh Rod can you help me? Is that the correct question?

**Shenyudong:** Yeah, it's the question.

**Rod Van Meter:** Yes that- that was the eh question on the floor. So sort of I- I guess another way to to say this is partly um how do you actually bootstrap this eh system or this or this application? Is that- how do you get it started?

**Oscar:** So um let me try and answer that question, and actually this is exactly the question where things go wrong. Because in the literature that is cited in RFC eh 9583, it starts- they all start with the premise okay, we have here two eh qubits that are synchronized, or we have two groups that are eh already entangled with each other and then go from there. But the whole bootstrapping problem is exactly eh the problem. And this is where we get the circular reason- reasoning. I hope that this addresses the question?

**Shenyudong:** No, I'm not ad- address the question.

**Rod Van Meter:** So the- um the- so that's not the- not quite the question you were trying to ask? You were asking something else? We do- we do need by the way to go on, we've got about 40 seconds left.

**Shenyudong:** Okay okay, thank you for your answer.

**Rod Van Meter:** Um you can ask questions in the chat as well and hopefully Oscar can answer them in the chat. I know Oscar is paying attention to the chat tool.

**Oscar:** Yes and I will post my email address in the chat so eh please email me.

**Rod Van Meter:** All right, we got about eh 25 seconds- oh let's see, Wojciech, Wojciech's got his hand up. You- Wojciech, you've got 19 seconds.

**Wojciech Kozlowski:** Uh that should be fine because I have mostly a remark as a chair. Oscar, this is a bit of a request from me, I you call this the RFC 9583 clock synchronization, whereas I believe what you are actually referring to is a reference referenced from RFC 9583. Could I ask you to please make that clear, because otherwise you're implying that RFC 9583 is proposing some clock synchronization, and that kind of reflects on the document we have output as a group. I would request you to correct that, and maybe you can then state this is the reference used in RFC 9583, but please do not call it RFC 9583 Clock Sync.

**Oscar:** I have made note of that and eh I will call it RFC blah blah blah referenced clock sync.

**Wojciech Kozlowski:** Eh again because you're- you're kind of implying that RFC is coming- that this is coming from the RFC and it really is not. I understand that your motivation is coming from the RFC, but you're referring to a piece of academic work referenced from that RFC.

**Oscar:** Wojciech, let's take this bilaterally. I do- I think I understand what you mean, but I really want to check with you if I'm going to implement it correctly in the next version.

**Wojciech Kozlowski:** Okay, sure, let's do that.

**Oscar:** Thank you.

**Rod Van Meter:** All right, with that eh time to move on. Mone, you're up. Hang on just a sec, slide control- hang on. Um when I got booted out here I lost eh some of my control here. Hang on, here we go. Just a sec. Eh enable the clicker. All right, you should be able to use the clicker now. All right, including Q&A you have you have 20 minutes.

**Mone Tokuyama:** Okay. Um good morning everyone, my name is Mone and I will be presenting our recent internet draft that came out of our group. Um the authors are Michal Hajdusek and Rodney Van Meter. Michal couldn't make it this time and Rod is sitting right there. Okay, so sorry, the objective of [this ID](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-draft-hajdusek-qirg-timing-physics-00-timing-regimes-ietf125-00) is eh to be like a reference point for driving layering decisions and divisions of responsibilities when we're thinking about um quantum network architecture development. So this document itself is not proposing any new architectural um layering or anything, it's just a reference point that we want to consider. So quantum network core function, how we think about it is to distribute entanglement and to do this, it requires coordinating tasks or quantum phenomena um that span 20 orders of magnitude in time. Which looks something like this. So at the far end in the femtosecond range you might have the infrared light cycles, um in the second range you might have very slow waveplate rotations that we use to eh measure photons in different different bases or just like system drift calibration that you might do every day or maybe in a couple of hours, stuff like that. So there's different time involved um in the layering of quantum networks. So the objective again going back is to, the goals are to identify and provide a um introduction to the physical principles relating to the timing regimes that I just briefly showed you in quantum networks and to provide justification behind specific design choices discussed in eh other documents that we are developing right now. And also to serve as a reference for other quantum network specifications that may come out of our group or different groups. Um the goals again are not to provide um architectural decision making or detailed physics derivation, however there is quite a lot of physics um or equations in the document, so sorry about that. Um so um talking about the other documents um in our group, we sorry this is like a screenshot from our non-public or private repository, um which we hope to make public very soon. But we're working on some specific nodes such as um EPPSs, which are entangled photon pair sources or measurement nodes or BSA nodes, stuff like that. Um also recently or this morning actually, we just um uploaded the network architecture specification document, which is a proposal of network architecture for our group, I think you can check that out in the Data Tracker. But anyway anyway this timing regimes document is um here to serve as a core reference for all of these specific node types or different architectures when we're considering how we want to layer stuff or what we need um to consider as time. Okay, so I'm going to walk through slightly the um the summary of the timing regimes in the document. This document is structured um like starting with the most stringent timing requirements and as we progress through the document it goes to least stringent ones. Um we can categorize the timing regimes into stuff like this. So the most stringent ones are related to the quantum optical path like interference um of the photons and also like detectors related to measuring the photons, stuff like that. Um then we have the classical hardware which is like switching optical switches or measurement basis selection. And then we have software components which are just like supporting the overall network and holding it together. Okay so this is the same um image of like the spectrum that I showed you earlier, but colorcoded with eh um this categorization. So this is not necessarily like a architecture layering or anything, it's just like showing you where the timing regimes lie in like technical like is it like the physics physical part or the software part stuff like that just to give you an idea where it comes from. Um so the layering is not due to time, it's not like the shorter time or the femtoseconds to the picoseconds is like a certain range or anything, everything is just like mixed together. Um different technologies like the physical part also might be related to like the um timing regime in days but also in femtoseconds, so just to give you idea where everything lies. Okay, so for the people who have may not yet looked at the document I'm going to walk through some of the timing regimes just to introduce you. Um so the first one, the most timing stringent one is the interferometric stabilization. So as I said earlier, the core function of a quantum network is to distribute entanglement and to distribute entanglement um we would perform a protocol, in a sense, called entanglement swapping on photonic qubits. So essentially what happens here is eh um two photons coming from different nodes meet at a device called a beam splitter and at the device they the two photons get interfered. So for this interference to happen um in a such a way that the entanglement swapping protocol is successful, the photons would need to be indistinguishable. So some properties that make the photons distinguishable are the polarization of the photons, the spectro modes, temporal modes, arrival time, stuff like that. Um so you can think if the two photons which are wave packets have a different shape which is induced by the spectro amplitude functions or eh for instance the center frequency of the wave packet could be different, then you will be able to distinguish two photons from one another, which is not what we want. Also even if the shape of the wave packet is the same, if they don't arrive at the same time at the meeting point um that will give you temporal distinguishability so you can tell one from another, the early one from the late one, which is not what we want. So to put that more clearly um photons are light, they travel at a constant speed, so if they are at eh um different distances relative to the beam splitter, relative to the beam splitter, they won't arrive at the same time. So the two photons for the interference to properly happen have to arrive at the beam splitter at the same time, which will give us good visibility, which is a measure of how well the interference actually happened, and which is also related to how good or the quality of the entanglement you get as a result. So for instance, if the photons are apart like this, you're not going to have good interference, you're going to have poor visibility which leads to poor entanglement or sometimes even no entanglement at all. So to fix this what we do is we use a device called optical delay line or in our group we call it ODLs, to adjust the timing of the photons. So this device basically there is a- it's a box with a mirror inside of it that can be controlled by eh um a motor, so you can adjust the position of the mirror which eventually changes the length of your optical path. Um so when we do- when we use this for the interferometric stabilization we have to calculate the time or the needed delay for the wave packet to overlap, the time to communicate necessary information to the optical delay line device and also the time to reset the optical delay line and stuff like that. Um another one moving um moving forward also measurement basis selection. So in quantum networks sometimes you want to monitor the quality of the entanglement you have eh and we do this by performing some processes called state tomography. So what we do here is basically we measure the photons in many different bases, um how we provide that basis selection is by combining two different types of waveplates in different configurations. So what we do is we literally rotate the waveplates to change the configuration and we just keep the photons going and we just have a detector at the end and we measure them in different bases. So this rotation as you can imagine takes some time. If a human being is doing it manually it's going to take maybe seconds to minutes, if we have a machine if it's like a really expensive one maybe it could be milliseconds. I'm- I'm not sure, but usually it's probably on the order of seconds. So this also takes some time and we have to consider this. Um another one is optical switch control, which might be quite straightforward. So the two timings you might want to consider here is the switching time and the propagation time. So switching time is the time required to configure the switch from like cross to bar. Um the propagation time is the time required for the photon to actually travel across the switch. So you can imagine if the photon is still in your switch and you're like switching it around, you're going to lose that photon or something bad is going to happen, like if a train is on the tracks and you like switch the tracks midway you know something bad is going to happen. So it's like that. Um depending on the technology of the switch the time does differ, it could be like on the order of kilohertz to gigahertz, but again there is some time related to this. Okay, so finally the last part is the software tasks, I just kind of bunched them all together for the people who have read it. Um you might realize that this part is still eh um under development, we're working on it. Um so this is just all overall composed into this slide. But basically the software tasks are the overall background and control software holding together the quantum network. Um it's like the normal software processing tasks that you might be familiar with as a IETF person, but yeah. So the timing regimes here that we're considering are the pre-configured event-driven tasks, like events being like photon emission um or urgent non-synchronized critical tasks, application level tasks and background tasks. So I might- I have mentioned it slightly but the pre-configured event-driven task might be something like when on the event of a photon being emitted, we have a pre-configured FPGA or something that encodes like quantum error correction code to something or we're not quite sure, but a event that triggers something is already pre-configured in a device. Um application level could be like connection setup or near-real-time processing, post-processing or connection teardown. The background could be like link monitoring, routing table updates and also maybe just like security monitoring, stuff like that. Okay, so with that being said, that's like just the summary of the timing regimes, but the main discussion here is the future prospects for this document. I think the document is still on version 00 but we're trying to upload the um another following version of this by adding figures and changing equation formatting to make everything prettier. Um if you guys can help with the figures because we have quite a lot of pretty figures but we're not yet sure how to actually upload them, which is a problem. But anyway, um for the actual content of this document what we're thinking of is adding different types of wavepackets to the timing regime. So wavepackets um for people who are not familiar is basically photons, you can think of them as like a literal packet of a wave. Um but the shape of the packet and like the size of the packet differs by the technology that is used to emit this photon. So for instance right now we're focusing in the document you can see that we're focusing on Gaussian shaped wavepackets, but with different technologies such as ion traps or maybe neutral atoms, the shape of the photon and also the length does differ. They- they might be non-Gaussian and they could be like super long. For instance, from this paper you can see that there's like photons in like the kilometer range. Like yeah that kind of sounds weird, but please go check this paper out. Um also some discussions on expanding the or discussions on visibility, which we could eh maybe use for um when we have like a given infidelity budget of the entanglement that we want in a network, what is the maximum misalignment at the beam splitter or the wave packet overlap that can be tolerated for the budget you have for infidelity. That's like one thing we're considering. But mostly we want to think about um the accessibility of this document to the IETF community. So right now there's a lot of equations, um so I might be, you know, saying something that I do mean but like it doesn't really look like it um but yeah so we're- we want to eventually show how the physics connect to the code. So like everyone that is not necessarily in quantum might also if you are interested, you can help us out. Um any kind of contribution or feedback is appreciated. You can come talk to us during the mailing list or just up write make a pull request, an issue in the GitHub. Uh but that's pretty much it from me and maybe I can take the questions now. Thank you.

**Rod Van Meter:** All right, thanks. Uh comments, questions, eh complaints, criticisms- don't criticize. Arguments, agreements, advice. Banter, burble, bicker, brouhaha. Um let's see, so there was a- yeah, so eh as Mone mentioned, the eh the draft is still in the dash-00 stage right right now. We've been trying since Data Tracker reopened yesterday to get a dash-01 uploaded and we're using eh cramdown-rfc plus um GitHub actions and it's failing on getting the figures uh uploaded and we don't know why. So if any of you guys are experts in eh in those tools we could very much use your use your eh use your help on eh getting that resolved. Uh comments, questions? Yes, so- eh you should be able to in in the Data Tracker you should be logged in there, there- there's an icon to raise your hand. Can you raise your hand? There you go. There you go. Now go to the mic. Roman.

**Roman:** Hi. That eh that's eh that's not on. You might want to turn it on, just eh like slide it up. There's a- there's a- there's a- there's a switch on the on the top of it there, right there. Pull that toward you. All right. Thank you for the presentation. Um so maybe you mentioned it and I'm sorry if you already said it but um the evolution of timescales at the quantum level, like how do you expect it to be eh dependent on the technology used uh on the nodes composing the network? Like do you expect to provide eh recommendations that would allow to build like a software stack or a network tas- network stack independent of the technology used at the single node level or is it too ambitious?

**Mone Tokuyama:** Um I'm not quite sure if I interpreted your question right, and the author is sitting right here, but I'll try to answer that. Um so different technologies, so for instance if we're using single eh photons emitted from an SPDC source, then we have like a different size of a photon compared to like an photon emitted from an ion trap. So depending on the technology used, like even if the network overall architecture is the same, you might have different work- like literal requirements for the protocol to be um like you have to work in this timeframe rather than this timeframe, or maybe you have to have a different type of optical switch. And like everything when you are designing your actual physical network, um regarding regardless of the architecture, there might be different design choices that you will make for the specific timing requirement. So um a protocol working with SPDCs maybe it might not work with the same exact protocol with um the eh eh an eh photon emitted from an ion trap, but you might just have to adjust the time, like in that sense or just any kind of like decision requirements. You want to know how much time it is to actually specify a number of being like, okay you have to work in this regime. Um is kind of what I was thinking. Do you want to add something Rod?

**Rod Van Meter:** No, that seems fair.

**Mone Tokuyama:** Okay. It seems fair. Thank you very much, thank you for the question.

**Rod Van Meter:** Other comments, questions? Do we have someone online? I don't see any- I don't see anyone else in the queue here. Diego was gesturing as if there were someone online. Um okay. I guess I was clear enough.

**Diego R. Lopez:** Thank you.

**Mone Tokuyama:** Okay. Thank you.

**Rod Van Meter:** No, whether they're- feel more comfortable- No, what they- what I would like to see this and this as a list of eh of issues is extremely interesting. Eh would be very desirable, apart from the issue with the eh with the graphics. Probably there is always the- there is a desk there with the RFC editor people.

**Rod Van Meter:** Yeah, I may have to go ask- ask him for help.

**Diego R. Lopez:** The the ones with the chocolate, so you can- you- you get some free chocolate and get some advice as well. Um what they- it would be nice to see eh some kind of uh structure or- because I think that we here are at least mixing probably three things. One is all this this interaction with the classical stuff, that concerns me very much and that- Second is- is about the implications that you mentioned on the different technologies and that eh equal architecture would be eh affected by the technology and this could be probably eh a dedicated one. And the other one is about, and I believe that's important as well, is is about the measurement, how you mention this uh rotating plates and things like that. And those are three aspects that are very much related to that we will have to do in the future in the document it said something like eh when the ethernet specification appeared there was a very much detail, one is that part of this eh of how we are going to eh measure, how this could eh impact the future eh architectural decisions. And the third part about this, I would if you can try to structure the document in that in those eh directions would be ideal.

**Mone Tokuyama:** Yeah, thank you, that's actually a very valuable comment. Um maybe it might be a section in this document, it could almost be a different document, um possibly. But for like the aim of this document is essentially as you mentioned, like the the ethernet original specification which like it has very very specific requirements of everything, but it does refer back to another document that kind of has like the physical underpinnings of all of these like why we are making these decisions in the- in the ethernet document. So we want this timing regimes document to serve as a document like that, that's um the reference um document for like what- what the ethernet document also had. Um but yes, we'll take that comment into account. Thank you very much. No other comments?

**Rod Van Meter:** And with that, we're down to one minute, so this is a pretty good point to eh to cut it off here unless somebody else has eh something. All right, um thanks Mone.

**Mone Tokuyama:** Thank you.

**Rod Van Meter:** All right, and our last presentation, actually, is eh Ammar. Ammar, can you turn on your- eh the- aha, good. I forgot to have you check your audio and video before- before we started, so I'm glad that's- working. Um do you want me to run the- slides from here?

**Ammar:** Uh can I change the slides from here or?

**Rod Van Meter:** Yes, you can request to actually share your screen. Let's see. Grant permission. All right, you should have permission. Not popping up. Try again from your side. From our side it says that you have you have permission. There we go. Now we see your full browser. Click into slideshow mode, and that looks good.

**Ammar:** Yeah, you should see the full screen now?

**Rod Van Meter:** Yes, it's full screen now. The- all right, you have 20 minutes including Q&A.

**Ammar:** Okay. Hello everyone, I am Ammar with eh NIST eh and eh this presentation is about [Multiverse](https://datatracker.ietf.org/meeting/125/materials/slides-125-qirg-multiverse-a-simulator-for-quantum-networks-architectures-00), eh our new simulator for quantum network architectures, which is a joint work with Korea University. Um yeah, so why do we need eh another simulator eh to start? Eh so research on quantum networking is becoming more and more complex and so today we we are not only studying eh entanglement distribution like as isolated process or optimizing eh one problem in in isolation but eh studies are going into more eh like studying more complete network behavior including eh different routing paradigms or different rout- different routing assumptions eh swapping and purification optimizations, eh different multiplexing or memory management, eh classical delay eh are also considered more realistically than just eh perfect classical delay. Eh of course different timing eh modes are ex- are explored and heterogeneous hardware also, and even the control and management of the network itself. And we are seeing more and more of of these or like two or more of these aspects eh integrated together and and studied together. So eh these these aspects interact together and eh to evaluate these interactions we we eh we eh we think there is eh need for a joint evaluation eh of all these aspects in a single simula- simulation environment which takes us actually into eh like a full network behavior. And with many existing simulators that we are all using, eh it's difficult to study these eh like all these processes together in a single network, especially when it's a large network because they mainly use eh photon level simulation, or they simulate photon level events and eh in combination with full state quantum state representation or state vectors, which can which be- which are conceptually already far from the the network behavior eh as a like fully functional network. So what we want instead eh with with this is the ability to study entanglement distribution with all these processes involved eh as a network system close to or as close as possible to what we eh we see in in classical networks. So that's what we try to address or what we try to provide with eh with Multiverse. And eh so the goal is to provide the flexible simulation environment for quantum networking and eh so just to give an idea this is a snapshot of the one of the examples of the eh how simulation is is defined. And you can see in addition to the to the quantum specific eh parameters like memory eh models and and noise models and topology of course eh we we eh we eh we try to or we want also to be able to configure eh networking aspects like the routing paradigm itself, like identify routing paradigms or routing models, eh submit or or customize routing algorithms, eh select swapping policies, multiplexing strategies and eh also timing models, at least eh synchronous and asynchronous operation of the network and of course customize the memory management or qubit selection or qubit eh management for the for the network all as a like viewed at the network level. And eh so for this there are two main challenges at least that eh we can cover today in in this in this presentation. The first one is as I said photon level simulation eh which combined with with density matrix and eh state vector representation is eh like is very slow when we want to simulate eh large network and complex network. And the second challenge is eh of course the the eh in this field the lack of technology maturity and eh the lack of uniformity in the processes or the protocols or standards, which is fine, it's not- it's not an eh an issue on itself and it's the purpose of eh of groups like QIRG. So it's fine but it's still eh a challenge when we want to eh want to come up with a design that that provides this kind of abstraction for network. Eh so eh that's what we eh we try to eh we try to eh propose with this simulator. Yeah so given these challenges we start with eh simple design principles. The first one is eh architecture agnostic design, so the simulator doesn't assume a specific quantum network architecture because it's it's meant for exploring these architectures. The second one is protocol stack agnostic also, so eh we don't adopt or enforce a specific layered model and eh we may not even require a layered view of the of the of the architecture or of the network. And instead we we eh we try to identify and define network functions that can be combined and customized to eh into different architectures. Eh yeah, and the third principle which we also try to enforce is the is the realistic abstraction and use only realistic abstractions, eh unlike many simulators that we that we use, we try to avoid abstractions that don't correspond to real network components, either phi- hardware or software components. And instead we so the simulator models the interaction between nodes and coordination. So eh these design principles what what they what they eh allow us, so they they allow the simulator to support different types of networks eh that we can eh identify or that we can easily eh yeah think think of from the different literature from different research, from centralized control to distributed protocols, reactive or proactive routing, eh connection connectionless and eh and so on. The eh so yeah, as I said for the the network functions eh these network functions reflect eh common components that are eh found in in the literature, in the research, like entanglement generation eh which I I put here link layer just as an en- an anchor, but it doesn't mean that it's eh specifically link layer component, but in every network architecture or entanglement routing eh study there is always the EPR generation for example between two nodes, if it's in the case of eh of EPR. Eh there is also forwarder or maybe another term would be more appropriate, but there is this entity that makes decision decisions based on eh routing instructions to provide the end-to-end entanglement. There is a memory and its management and then of course purification and swapping and there may be other of course eh functions depending on the the hardware technology and the type of networks. Eh yeah, so for the the abstractions we avoid for example the eh eh entities like global resource manager or or centralized scheduler for all nodes because they eh usually don't exist in real networks eh and they they may produce unrealistic expectations eh regarding some eh design or some protocol eh where when it comes when we come to eh like a real implementation or a more realistic implementation then we may find there is eh some overhead and some coordination that's needed. Um yeah, so one important eh design choice eh in the simulator to make it like to make it faster and eh and eh and more flexible is the is the modeling of entanglement generation. So eh if we simulate every photon attempt in in the simulator then the simulations will quickly become very slow and eh so they become slow when the network grows. So instead we use analytical models for the physical and entanglement generation and in these models the simulation time can skip ahead directly to the successful event based on the eh probability of success and the the the time duration. So this preserves the correctness eh of the behavior to some abstraction of course, eh and I will I will show that in next slide. Eh yeah, preserves the some correctness without needing to eh simulate every individual attempt, which save us some some time and makes it more scalable as we we see in the figure compared to eh a simulator that uses single photon eh or photon level simulation. Eh so yeah for abstractions eh still in the entanglement generation modeling eh so we we eh we use abstractions like Werner states and Bell diagonal state eh fidelity, we eh it can be either predefined initial fidelity for the pairs that are generated or the simulator has also eh a small calibration simulation that's run that's run once to estimate the fidelity of the link and then it's reused for the other eh the other eh pairs generated. And for this there is an event scheduler that's responsible for eh for the physics. So eh yeah, we use a scheduler only in in these in this case, which is for the quantum phenomena that don't need to be coordinated classically, so they they happen naturally, so eh that's the only aspects where we try to keep the some kind of scheduling of events. And eh yeah, so we validated this with eh at small scale for now, eh yeah, so we validated it against models and and eh and eh and simulation for single link and eh and one repeater chain. So um yeah, the an other important aspect eh that we eh we also explore for the for the simulator is the link architecture framework. Eh so we of course different physical platforms use different methods to generate entanglement from detection in midpoint to sourcing in midpoint and send-receiver with different photonic encodings and also optionally with transduction for some platforms. So we try to include this common abstraction in the in the simulator to represent these different architectures. And for for in the framework itself for each link architecture, the entanglement generation is is modeled based on the success probability of a single attempt, the duration of a single attempt, and also the the age of the qubits at the heralding time. So when the nodes are aware of the entanglement and they can start using it at the network level, there is this age of eh of qubit that depends on the link architecture and we are building eh some sort of framework to eh to provide uniform abstraction for these link architectures. And eh yeah, can also be extended to multipartite entanglement in the future. Um another important aspect eh um is the is the life cycle of the of each qubit inside the node and eh so we the simulator uses eh an eh final state machine that tracks the different states of the qubit eh from the raw and free qubit to the qubit that's consumed and released eh going from purification and swapping conditions. And this is eh where all network functions and eh and coordination happens eh through the network, from entanglement generation to swapping, purification, multiplexing, and even the routing decisions or routing eh paradigms which which eh really differ in the in the aspects of eh when entanglement or when routing decisions are installed and when they are taken with respect to when entanglement are generated and purified and swapped. So this eh unified life cycle eh so we try to coordinate everything around this. So eh in in such a way to capture eh some common eh life cycle for the a large set of architectures. Um yeah before concluding, eh yeah, I think Multiverse can support several efforts that are currently being discussed in QIRG in which we are also involved more or less. Eh for example for the the the quantum native architecture, eh it can be used to explore the the architectures including quantum addressing and eh quantum native control plane. Um it can also be helpful or useful to eh to study in the multiplane architecture, especially to explore interfaces and APIs between the the the the quantum eh data plane or forwarding eh service and control service and management functions. And finally the the the last or eh before last eh draft about timing regimes which we was just covered. Eh two directions can be eh can be envisioned here. One is to eh use the simulator to eh like or update the eh network archite- the link architecture framework eh to enforce the timing regimes identified in the in the in the draft and in the discussion to enforce it for different assumptions and different platforms. And the the other direction is from the simulator by modeling the by exploring different architectures and different routing eh paradigms also eh get results that in that can inform on the timing regimes for the the software aspects and the lo- the lower slowest aspects of these eh timing operations. And eh that's why I eh yeah that's why I wanted to introduce Multiverse here in this group. I think it can serve as an experimental platform for evaluating quantum network architectures and protocols in relationship with all these different efforts that eh that are eh yeah that are being here in the group. Eh yeah, so eh to conclude the so the simulator is openly available, eh I will share the the repo and the the main paper in the mailing list or you can reach to me. Um and so yeah mostly we have included a set of examples and we are still expanding them that show its capabilities and eh what you can customize and how you can you can play with it. So like the entry point is these examples. We have also some ongoing and eh planned ideas. One of them which we are actively working on is the support of external control and management, so you can bring your own orchest- controller or or NMS and use the simulator as a as a virtual network or virtual environment to control the to control the networking aspects or the network layer. And eh so yeah currently the these network functions interact so you have to code the eh their interaction in some sort of new component to try eh different protocol or different architecture, but maybe a dynamic composition of these functions can be interesting so we can just define specification of the architecture and then eh and then eh the composition can be made by the the the the simulator, so just an idea that we we didn't start exploring yet. And eh yeah another also aspect interesting is eh to be able to explore the quantum native control plane eh beside the classical one, so we can we can have a better understanding of the how it compares and eh yeah and what's what are the pros and cons of eh each one. Yeah, I think that's all I have for eh for this talk. Thank you.

**Rod Van Meter:** All right, the- we are actually pretty close to 20 minutes here but uh since we actually have some time we can take some eh Q&A here in here in the room or online. Winston is in the queue, Winston. You have to turn the mic on, somebody turned it off. Hello. Right. There you go. Right. Eh yeah, eh okay eh Ammar, eh thanks for the eh introduction of your simulator, it gives me a lot of eh hope hope eh towards eh trying to verify my work. So I've looked- we have looked at a lot of simulators and they they sort of eh model the entanglement setup and all that based on a fiber link. So eh the- are you looking also in sort of incorporating eh a satellite link eh as part of the eh you know your work? Because what we notice is that eh you know there are other difficulties when you deal with satellites like pointing errors, diffraction, you know photon loss over free space and all that, which at this point maybe we have not looked hard enough, we couldn't find any simulator that really looks- covers all this. And I I sort of take your point that, you know, rather than modeling or simulating every single photon setup, you use eh mathematical models, which is what we have done, we have we have a mathematical model that we're now trying to verify. So fiber, we can sort of look towards people who have done lab setups but so far we haven't found anyone that actually done a eh an experimental model of a you know a satellite link. So sorry, eh so to- to cut things short, I mean are you or has eh has your model sort of looked into a satellite entanglement setup over a satellite link yet or is it- will that- if not, will that be in the future?

**Ammar:** So yeah, so eh mostly what we we model mostly is is eh is eh is fiber links to be honest, so we always eh look at that first. But eh yeah, so since it's it's models, so we can easily eh eh extend to eh satellite to incorporate free space eh models. So but if the purpose is to validate the model through some eh like more physics simulator then probably the the it's not the right tool for that. But if the purpose is to start building something more eh evolved eh based on these links, then yes, it's eh probably through modeling it can be extended to that.

**Winston:** Yep. And then eh like are you open to like contributions or you know like to eh because like some of the simulators out there are like closed, you know we can't we can't change anything.

**Ammar:** Yeah, so it's eh yeah, it's open source. Eh yeah, I can share the the the eh the eh the link in the mailing list or there is my email in the slides if you eh reach to me.

**Rod Van Meter:** I'm sure people would be thrilled if you would share the the link to the to the source code on the QIRG mailing list. That's the eh that's the way you're going to reach the most people.

**Ammar:** Yeah, sure, I'll do that. Yeah.

**Winston:** Thanks. Thanks very much.

**Rod Van Meter:** Other comments, questions? Do we have someone online? I don't see anyone else in the queue here. Diego was gesturing as if there were someone online. Um okay. I guess I was clear enough. Ammar, can you go back to page let's see, what page was I looking at? Uh six? This one? Page six, yeah here you go. So scalability with 10 qubits channel capacity, I don't understand what the definition of channel capacity is here. What's what is that?

**Ammar:** Yeah, so eh basically it's the number of eh qubits that are on each side of a channel, of each channel. So it's 10 qubits.

**Rod Van Meter:** So this is a number of buffer memory qubits at each ateach end of the link?

**Ammar:** Yeah, so eh yeah, so it's the number of qubits or the number of entanglements that are like that can be eh generated in a short period of time, assuming some multiplexing. So it's- it's not usually it's either one or more than one. So in this case it's eh it's 10 qubits. So you use the single the same channel to generate eh to generate entanglements and store them in- in those qubits. Yeah, so it's like a buffer, yeah.

**Rod Van Meter:** Yeah, so your last bullet point on this slide, scales to hundreds of nodes where photon level simulators become impractical, that's definitely one of the big constraints, one of the big drawbacks we- we found in our simulator Quisp. The original design for it was for nodes with memory and so the expected trial rate was- was, you know, on the order of tens to hundreds of kilohertz, but we- we're now trying to actually use it to model sources that generate entangled photon pairs at- at as much as a gigahertz, and that's just- you're right, it's impractical. So we've talked about dramatically rearchitecting that to do something kind of like what you're saying here, which is rather than- rather than doing a billion events a second, you know, go ahead and multiply by the- by the expected success probability and then skip ahead to- to a- to one that's actually likely to succeed and- and not queue as many events in the event driven simulator. That should save us, you know, a couple orders of magnitude, we think. But we have not done it yet.

**Ammar:** Yeah and that's exactly- yeah and actually if- if the- there is always some model in the simulator, even if it's single photon, if it's photon level. So if- if the- suppose the simplest model you have is the- the photon loss in- in the fiber and you have this exponential probability to loss of photon. And so if you just try every time, so if you- you have an event for each photon and you just discard this event and it- it doesn't bring much accuracy, like it doesn't bring more accuracy than just use the- the model itself through some geometric distribution and- and just skip ahead to the successful event.

**Rod Van Meter:** All right, thanks. Um other comments, questions from- from the floor? Anybody? Yeah, go- can you click on the- well, all right. Go to- yeah, click on the- the raise your hand function there, if you can. There you go. All right, tell us.

**Speaker:** Test test. Okay. Thank you for the presentation. Uh maybe the- I don't know about how it works for the other simulators, so maybe this is a dumb question, but um when considering for example distributed quantum computation, um sometimes you use state teleportation, sometimes you use gate teleportation. So I think that can affect the how much, let's say, the buffer memory you have on each node. Just curious about- maybe you said it earlier and I didn't understand, sorry, but how that works in your simulator, how you can deal with changing the- the memory with time for each node.

**Ammar:** Uh so can you be more specific on the- so the- the use case at least?

**Speaker:** For example, when you use uh gate teleportation in distributed computation, as far as I understand, you can keep the same amount of memory. But when you use uh state teleportation, sometimes you will need- as far as I understand, you will need to exchange these- switch the- the- sometimes they- they differ between this link memory that you'll have available for establishing entanglement and the computation memory which you use to interact with the to actually do the computation of the quantum circuit you want to implement. And and then this can affect the- the amount of memory you have for example available for entanglement with time. So how does- how does the simulator do with- can it do with this change- this dynamic memory size?

**Rod Van Meter:** Can I try rephrasing that? So the- I think the question is, what are you doing about modeling the application's buffering of qubits and use of memory? Are you actually- are you actually modeling memory allocation as- as application level qubits move from one node to another in the network, for example?

**Ammar:** Yeah I guess- yeah, if I get the question correctly, I guess in- in our case here we- we look mostly at rate of entanglement deliveries and fidelities, so usually the entanglements are- are consumed right away. So um of course the applications will change this behavior depending on what the application needs from the entanglement. So yeah, probably it's- it's not incorporated yet in the- in the simulator, so the application has to decide on that. But in our case we just- when the- the end-to-end entanglement arrives, it's consumed and- and statistics are updated. So yeah, probably it's- it's an open question on our side of this.

**Speaker:** Okay, thank you.

**Ammar:** Yeah.

**Rod Van Meter:** All right, and with that we're well over time on- on this particular presentation. So Ammar, thank you for- for your contribution here and looking forward to learning more about your simulator and seeing it develop too. Um all right, uh that's everything that's on the agenda. Does anybody have any additional items they want to actually bring up? Any other business, the AOB portion of the- the agenda? All right, I have one thing. So uh as noted early in- in the meeting and for those of you who are on the mailing list you- you have seen, we posted the dash-00 draft of a- an architecture draft based on our architecture we are actually implementing. Um we posted that this morning, so obviously nobody has had a chance to read it. Uh I will say it's still very, very, very drafty. It's very dash-00. It's maybe more like dash-minus-one level- level of completeness. Um we're trying to capture, among other things, the requirements for- for the network. There's a whole lot of stuff that's- that's sort of in our heads that isn't written down in a bunch of places, and there are a number of design decisions that also need to go into that. Um parts of the document come from some older papers and- and theses and things like that, and parts of it have been sitting around for a while, and so the- basically none of it is up to date with Diego's draft or the other drafts that- that are out there. And so we should actually reconcile as best possible with the ideas and terminology in those, although once you get into any of the level of design decisions, I think we're likely to wind up with different choices in the design decisions. So that doesn't necessarily mean that anybody else's is wrong and ours are right, just that this is what we have decided. Um we are happy to have feedback on that as well as on the timing regimes document. Those both are just personal comments for me from- from- from our group. Um and with that, that's everything that's on the agenda for today. Wojciech, any comments about um Vienna or any- any other final- final comments on wrapping up the meeting?

**Wojciech Kozlowski:** Uh no comments on wrapping up the meeting uh but for Vienna eh yes, I do plan to attend so if there's material for a QIRG meeting eh yeah, let's do it then.

**Rod Van Meter:** Angela Sara and- and I think a couple of others have- have also said that they were- they were interested in trying to get some stuff ready in time for Vienna, so assuming that they're- they're on track for that, I think it's likely that we will have a- a QIRG meeting in Vienna. Um we may- Rod- I- I may be remote in that one because it's just bad timing in our academic calendar.

**Wojciech Kozlowski:** Yes and for some additional context um whilst in QIRG we don't do QKD, the QKD people I think are looking more broadly towards entanglement-based networking, and EuroQCI has just got the next kick in Europe, so it's a good point of connection also with the European initiatives via the QIRG. So eh I will see if I can actually pull some people from the EuroQCI community eh into our community as well and have a connection established.

**Rod Van Meter:** Ooh, that would make for a very tasty meeting in that- that would encourage me to do my best to actually get there in person, too.

**Wojciech Kozlowski:** Yeah.

**Rod Van Meter:** With that, if there's nothing else, uh I think we are done about eh seven minutes early, and uh so uh see- everybody have a- good week here in Shenzhen and we'll see you in Vienna. [Applause]