Session Date/Time: 22 Jul 2026 14:00
[00:00:04] Lixia Zhang: Hi. Nice to meet you in person. Nice
[00:00:07] Ryo Yanagida: to meet you. Good to see you. Good to see you.
[00:00:14] Dave Oran: Hello. It's 4PM. We are going to get started because we have a jam packed agenda this time with really interesting research talks the whole time. So I'm Dave Oran. I'm one of the ICNRG co chairs. Ryo Yanagida is my I guess, I'm his other co chair. I managed to get him to do most of the work to set up for the for for this session, so that's really nice. He's replaced Dirk Kutscher, has moved on to more administrative tasks. And who is in the room? Alright. So this is the ICNRG, and we are an IRTF working group. So just recall that there are intellectual property rules around participating in the IRTF, And you should be aware of those rules if you work in an environment that is cognizant of of of those things or have them yourself. We make audio and video recordings of these meetings. And in fact, we we now have transcripts that have can actually be processed by by some tools that have come along. So be aware that anything that you say do or otherwise work around will be on that recording or maybe. We have a privacy and code of conduct. If you're not familiar with it, please take a look at it. Those of you who have been part should be familiar with that. The IRTF is not the ITF. We do not do standards. We help organize various forms of the research, various parts of the research community and provide a forum for interchangeable ideas and presentation of of research work for feedback from the community. We publish informational and experimental drafts in through the normal publication process, but do not do standards. Some tips. Please, any of you who have not used their your capture to join the MeetEcho session, we track who are the participants in all sessions through that tool now. We used to use pieces of paper, believe it or not, some not that long ago, but now have those tools for maintaining the list of people who who are participating. Our administration stuff, if you need pointers to things, we the mailing list, you should join even if you don't follow it that much. And our data tracker web pages are available through the IRTF. Do we have a notetaker? We have asked for a notetaker. And if you you may not want to believe this given how tight we are on time, but we cannot proceed unless somebody puts their hand up and says, will take notes. The notes do not have to be very extensive. You don't have to write down what people are saying in their in their talks or anything like that. It's all captured. But for capturing a written form of the of some discussion questions and answers, we need a notetaker. Thank you. Ali Begen has agreed to be the notetaker. Now I owe him doubly. Alright. So here's our agenda very, very briefly. We have one, two, three, four, five, six research talks. They we'd like to keep to very close time. The most of them have twenty minutes, which means you don't have twenty minutes. You have fifteen minutes to to to talk and five minutes for for q and a. And we're gonna hold people to that because every one of these talks is fascinating, and we don't want the later people in the session to be be tough for time. In terms of the active drafts these days in in ICNRG, there are a number. I just wanna point out a couple. The the CCNX chunking draft went through last call in the in the research group. It went up to the IRSG. It got an IRSG review. There were some comments sent back. The authors have, reissued the draft with the with the changes, and it's at the moment just waiting in the queue for some administrative stuff to go back and make sure that the person who reviewed it in the IRSG is happy with those before we can move it to final publication. There's a versioning draft, which is an active RG drop moment. We're waiting for more comments on it.
[00:04:58] Tianxiang Li: We would like to get it to last
[00:04:59] Dave Oran: call sometime, hopefully, very soon, but we haven't gotten enough feedback yet to do that, and we'd like to do that. And lastly, there's a fairly important piece of technical work that has been floating around for a very long time, for how you design and implement manifests to to combine multiple individual, ICM objects into more complex structures, called Flick. I have been, sidebarring just now with the author, One of the authors. I'm actually one of the authors as well. And he has actually promised to have a draft of this reissued and out for review well before the November ITF, and we will be able to look at it then. And perhaps, finally, last call it. So with that ado, we are ready to start the presentations. And I think it's Jeremiah who is up first. Stop slides. Some of our talks are remote today. Some are in person, so we'll have a mix.
[00:06:13] Jeremiah Davis: Good afternoon where you are. This is I'm I'm Jeremiah Davis. I'm gonna be presenting ICNCION, which is a project that we're working on together at the University of Kentucky. Today, I hope, to be able to, give you an overview of ICNCION, talk about some of the motivations behind the project, give some necessary background in two non, ICN technologies that are closely, that are integral part of this, of this project, Scion and RHINE, And the, to talk about our initial design status and, hopefully, have time for a takeaway and some, questions and answers. ICN Scion connects NDN CCNX, autonomous systems. So this is for the NDN CCNX sort of family of ICN, ASs to one another via the Scion inter domain architecture. Our goal is to create a global network service that has qualities that we, find desirable in ICN interdomain attempts that or in an an ICN interdomain architecture that we haven't seen in previous attempts. We among our goals, but not limited, to these are the compatibility with the existing Internet, provider customer model and set and also the incentive model of the current Internet. We, hope that, our system will not require a global root of trust, and we have designed, the system with this in mind. And the end result is that we would like to see an architecture that's scalable and secure. A sort of nutshell overview of iCn Scion, You can see that this is a small Internet work consider consisting of two ISDs. We'll talk about what those are, but they are essentially groupings of autonomous systems. And if a consumer in a s one zero two issues an interest that can't be satisfied within a within a s one zero two. The a s's own IC and Scion components that I'll describe later in the talk determine that there's a producer advertising this prefix in a s four. The border router of a s one zero two encapsulates interest in the Scion packet, and then it's tunneled across the Scion Internet work through a s three ninety four, a s 66, and a s 95. When it reaches a s four, it's decapsulated and forwarded via the normal ICN means if the producer in in a s four is able to return a data object, it is returned initially via the ICN breadcrumb path, then encapsulated again and and, tunneled back across the Scion network. Scion and ICN are mutually beneficial. And in particular, Scion systematizes inter domain trust in a way that no previous ICN inter domain proposals have. But it also still, by default, depends on IP at the intra domain level with attendant security problems such as reflection based attacks. I c n sign, our our own, project includes producer verification as a step that precedes the advertisement of a prefix in the in the routing system. This mitigates congestion and cache poisoning, but it also opens up the, the possibility of a multi tiered service model where some customer customers may not be, producers with permanent names, but only consumers. Today, we know the how today's Internet developed, and Scion and ICN mutually enforce the, one another's ground up approach to the redesign of that global Internet work on the basis of how we actually use the Internet. Our ICNCION project will provide a proof of concept for network layer that has trust and security as its key design element that's not attacked on enhancement or feature. So what is Scion? Scion, is a secure replacement for BGP at its heart, and it originates with Adrian Perrig's group at ETH Zurich. It combines a security first approach that doesn't seek to revolutionize the provider customer ecosystem. So, inter domain packets in Scion are source routed. They, contain in the packet header the attested authenticated paths between ASs. And Scion is in real world use, in the Swiss banking system, and it's being commercially developed by Anapaya. Scion ASs or autonomous systems are organized into isolation domains or ISDs. And you can think of this as being similar to an ISP customer core except for the fact that normally an ISD doesn't involve just one ISP. It'll have multiple ISPs. The actual boundaries of an ISD typically correspond to real world trust boundaries like nation states where the contracts between the ASs can be enforced. The trust that exists within an ISD is systematized in a trusted root configuration. It includes certificate authority keys for the path attestation as well as various metadata. And within an ISD, there are certain I s ASs that are called core ASs, and the core ASs are responsible, for, beginning the, the path, beaconing, which builds paths, which I'll describe, in a moment. And they're also, responsible for connecting, to ASs and other ISDs. The, scion control plane, is shown here, and the key part of this is how pads are built. Core ASs send out beacons that propagate away from the core. They propagate down the provider customer chain. They also propagate to other, core ASs, those that are in other ISDs. And, this builds past segments, as the beacons traverse the ASs. And when an a a beacon reaches an AS, it can, make a decision as to whether or not to advertise that path segment according to policy down its own, provider chain. This process results in authenticated segments that are also oriented. So for instance, we have down segments that are down a provider customer chain such as m to r. We have core segments that are between, core ASs in the same a ISD or in separate ISDs, such as c to c to a in the first case or b to I to l in the the second example as well as up segments such as f to e to c. So when sending a packet across the Scion Internet network, remember that I said that Scion is source routed. So the pack packets carry the complete path that's made up of two of two or three of these segment types. An up segment, an optional core segment is necessary, a down segment. And there also are peering links, but I'm gonna omit this for simplicity for this illustration. So suppose in an application, an h needs to communicate, with an application in, in queue, with a server in queue perhaps. H will, query the Scion control service, which returns a set of path segments that, are known to exist between h and q. And then the application assembles a path, according to whatever its internal application heuristics are for assembling that path, and this path, is stored in the ICN packet, or or in the Scion Scion packet header rather. So in this case, we see h to g to b is the up segment, b to I to j is the core segment, and sorry. B to I to l is the core segment, and then l to p to q is the down segment. And the paths are reversible, so this can be used to send the packet back across the network. The key component of our IC and Scion key components of our IC and Scion, design are a gateway that, is responsible for name service and Scion control queries. I'll talk about the name service in just a moment. This allows for IC and applications that are unaware of Scion at all to be used in this IC and Scion, infrastructure. The next component is the RHINE name service, which is an improvement upon DNSSEC and DNS and, is associate closely associated with Scion. Scion border routers, IC and Scion border routers speak both protocols, and they're responsible for encapsulating outgoing interest in data and decapsulating incoming ICN packets. Reflexive forwarding, which I'll describe in a moment, is an enhancement at ICN that enables the gateway to set up inter domain state in the routers. And in ICNCION, before the advertisement, before advertisement in the routing system, producers prove that they can publish under a prefix in a particular trust context that is permitted by the AS. And by default, this is a DNS like namespace where prefixes are are delegated, within RINE itself. Rhine is a secure replacement for DNS and DNSSEC that we use as the name resolution service. It separates securing delegation status from securing zone data, and it allows for multiple words of trust. We use it both for prefix to I s, to AS mappings stored in a special record as well as to certify the binding between the ICN prefixes and signing keys, and this is very similar to DNSSEC plus DANE. RINE, in particular, is desirable because it addresses security holes that exist even in DNSSEC, such as the ability of a compromised parent to interfere in the operations of a delegated zone. And it leverages web PKI like CAs, as well as snapshots of the global delegation state in order to prevent, this and similar types of security problems. As I said, our system uses reflexive forwarding as a key component. Reflexive forwarding, is, as I said, an enhancement to ICN that, allows our our gateways to communicate state to the border routers, but more generally, Reflexive Forwarding allows consumers to issue special trigger interest to establish temporary forwarder state, between themselves and, some producer. And this, temporary prefix can be used by the producer to send back reflexive interest, which allows for multi, exchange hands handshakes without resorting to interest payloads, which we consider to be undesirable, or permanent advertised names from the producer. This is a, top down look. It looks like the some of the lines might have gotten messed up in the conversion to PDF, but this is a top down look at an a SCION AS. And what this is intended to show, if the if the lines were more correct, is that the the default routes are always towards the logically centralized IC and sign gateway. In a RealAS, there would be more than one node that was running the gateway, but in this case, we have them all to get together. The default routes for all unsatisfiable interests are directed towards this logically centralized IC and sign gateway, and it can determine through, the RHINE and sign control, service lookups. If there's a remote producer for the data and the inner domain path to that, AS if if, it exists, it can then, the gateway then communicates this information to the border router that's on the first hop of the Scion path, and the router encapsulates the interest if it it, and if it receives return data, it begins to advertise the name, of that, data or the prefix of that data directly so that future communications can bypass the gateway. This is a little bit more information about locating data with Ryan. I'm not gonna go through the whole thing, but the key thing to to take away is that, the division of labor, that exists between the gateway, which is responsible for name resolution and control service queries, and the border routers themselves, which simply encapsulate, decapsulate, and eventually begin to advertise the remote names. Here is a a brief, example. Say that we have a in our local AS, there's a consumer that issues a, a interest for a name that finds no match in a FIB. It's gonna be forwarded to the ICN Scion gateway. The gateway then uses the, the Rhine lookup to obtain ASs that have sources for the name prefix, actually, that really this should say name dot prefix, rather than simply name. And in this case, it finds, both a s four and a s nine, and it makes a decision based on a s policy or, some other information that it has about these two a s's and decides on a s four. Then the gateway queries the the Scion control service, or path service, and this, results in a set of segments path segments that can be assembled into path one or path two. In this case, the gateway chooses path one, and then it uses reflect the reflect reflexive forwarding enabled exchange to set up state in the border router, associating, path one with a pit entry for, that name. The border router then encapsulates the interest as a signed packet forwards it along, path one. And when the signed packet reaches the remote a s a s four, it it, it decapsulates the interest, forwards it via normal ICN means to the producer. And if the producer returns data, that data is returned back along the ICN reverse bed breadcrumb path and then tunneled back across the Scion, Internet work. When the data packet returns to the originating AS, the data packet is decapsulized. It's matched to a PIT entry and forwarded back initially to the gateway, which then, forwards it back to the original consumer. If after one of these successful interest data exchanges on a particular prefix, the border router eventually begins to advertise the avail availability of the name prefix in the ICN intra domain routing system. Today, we have the separate components of ICN Scion working in the in the fabric infrastructure for network development and testing. We're using the c four c four implementation of CCNX, though we are designing everything, in mind for future use with the NDN as well, and we're trying to make as few changes to both Scion and to and to the underlying ICN technologies as possible. But we have c four, Cyan's open source implementation, and Rine's open source implementation, running in fabric. And so now we are in active development of both the gateway and the border routers. We also have a, means in place for a connection to the SCIONLab, Scion system for it's a research, network for testing and development. Our future research includes the details of the producer verification protocol that I just barely touched on today, solving the problem of locating RINE servers without global, IP locators, ensuring that the major components of the of IC and Scion are scalable, and some details of the control space the control namespace design. Our ultimate goal is the off the shelf network layer that combines the best of both IC and Scion with improvements over the legacy BGP IP Internet. And we found that the steps towards getting there, with particularly with with mature research implementations aren't straightforward, and we welcome comments and questions. Thank you.
[00:24:15] Ryo Yanagida: Great. Does anyone have any questions? Oh, we've got a question from the chairman.
[00:24:19] Tillmann Wegmann: Hello. Yeah. My name is Tillmann Wegmann. I'm from ETH Zurich. Yeah. Nice talk. Just one question. So you're using that Internet gateway a lot. Have you thought about actually going directly to the clients? Or do we need to go through a central gateway?
[00:24:37] Jeremiah Davis: So, yes, that's a good question. So, we do think that some of the clients will be sign aware, and so this will allow them, for instance, to have, multipath capabilities, with both at the at the, at the ICN layer and the Cyan layer. But the the choice of a gateway is is, for two purposes, really. One is to allow, ICN, applications that are not aware of SION, so that are that are purely unaware of location at all. And, also, it allows, for, some, use of of IC and caching if you can have these prefixes advertised more generally from these exchanges.
[00:25:31] Tillman Seska: Okay. Thanks. Yeah.
[00:25:32] Ryo Yanagida: That makes sense.
[00:25:34] Dave Oran: Dirk, let's make these very quick because we're already talking a little bit over the allocated time.
[00:25:41] Dirk Kutscher: Dirk Kutscher, hi. This is really great, interesting work. I'm just curious. Have you made any performance measurements so far? Because I think you were introduced quite a few extra interactions. Just curious.
[00:25:52] Jeremiah Davis: Not not not yet, but this is the part of the summer work, basically.
[00:25:57] Dirk Kutscher: Okay. Thanks.
[00:25:59] Dave Oran: And, Stuart?
[00:26:02] Tianxiang Li: Stuart, just wondering if you can point me to any drafts or whatever on how you take advantage of any one way broadcast links.
[00:26:18] Dave Oran: Working with Cyan in the first
[00:26:19] Tianxiang Li: Ken, do you have any other visibility? Alright.
[00:26:21] Ken Calvert: So I are are you at you're asking about, leveraging, broadcast multicast capabilities for for the ICN part? Yes. Yes.
[00:26:30] Dave Oran: So we
[00:26:31] Ken Calvert: we don't have anything on that at this point. We're focusing on getting just point inner domain, point to point, working at this initially.
[00:26:43] Ryo Yanagida: I saw Ken had a hands up earlier, but I suspect, like, you're okay then, I guess. Yeah. Cool. Thank you.
[00:26:52] Dirk Kutscher: K.
[00:26:56] Ryo Yanagida: Alright. Next up, we have ICN-Enabled Adaptive in network competition. I hit that.
[00:27:06] Dave Oran: Tets, you you you there?
[00:27:08] Tatet: I'm good.
[00:27:09] Lixia Zhang: Oh, hi.
[00:27:10] Dave Oran: I didn't see you. You might wanna move the bike down just a little bit.
[00:27:17] Ryo Yanagida: Yeah. Oh, let me Yeah. That should
[00:27:26] Dave Oran: Give her the you give her the clicker?
[00:27:28] Ryo Yanagida: Yes. K. I did. Okay.
[00:27:32] Tatet: Hello, everyone. My name is
[00:27:34] Dave Oran: I stopped
[00:27:34] Ryo Yanagida: the time. Speak a bit louder.
[00:27:36] Tatet: A louder? Okay. Hello, everyone. My name is Tatet from NICT Japan. Today, I would like to talk about ICN enabled as update in our computation for resilience distributed AI. So let me start my presentation. So that's we know that, traditionally, AI processes are centralized processing, and we have to move all the data towards the centralized server or a cloud server for the processing because we all with all the algorithms are inside this cloud server. So federated learning, in case we already moved this problem by putting all the computation in inside the device. So it solved some of the problem, but it still have some central aggregator to aggregate this competition. And although we have, like, distributed data, so we moved to the h AI. So h AI offered the NEA source processing. So h server can process this kind of, like, complicated processing, but we still have a static server to move data to the static server. So finally, we have distributed AI. So distributed AI moved the to the data. So we can do, like, a lot of, like, automatics processing for the system processing in more distributed way. So it moved data travel to the compute towards the compute travel to the data. So, however, like, we have a still have key requirement in the distributed AI. We need communication efficient, model sharing, and real time responsiveness, and also location independent executions for the large data. And, also, we need to animate text allocation. So what makes this problem more confusing is that we have, like this day, we have a lot of AI driven application, which have much more data inputs, and we still have a lot of large scale data and also very frequent model sharing inside the network. So we need real time processing across the distributed system. So as we can see that we have a lot of, like, data from the IoT devices and also image and video streaming and text data are shared between this distributed network. And, also, we have limitations such as, like, this AI complexity makes this computation a lot more computation will be less scalable. And, also, we have server centric limitation and, also, however, like, serverless approach offer the flexible computation. However, they still need to struggle with the compute and latency sensitive application for the distributed AI workload. And finally and most importantly, computation communication bottlenecks for the frequent AI model sharing is still have a lot of, like, communication bottleneck problem. So as you can see that it's a factory learning, as I mentioned earlier, has some aggregation problem and also distributed AI system currently. We still have tight coupling with the host location. So in here, as we can see that this enterprise centric communication and computation still lacks in our processing and also excessive data movement between the host and the, like, center and the receiver. So we use in here, I I see an offer of the very flexible and, reset reuse for the computational result and coordinator free computation and AI inference aggregation can be performed. And, also, we ICN offer a multipath and multi cat pose model update and distribution. So here, starting from the I c and I, we have still we have, like, a city work on inner work computation. And as you can see, the NFNs and a function locate, model compute and trigger inner work computation and execution, and and also NF AES also offer the function placement in the dynamic placement and execution by a lightweight counter and ran on any devices. And RISE, as we can see that it it decoupled, like, invocation from the return receiver by using the tag and also node persistent, no state. And compute function networking also offer them beta based on the rise and distributed age computing where we offer. However, as we can see, like, in the current distributed AI and AI computation needs state nets statefulness because as for example, we consider some of the vertical object tracking example. If we only track the the data, we don't need the state because I for example, in the frame one, we only need to detect, for example, one person, but we need to track this person. Or maybe we predict this person will be going to through the road or maybe it crossed the Mediterranean. So we need state, and we need to track this passing. So we have to have the as resolve the AI fashion and preserve the contextual state for the depend like, dependent text as a main data. So we propose a a adaptive in a word text for execution for the low latency distributed AI. So in here, like, AI fashion can be AI fashion and in foreign text can be invoked as a in a word services, such as auto detection and anomaly analysis. And, also, we offer like, we propose two mechanism. The first one is a request to compute our DC model. It treats the intermediate output and computation as a name function. And the second is a state management, how we can track this kind of, like, AI text by using the contextual state. And intermediate reset can be version as a name object as we are currently working for the versioning draft. So we, like, we want to refer this versioning as a version tech. And, like, we propose this kind of, like, state management. So we this kind of, like, AI computation can be can be fetched from the correct version and result. So it also enable the reuse of the computation and the seamless handover without the recomputation. So as we can see, like, on the first content aware fashion execution will be happen for the data. As we can see, the request are in can request by using the interest for the text one and d one, as you can see in here, extended in here. In here, extended ICN naming ICN naming with the version v one and v two for the state function. So we can name we can use the I three I see an interest name. For example, for the vehicular object detection, we can use the vehicular vehicle text one version where by embedded the functions on the data here. So version progression by will be happened by the producer, so with the sequential counter. And, also, in the fashion execution, we have to we have the notes adapted note selection. So we compute the note that received the interest and confirm its eligibility to compute this function and this by considering the capacity score and available resources. And, also, it also minimize the communication and execution cost. And finally, we compute the note and return the data, and the return data can be cached within the network. So we don't need to compute from the draft or the from the beginning. So this computational result can be used by by and requested the version. So we can also track the old version and the new we can also track the new version. So for a more complicated case, if we can find any data or the version in the compute note, so we can also use adaptive data and coordination in here. So in the coordination phase, if as we can see, the c n one has no data for so we need to we need to get depth information coordination from the data producer so it can generate the new interest to fetch the data. So from the data producer, it get the data by getting that by getting the data result too, and it can be returned to the content, like, content computation note. And the computation note has all the text and the data by coordinating this data and function together, and then this function can be computed and executed within the network. Then the result will be returned as a new data object. And, also, it can also cache in the network. So this is the more complicated case for the missing data and a function check like, coordination within the network. So we perform various site evaluation using this PICN, open source Python ICN framework, and we use the image for the text. We use the image based project detection using the YOLO three, YOLO five, and YOLO seven model, and we use a new SAS data set for the object detection model. And so each data object has one eighty kilobyte, and we set up the communication delay for two millisecond and bandwidth for 10 megabyte per second. And we use this evolution topology with 13 node with the BA topology with including the five broadcaster, 10 data producer, three compute nodes, and 12 ICN router. And we have, like, some various reset. The first one is, like, average inference latency. So we check our proposal can offer, like, like, how we can offer the inference latency for each of the various dataset and the various model. So you lose three and five and seven, we offer our proposal can support multiple model complexity with the low latency and also low for the figure b, we have, like, low computational text execution compared to the cloud and edge. And, also, it is very competitive to the local execution. And, also, for the figure c, as we can see, as the numbers of text execution increase, we have the improve improve the inference throughput in here. So from this slide, as we can see by using ICN, we can have a latency aware text placement in the network and is very practical for the scalable and responsive distributed AI services. And next series of, like, evaluation is that the figure team showed the text and cell rate. As you can see, within the ten millisecond of the threshold, we get over 96.6 of the packet of the tax rate with the packet loss ratio ratio from zero to 20%. And also compared to the agent cloud, it's we have the highest rate. In the figure e, we can see that compute accuracy is over 99% even with the detected object is increased. And, also, we have as we can see in the last figure, the it showed the object detection on the as a successful real time object detection with a high score. And to summarize this slide, we can see that this our proposal offered a low latency, reliable detection and other complex prediction for which are mostly applicable for the safety critical applications, such as traffic monitoring and autonomous vehicle perception systems. For the last one, like, we check how packet loss and how it improved to the packet loss and availability of the data. So compared to the Cloud and Edge, we offer very low retransmission pressure on the network. And also in the Figure Edge, as you can see, that there there are various fault conditioned case, and we offer the, like, fault 5% packet loss, and we offer the very low fault like, part like, interest part leader. So this property can be retrieved from the key resilience advantage. Like, we have the state aware execution, which advise the redundant transmission and recomputation. And, also, we offer adaptive node selection. It also redirect text the upon the failure. And, also, I see an multicast forward to bypass this kind of Lucy and for detect false condition within the network. So it's all for the scalable and or the height request load in the unreliable environment within the distributed AI services. So to summarize it, we proposed the data in our test execution for the AI services, which has which require low latency intelligence and real time services. And the design proposed dynamic resolution and fashion of the named data by using ICN. And, also, we proposed a contextual state management to preserve the intermediate data and computation result using the versioning inside the name. And, also, we offer the seamless function handover, faster recovery, and efficient reuse of the PVR computations. And evaluation offer, like, low latency test coordination with a minimal inference latency and tax rate. So for the future direction, we aim to include the adaptive function placement based on the network adapt network workload and the network patterns. And, also, we we aim to include digital test scheduling using the workload patterns and network dynamics. So these will be the future work. And also, we have some publication in the and the info. So it also include verification of user that this data centric protocol. So if you are interested, please check out our paper. And that's all, and thank you very much.
[00:40:54] Ryo Yanagida: Thank you. Do we have any questions? Oh, Dave.
[00:41:01] Dave Oran: So one of the nice fun things we get out of this is the ability to cache results and and not redo computations when multiple people ask for the same thing. For this particular application, either training or inference, where do you expect to see that happening? You know, when I think about, I think every one, you know, every one of the computations is gonna be slightly different from the other ones. So do do you see opportunities in which the the we can avoid the repeat computation and actually use cached results?
[00:41:33] Tatet: I see. Like, because, like, we have, like the most obvious use case should be the vehicle detection. For example, we are there will be, like for example, in ten ten cars near the pedestrian or the traffic light, we can see the same we can have the same data object detection, and we can have the cap the capture can be captured the same scenes. So if in this kind of, like, autonomous system, if they have the same scene and they need object detection, for example, there's a 10 people near the pedestrian, for example, we have, like, the traffic light is already red, this kind of thing. So in this kind of use case, we can imagine to use this kind of, like, recondition, will not be required for the nearby car and vehicles.
[00:42:18] Dave Oran: Lovely. Thank you.
[00:42:19] Tatet: Thank you very much.
[00:42:21] Ryo Yanagida: Any other questions?
[00:42:25] Shelley: Oh, thank you.
[00:42:26] Ryo Yanagida: Can you can you make sure to add yourself to the queue so that way it's easier for the notetakers
[00:42:32] Shelley: terminal, the power, eligible computer, functions, survey, service, availability, change dramatically, or connect to is intermediates.
[00:42:44] Tatet: Yeah. So in this slide, we show the note selection in here. Maybe I think you are asking for this kind of, like, like, attempted note selection. So we have, like, compute note. For example, we have compute note one and two, then we compare this kind of, like, ultimate compute note capacity using the core score and deliver resource nearby the compute node. For example, we have roadside unit near the pedestrian or near the traffic light. If we have, like, two or three roadside unit, we share all the resources and we compute within these three, like, row side units, and we choose the ultimate node compute node that can be compute this kind of function and this kind of, like, computation.
[00:43:23] Tianxiang Li: Okay. Thank you.
[00:43:24] Tatet: Thank you.
[00:43:25] Dave Oran: Lovely. Thank you so much. Let's get the next one going.
[00:43:34] Ryo Yanagida: Just about control. Yep. There we go. Oh, yeah. I'm gonna stop slides.
[00:43:38] Dave Oran: So up next
[00:43:39] Ryo Yanagida: Thank you very much.
[00:43:40] Dave Oran: I think it's Alicia.
[00:43:48] Ryo Yanagida: Yes.
[00:43:53] Lixia Zhang: I'm ready. How do I try the slides?
[00:43:56] Dave Oran: We're gonna pass you the clicker. Just give me a minute.
[00:44:00] Ryo Yanagida: That should be you now.
[00:44:02] Dave Oran: You should have slide control, Alicia.
[00:44:04] Lixia Zhang: Okay. Great. Hi, everyone. Unfortunately, I wasn't able to make it to Vienna, so I'd like to do this talk remotely. For people who attended Indian community meeting this year back in May, you have heard the the talk of the same title. This one largely is the same, but I think I clarified some basic points. Let's let's get into it. The question is why after so many years, we revisit routing scalability question again. I remember Tony, Lee, and I co chaired routing research group. That was in the 02/2008, around that time period. So here's why. It's highly related to name the data networking. We all know routing scalability is a research challenge from day one. In the early days, in the late eighties, we worried about routing scalability. I I don't know if Bob Hendon was in the room. He actually chaired kind of a private group looking to that question in the eighties. Now in the end, ICN, we proposed to use the data names for network delivery. That's you know, it looks like it just magnified the scalability problem by authors of of magnitude. So this talk, we take a historical view on the root cause of scalability. And mostly interestingly, we noticed that there's recurring patents on those scalable solutions. So we want to extract out the the common patent and apply the license learned to the future routing and the forwarding system designs. So what's the problem? I think people who ever cared about routing know this issue. There's a direct conflict between the end systems and the network. The network wants all the IP addresses to be assigned by providers so that it has a topological meaning and can be aggregated by prefixes. On the other hand, the end users or end enterprises systems, they really want the stable identifiers of the endpoints. Everyone, I believe, has to change the providers from time to time, and yet they don't want to change addresses. Then you can see that there's a direct conflict. And that attitude is a very famous Raptor's law. Addressing can follow topology or topology can follow address and choose one. That is seemingly like a solve our problem. Is that really so? So we turn this thing as the following. I think on the left side, it's really logical identifiers. On the right side, it's a topological identifiers. Instead of declared the conflict number resolvable, we actually noticed that there's a number of solutions that has come out over that actually resolved this conflict, where it might be. I would just mention the most noticeable ones, over the history. So the very first one is really mapping tech. It's the RFC 1955. I think it's published in 1996, I believe, by Bob Hinden. And he essentially proposed this idea to say that we know that there's and identifiers, and then there's a so called locators, which is the topology based address assignment. So we resolve the conflict by my team, the identifier to a topological address at the ingress into the network. So, therefore, inside of a network, you only see the topology based addresses that will scale the routing. So that's what I indicated here. You only see the locator based address. And when you are exiting the network, the egress router gonna remove this encapsulation. So the end size always work with their desired stable addresses, and the middle always work with the topological based addresses. So everyone is happy. Now how come this a good idea never gets actually adopted? So there's challenges there. Right? So let's take a look of Lisp as a specific attempt to actually realizing the idea Bob Put into the r c nineteen fifty five. So list with locator identifier separation protocol. That's precisely the point. So what the list will propose is just now they call the EIDs RLOCs, which is topology identifier. And then they provide the making table called this dedicated database stream, maps the locator, maps the ID EID to RLOCs. And it will do exactly the same in comparison decapulation, like in Bob Hinden's RFC. But that, you know, got published at the experimental RFC in 2013 and then became a standard, actually. I didn't realize that until I checked. Standard in 2022. But look at the current deployment. I believe there are places that actually use this. But by and large, I would buy to that many people at the ITF haven't paid attention to this thing called this. Where is the hangout? That is on the DDT stuff. So you can provide this mapping system. The question is, what is the governance rule for this mapping system? Who's gonna provide this? Are we gonna do a kind of a second copy of DNS equivalent? And that is really unassolved issue. So at least I would say that nice idea, but the intrinsic barriers that stopped it from wide adoption. Now what actually get adapted to scale the routing is MPLS. People may not think of MPLS as company type, but that exactly what it is. But the ingress router into a big ISP's network, you actually map this this forwarding equal in the class, if you see into the MPLS label. So, therefore, instead of the core AS, that one AS, you really doubt on the labels. And the label, of course, are assigned by the network operators totally under their control. Is totally scalable. It's the topological identifier. And then, again, at the egress, of course, you exit the current AIs, move on to the next one, and then you go back to the original prefixes again. So you can think of MPLS as encapsulation. It's not like IP and IP encapsulation. This layer 2.5 encapsulation. Nevertheless, it achieved the exact same goal. And this picture looks exactly the same as I showed you for the original Bob Hendon proxy. Now that's about unicast. How about multicast? We all know this IP multicast forwarding approach divided by still urine back in the late eighties. Usually, there's all kind of a different realization. People are old enough with the ITF. You could recall the Mbone deployment in the mid nineties where that was the first time ITF meeting got broadcast out for the remote participants. I hate to inject the historical anecdotes into this. I remember this so clearly. My dear friends, Alison Mankin, was pregnant and couldn't have pregnant again. And therefore, she's asking, hey. We have all this audio and the video on IP now. It's the leak and the bite, And also the IP multicast. Can't we distribute I can't make things for remote participants. And that's how the iPhone actually get this started and people tried it out. I really love the idea. Ideas are lovely. The question is scalability. So at that time, you know, during this configuration inside a with the source and then the group address. Therefore, every router, generally speaking, needs to keep this pure like, as common geo state. That is per source group, high drives combination. And then you can think of how well that scales. The number of groups are now funded. Well, you may say it's a funded by the class d addresses. Yes. That's a two to the 24, but the the sender per group is still can be a very large number for large groups. And we just put a very simple explanation here to say that it's really really much worse than unicast conflict. So high multicast get deployed here than there, maybe like a list. Right? But those are very engineered solutions, you know, single source multicast and for specific domains and specific usages is like IPTV. But, fundamentally, this is giving issue. I think it can find the multicast deployment. Now since late twenty tens, I think this the BIER thing get the standardized there. I put it here, 2017. This actually took a entirely different approach to multicast forwarding. I think the people here should be aware of aware of the situation, how it works. What's new on this slides is to take a different view BIER. So for BIER, you have the the say, the ingress of the ice of the AIs. I forgot to mention that for the MPLS mapping type, the fundamental question, how the map gonna provide it if I go back. Can I go back? Can I go oh, it kinda is it? So the map is provided by I b g p. I b g p's I b g p's side side. Okay. For this exit voucher, that's all the destinations you can reach. So map is actually very important thing. Remember I mentioned that this get a a of challenges with how you provide the mapping information. And then from all the tasks, all the mapping is done. So for the BIER, instead of AS, there's also the IPGP provide the information to say that at the e each egress router was an IP address that has the membership into it. So, therefore, the ingress router will just put this bit string onto the packet. Then inside the core, again, packets are kinda forwarded based on the bit string. So you can see that, you know, it goes to the exit router. But every router, actually, the split of bit string so that packet slows down along the tree to reach individual receivers. Say this way. So, therefore, if we call it map and then in cap, where's the map? Map happens at the ingress. Where's the incap? Incap, actually, is just like a bit stream that plays the same role as the unicast encapsulation because each bit tells the router where to forward. Just like the unicast a calculation, the outer address tells the outer where to forward the package. So that's the we think it's equivalent. We call BIER. It's a multicast. Therefore, you can see the scaling issues. For the unicast that we still deal with I PGP, and that is still proportional to a number of prefixes that's out of the network's control. So IP multicast, the similar situation are getting worse because the combination gets way, way bigger. Then for MPLS, in inside of domain, they do map and. So it's there. Now we just put this in this, you know, time scale. We can see that mapping cap divide in the nineties and in the 28 2,000 those MPLS. And then later, there's a please forget the spandrelize, and then we have BIER from multicast again. The one thing I just put a note there, that is cross the domain. We still deal with the per prefixes. The reason is that although we have AIs, AIs is not a routing unit. You don't have a forwarding table to say if our AIs, say, 3336, I think that's used to be the number three, I guess, the number three IP number. You cannot count to a AS. AS merely as a, like, a logical unit that control the BGP prefix eligibility propagation as a policy onto it. And therefore, for both unicast and also multicast, correspondents, you're still dealing with address prefixes. Now the AS as unit. This is my last slides. I think we can draw three licenses. That is if you want to scale routing and forwarding, you have to make it work with the topology and not the external logical identities. You like this source specific multicast. This kind of you just have those overhead deferred to elsewhere. SSM requires configuration and limited to within specific application domains. And then using mapping type is really the right way to resolve conflict between logical and the topological identifiers so that you can scale the forwarding and the routing based on the topology and not external factors. And our observation especially pointed out is the third point that is that the micro system is a very critical ingredients in the future scalable routing the forwarding designs. As we can see that iBGP, that was part of a BGP. So it provides the mapping for the MPLS and also for their within AIs deployment. But then, like, least, and also I would add the ILNP, they will try to write American system to our existing deploy technology. And so far, we have not seen widely successful approach based on this post factor item of the making system. So that's the end of my talk.
[01:01:07] Dave Oran: Thank you. Thank you, Alicia. We we're a little short on time, so I wanna get right to the questions. Please put yourself in the queue if you have a question. I think we have Ken first in the queue.
[01:01:17] Ken Calvert: Hi, Alicia. Thanks. Nice nice talk. I I'm wondering how you feel about Scion as an instantiation of mapping and cap, which actually allows you to route to an AS on a based on AS number.
[01:01:36] Lixia Zhang: Yes. Sound. I unfortunately, I missed a little early today, so I didn't hear the full sound talk. I think of a sound, I have a different comments. So maybe it's not related to. Should should I reserve that for a later email exchange? So I don't divert
[01:01:57] Dave Oran: Sure. That's fine.
[01:01:59] Lixia Zhang: The marketing cap is a way to scale routing and forwarding.
[01:02:06] Dave Oran: Good. Roland, you're up next.
[01:02:08] Roland Bless: Yeah. Roland, hi. I just want to mention that there are actually schemes that support ID based addresses without any ID to locator mapping. So so I put a a reference to Kira into the chat, so you may have a look at that one. So it's a scalable routing scheme that only has logarithmically sized routing tables, and the prices stretch for sure, but it works without any central coordination also. Thanks.
[01:02:40] Lixia Zhang: Where is the pointer?
[01:02:42] Tianxiang Li: The chat.
[01:02:43] Lixia Zhang: In the chat. I didn't see it. I I this thing. You mean that's a k I r a?
[01:02:52] Farhat: This is
[01:02:52] Lixia Zhang: You're right.
[01:02:53] Roland Bless: Yeah. Yeah. Yeah.
[01:02:54] Lixia Zhang: If you use it then wow. Again, time to start here. I think there's a lot to say about the FCA based routing.
[01:03:02] Roland Bless: Yeah. I was
[01:03:04] Lixia Zhang: There's a paper, routing on flower laughing. It's AROLF. Do you remember that paper?
[01:03:16] Tianxiang Li: Yeah. Ruffled. Yeah. Yeah. I know. I I know. Right.
[01:03:18] Lixia Zhang: I think they yeah. Let's start conversation with that paper. But but maybe not here given the time limit.
[01:03:26] Dave Oran: Yeah. And if you wanna sort of, like, have a to get a hook hold map of the space of the approaches, whether you like it or not, hyperbolic routing is another quite scalable approach which trades off stretch against state. So, yeah, there are other things. And you may be right that mapping endcap's the only thing that has any hope of succeeding. But maybe we should understand the whole space so we can place it appropriately.
[01:03:53] Lixia Zhang: Yes. Yeah. Yeah. So, yeah, I should have mentioned that. But I think this my I got to my point. My opinion is really critical point if you want to do marketing cap. And so far, we haven't seen very successful post effect injection of a system. And that's a problem. So I I want to just say one word about NDN. NDN start from day one. We knew there's a logical what's a technological conflict. So in early days, people probably remember that we had this thing called a forwarding hint. That is an interesting carrier forwarding hint, which is a locator. And the name is still the identifier, identifies the data you want to take. But then, you know, where it's merging. In many early examples, we actually have the mapping supported in a kind of case by case situation. It's only in the late implementation. We realized that, actually, when we design the new routing protocol for Indian, this Indian gateway, this is the vector Indian routing. We realized that we should have a unified making system as a part of the the routing. So it's my last comment. Next, let's talk about that.
[01:05:16] Dave Oran: Great. Thank you. We this is great. Great discussion. Well, we need to move on because we're trying to keep the time. You're you're on. Yeah.
[01:05:31] Tianxiang Li: So I can show the slides now.
[01:05:34] Ryo Yanagida: That should be you.
[01:05:36] Tianxiang Li: Okay. Thank you. Hi, everyone. I'm Tim. And here we are presenting this the work that Leisha mentioned that is when we designed the new distant vector article, we realized that it is the right time to apply the map and encapping to Indian routing so that we can scale the whole network. We know the context well. That is, as early people mentioned, we in the end, routes out packets by names. But, obviously, we have tons of DNS name much more than the IP addresses people can have, especially when you especially the situation get much worse when you consider multicast. For example, the recent application, the called only we we just developed. If you can create an overleaf like directory so everyone everyone can collaborate on that, but how you communicate, you you must have multicast to synchronize the state, and, others need to fetch that added data you have made. So given these tons of app application names, how you scale the routing, you you cannot afford an exploded fit table. So this is the problem that we are actively facing in the end. And as Lisa has talked, this is not the that is not the in the unique problem. But scalability is long lived concern even for Internet from day one, and there's a long lived and and fire locator conflict too. And map and incap goes by ITF standards, but research work or or engineering practice, for example, MPLS. Although it didn't start with a purpose, but it end up with the the practical answer that is we provide a mapping system, and we try to encapsulate the packet with the topological identifier for both unicast and multicast. And this work is essentially a map of the incap incaps implementation for Indian itself. We try to leverage Indian unique feature. For example, as a state forwarding plane, the default data multicast is and especially security for efficient and secured mapping replication among all the topological points. And with the mapping, we can do the beer so that we can support stateless multicast, which kind of unsolved the problem for MDM for a long for a long time. So this work is essentially a scalable routing architecture for NDN. Let's say this. We directly build the mapping on the router themselves of and, of course, the routers need to synchronize on the mapping table. And for the encapsulation, we utilize the existing, let's say, layer 2.5 protocol for endians. They are current status protocol is essentially used for endian hop by hop fragmentation, but it's extensible. So we extend this LPORT_V2 protocol to support our encapsulation point for the topological identifier. And this work although we're in big, but we slow start, that is we start with intradomay routing that within one route of a domain, and the routing protocol has already established at least as router reachability, then how we do map an incap within a single routing domain. For mapping in cap at the AS level, that's actually, that's our ongoing work. So that's out of the scope of this talk. Overall, in the in the routing domain, we consider there are, of course, end applications. They register application prefixes to the client facing routers or application facing router or Azure routers, whatever you want to call. And the Azure routers, they sync they have the mapping table, and they synchronize on mapping table. And they try to when they receive a raw interest from the end applications, they will try to look at the mapping table to look at, okay, what is the topological endpoint? What's this topological point I need to route to? Then directly puts that router ID in the encapsulation layer so that the the the layer the routing in the middle, say the core routers, the gray routers in the figure, they only forward based on encapsulation header. They do not need to look at application names. At least we have a a relatively flat forwarding table in natural core. And we and we and at the at the end of the edge routers, we have the mapping table called prefix egress table, essentially decide for for a specific prefix, which is the egress charter that you need to visit to. And we also have the control plane component we call it perfect state database. Essentially, all the edge routers, they join a synchronization group and say, how many what other prefixes attached to me? And is it multicast prefix, unicast prefix? And and, also, as router lifetime announcement, we have the time to live. For example, this how many routers? Six routers to biology. We have the four at routers at the four corners, and I have two core routers. See, at the router one, we have a mapping table to say this p four is p four is available at a topological point r two and r four. Then when r one receiving this receiving the drawing interest coming from the application, it doesn't have the encapsulation header, so it need to look at dot mapping table. And mapping table says r two and r four is our destination. Then because routing protocol, the intra-domain routing protocols already established lot of rigid ability in fib. So I look at the fib and say and and and fib says R four is the closest router. So I decide so r one decide I need to encapsulate this interest with with the header R four to say so so the next router R six need to know the destination of this interest is R4. So R1 send this interest to R6. And for R6, because it already the the incoming trace already has the encapsulation tag with R four, so it doesn't need to look at the mapping table. They only need to look at a topological table to say R 4 is available at my west facing face and forward interest toward the R 4 direction. And at the egress prefix egress point, we need to do another mapping that is authority to as as the as the producer at task point, authority to also record for each prefix, what are the local phases that I need to send to. So when receiving this phase receiving this interest, this interest has to attack. And me is the, so I need to look at the table. Then it says, okay. This is the phase I want to I need to send to, and r four can egress this this prefix to the applications. And, of course, if even you don't have a running protocol, still, if you only have local forwarder, that means you don't need to look at the FIB anymore because FIB contains pure router availability. For pure applications, running a single router, say r one, you just look at the perfect egress table. And now given we have the mapping table, we can talk about how we can extend this mapping so that we can support the beer multicast. So so we the design decision we made is that we add one more one more header type to the layer two layer 2.5 incap that is the beer beer bit string. Essentially, it says essentially means when the encapsulation header carries the router ID, that means that is a unique interest. And if the interest carries the beer string, that means it is a multicast interest. And for the ingress router, when it receives the raw interest, it it needs to look at the prefix table to say if this interest is multicast or unicast. And and if it is for multicast, it need to look at, say connect. How can I go back? Yeah. For this for this case, this p three is the multicast multicast prefix, and the r one say, I need to send this interest to r two and r three, and it will construct the peer I peer peer string to r two and r three so that later r five know how to forward. So, yes, this is the example I just I just talked about. That is if a network providers, they assign the peer ID to all the peer route to all the routers, then we can with the mapping table, we can essentially build stateless multicast. We only keep the prefix application dependent state on the edge routers. After edge router look at the prefix table, internal the real internal transit router like r five, they only look at the topological dependent state, which is the beer beer table so that r five knows, okay. The second bit and third bit are set to one, so that means I need to forward to and r three and look at its own beer forwarding table to say how to forward r one r three. So the entire multicast tree becomes stateless. You don't need to maintain any application state within the network. Now the question here is how we synchronize the mapping table. Right? Because after all after all, it one can say routing itself is another piece of application, then how if you say application states are kept at the edge, how can do that? Yes. Routing itself is application, but the routing is a special application. So what we have what we have done is that all the routers, they join a synchronized group, and we assume that and because we assume that all the router, we all join the synchronization group. So the and the inter intradomay routing protocol has already established router reachability so that we can safely include all the routers. We can safely assume that all the this multicast perfect slash network slash PSD slash sync, this multicast perfect is available at all the routers that I can find in RIP. Also, for specific mapping updates, may say slash network slash TSD, which is the application prefix as a special application slash router slash a sequence number, which identifies, like, the mapping table updates. This specific application prefix is available at the specific router, which we can find in RIP so that we don't need to do extra things. All we do all we need to do is make sure that all the routers join the synchronization group so that we can we can synchronize mapping table. And we prototype this routing architecture in the go on forwarder so people can yeah. It's rather it's already readily usable so people can use our go go forwarder with this strategy. And we because as we said, the routing is merely another application, so we of course, it will be secured. So we utilize the existing Indian trust schema in force policy saying the applications have only announced perfect says that they really own, and the router can only produce its own mapping table data. You can router one cannot override the mapping date table for for router two. And, also, other, like, command line interfaces for management, you can announce manually announce the prefix, withdraw, or register the the peer router ID, things like that. For evaluation to evaluate this work, we focus on two points. That is, first, given you place a mapping table within the system and they need to synchronize that in table. So an inevitable problem is how we can make sure that it converts fast enough. It is essentially how the single protocol the speed of this convergence is essentially the sync convergence speed. We expect something just like sync convergence. And, also, because the the ultimate goal is to minimize the forwarding state within the network, so we definitely need to look at table size. And we for evaluation, we chose two representative topology. The first one is that there's no specific distinguish between the edge and the core. There's more like a more over more close to the deployment reality of Indian, which means you you deploy as overlay, and every single router is application phase so that you cannot have real core out core routers. And secondly, it's more like, in theory, you have core routers. You have real application facing routers so so you can gain the most benefit from this routing architecture.
[01:19:26] Ryo Yanagida: I would like to remind you that that we've got you've you've only got five minutes left, so I I suggest you conclude quickly so that we actually have time to discuss.
[01:19:36] Tianxiang Li: Okay. Sure. So I can look.
[01:19:40] Ryo Yanagida: Where is
[01:19:41] Tianxiang Li: I can direct get to the point. Yeah. So the most important thing is, of course, because we kept all the application perfect on the edge, so we did save a lot of forwarding stage in the core. In the core, we only need to maintain the routing where router reachability, and the the the topology is a fixed size. So, of course, it stays stable. And for the for the conventional routing, because throughout that prefixes, the you can see as the as the application premise goes goes large, you have more and more affording state. And at the edge, you can say both the commercial routing and our own routing and our new approach scales linearly with application prefixes. And then our next work is do the mapping incap at the incap domain level because the ISOs here still stay the same. That is you have a topological you have topological point, and they have logical and then identifier, and they need to map the object identifier to the logical point. And AS can be viewed as another topological point. So if we wanna do the inter domain map and incap, the first thing is that we really need AI starting protocol rather than perfect starting protocol just like BGP. And then we also need map synchronized mapping between the domains that is which prefix match to which AS. And we also need to solve the inter domain multicast problem, which kind of harder problem for us now because, currently, the Ink domain beer is not very mature solution yet. So that's our ongoing work. And our autumn and our ultimate goal is to have new Indian test by the rollout with this map and Ink app. Yeah. Thank you.
[01:21:20] Ryo Yanagida: Thank you. Duck, please.
[01:21:26] Dirk Kutscher: Hi, This is Dirk. Really nice work. So I guess the the scaling scalability of the system kind of hinges on the scaling properties of the edge router synchronization. So think you I only showed it briefly, but I I think you assumed, like, 64 or 51 patch routers. That's a fairly low number. So can you say a bit more about the expected scaling and also maybe your performance latency when you use synchronization protocols like SVS. Not quite sure how well that would work in a.
[01:22:05] Tianxiang Li: So for the scaling part, because you you have to cap all the mapping table at the edge. So the at the so at least for the edge routers, they have to have a forwarding state. But the point here is that you don't have to if you really want to optimize, you don't always need to keep all the prefixes in the forwarding table. You can have some on demand driven that is you only you only put you only put the, like, the popular mappings. You only populate the popular mappings into real, like, the s r the s r a m or the fast fast memories. So the whole point is that we want to keep the network itself, that state to biological bound. For the application for the application part on the edge, I think it's optimizable number. And for the s and for the convert, the number here is that because the existing approach is that you essentially brought a perfect advertisement to the entire network. So, actually, actually, we now it's we are not not we only prefer we only add, like, only 500 2% of agency, but we saved a lot on packet overhead. Whereas previously, you have to broadcast entire network, but now you exact multicast the edge router. So the actual saving is on the packed overhead of a new perfect. But, also, another important gain is that whenever a topological changes whenever a topological changes, it's only one factor in protocol itself. You only there's only update in the distant vector protocol. Logging topological changes does not produce, like, perfect churn for the mapping table because mapping table only says for this route, we're gonna have perfect zero available. For internal topological changes, it doesn't care.
[01:23:58] Dirk Kutscher: Any other questions? Yep.
[01:24:00] Ryo Yanagida: Alright. Ken?
[01:24:03] Ken Calvert: Hi. Thanks. Just a quick question to clarify. Did I understand correctly that, that interest sync interests need to go to every member of the group, so they go to every edge router? Is that what you said?
[01:24:20] Tianxiang Li: Syncing first that announced a new mapping table optic, it need to get to the old edge routers.
[01:24:27] Ken Calvert: Oh, it's oh, but not for application sync interest. Just mapping table update sync. Right. Application. Okay. Okay. Thank you.
[01:24:36] Tianxiang Li: First match. That's perfect. Right.
[01:24:37] Ken Calvert: Yeah. I got it. I got it. Thank you.
[01:24:41] Lixia Zhang: Okay. This is. So in my pre Indian life, we we were working on BGP. I think a few of you remember that those days, we developed some modules for tools. But back to this point, with regarding to the overhead, when they were BGP's are, we noticed two things about overhead on the BGP. One is the document. That's what we measure. It's a huge amount of shifting. When the ATT and the horizon has a cut in the middle, in those days, ATT and level three, then thousands tens of thousands of prefixes change a lot. That's a model of updates. That's a overwhelm the network and the cause of congestion on their own. So I think what we doing the might have, we separate out the prefix changes from actual technological changes. And that's a big, big, big saving based on our previous life with the BGP. The second thing is about routing convergence delay. Because you you substantially by all those are magnitude of deduction of the routing updates, the convergence is also fundamentally different. Why is that there's not that much volume to ship? A tool is that the prefix to router mapping oh, yeah. Perfect to router mapping later is prefix to AS mapping was communicated in a entirely separate channel than the topological updates. So the sync goes really fast because it's not about one author sent package to many others. Instead, it follows the the multicast trip. I think a chance question is a good one as a clarification. We're talking about routing protocol or the application and so on. By protocol stack, BGP is is on the high level. So so that's this routing sync has nothing to do with applications whatsoever. It's a very separate sync. Cool. Thank you.
[01:26:45] Dave Oran: Thanks. Let's move on. Next talk.
[01:26:57] Ryo Yanagida: Yep. Right. Take it away.
[01:27:04] Farhat: Yep. Thank you. Hello, everyone. So my name is Farhat, and the this part I wanted to to be this presentation to seek a discussion actually about the confidentiality in Indian and how it induced thank you, how it induced the data centric confidentiality, the challenges that, cryptographic engineers face, and our, our own proposal to, to try and enhance, the existence. So we know for TCP IP architectures that we usually rely on securing the channel rather than the content. So utilizing cryptographic channels like TLS, sessions. And, the main thing to keep in mind here is that the encryption and the security is, purely bounded to the session itself. So, the security starts, then ends with the the session itself. On the other hand, for endian architecture, we now seek to secure, so develop the security mechanisms around the content itself. So first of all, of course, we have that every packet, can be signed, and every data packet, is mandatory signed at prediction and distribution of it. And maybe the main idea to keep here is that security properties of the data needs to travel with it. So, it's either about signature, the key used to sign and to verify the signature, and for for our case, here, encryption, the ciphertext in itself, of course, and the the content needed to, the cryptographic material needed to to crypt, the ciphertext. A key point here for this discussion is, is to is to see that authenticity and integrity are built into NDN. However, confidentiality is left out, to the application layer. So, we have a lot a lot of work that, claimed that security is is built in natively in NDN, but they usually refer to integrity through the signature scheme rather than confidentiality through the encryption scheme. So when develop when implementing confidentiality in NDN, we are facing a few challenges. Practically, all of them comes for from how NDN works. First of all, we have the in network caching, where since the data is scattered in the nodes of the network and you lose the direct access of its distribution. So we cannot control directly the access to it. Even if you do actually control have a direct control on data, a producer receiving the interest doesn't, natively at doesn't know which consumer requests what since the, by default, interest packet doesn't hold identity information, and it doesn't know as well how many consumers it will serve. So this kind of makes the key negotiation and the key exchange and through channel security practically pointless. And maybe one last thing is, to talk about the one to many inherent communication model, of NDN, which constitute actually a group key management problem, a struggle, especially when dealing with revocation where if we want to revoke, an access to a consumer. So here we have the, data centric answer, the data, meaning the data centric confidentiality where we seek to encrypt the content and not and not the connection. So the the the ciphertext, of course, travel with the data. And as we said in this previous slide, security properties travel as well with the packet, which helps guiding guiding the consumer to to for in its decryption flow. One other one, one other important thing is is to say that access control now becomes a key distribution, problem, since now granting access or revoking access translates to having or not having a specific key for for decryption. So here, we take a look at what's maybe a foundational work in data centric confidentiality, namely here, name based access control, where we solve the key management problem by, first of all, making the key named data itself and the data packet that consumers and and other nodes can can request. Also, utilizing naming conventions to to to ensure the decryption flow, and automate the the key management process, so guiding consumer knowing for we, for for a content name, which key to to utilize. Also, if we are working with the attribute based encryption version of the of the NDN-BAC access control, we now have the an access control that fits the one to many communication model that we described since IO with attribute access, attribute based encryption. We have one encryption that can be sent and decrypted to many consumers. However, here we need to point out some unsolved points. First of all, we we know that NDN supports the decentralized application. So it only makes sense that the authority here follows this pattern, and we avoid this single point of failure. Again, we talk about the group key management, problem. Here, if we want to revoke an access in this access control architecture, we actually ended up, waiting for the next rekeying of the of of the encryption scheme, which means changing basically all all keys, either private or public, of the asymmetric scheme. And on the other hand, it leads as well to changing the preshared so the shared key that is the is the symmetric key used for communication. And changing it means inducing another encryption and decryption of participated notes. So here we are we are actually going to take a look at each point and discuss discuss them. So first of all, about the centralization problem. Here, we can take an example of the the only the secure the this one a secure decentralized workspace that is built over NDN, and that sits on the NDN testbed. And let's take, for example okay. For myself, I'm a I'm a user of of this application, and I'm connected to the Frankfurt node. So it is my authority, and I want to access content that is under the u c UCLA node. So the first question to ask is that who will issue the necessary keys to give access to to this other domain data? Is it my own, which has no relation with the data, or is it the the authority of the the of the content I want to access, which but that doesn't govern govern my my node? Another, simpler question maybe is, what if the authority, of course, goes down? So, we can clearly see here a single point, of of failure. So how do we revoke access to cached, cached data? Well, answering this is usually about balancing, the efficiency of the revocation. Of course, the the the more the immediate revocation comes with a cost on the system. Initial solution is to rely on the periodic rekeying of the system to ensure the the revocation, either the admission or the exclusion of members in the communication, which means that we need to wait for the next rekeying cycle, which is not an immediate revocation. And if you want to make it more if you want to apply revocation more frequently, we'd have actually to increase the rate of the, which is, of course, not without a great cost, on the system. So we can imagine, the point here on the bottom sliding more through this axis of the cost rather than, for the immediate revocation. A more drastic solution for for revoking data is to say that for every revocation, I will rekey the entire system, of course, and utilizing reencryption because we talk about cache cache data. And for specific scenarios, we may require that this that we control also access to this already cached data. So we actually end up re encrypting what's inside the NDN routers. Or, of course, we will be looking at an in between solution, so utilizing publicly available, cryptographic material to ensure, updating the necessary keys, either private or or public. And, we can also argue that, reencryption re encryption is actually two two scenario specific. So, we we may say that the content that is already cached, we only assess the access, of consumers when the content, is distributed, from the producer. So, another design choice about implementing the confidentiality. Of course, we may say that each Indian application will implement its own encryption scheme for for the greater flexibility, but, of course, not really a solution, honestly, because of repeated effort and practically no interoperability between heterogeneous and the application. For the for the to the other way, we can say that we can implement, standardize, actually, confidentiality into NDN, a more drastic, a more drastic solution. So following the the signature scheme, which is built in NDN. But, of course, this risk, again, to of fixing single encryption scheme for all u use cases. And, again, a a middle solution. So working with a secure security library that sits between the application layer and the network layer. But, again, application still needs to use the same library, and, it still keeps confidentiality optional in the sense that signature is mandatory, but it keeps the confidentiality to the the upper layers. So question here, what's the best approach, of course? So here, we I will discuss our attempt into enhancing and maybe addressing the points that we discussed earlier through a security library, a secure a decentralized security library where we utilize multi authority attribute based encryption to provide confidentiality in MDM. So for this scheme, we include an immediate revocation mechanism as as we talked. So utilizing publicly available information that are shared in the network and with it an optimization mechanism because we know that the the shared key that is used, we know that it's gonna change after revocation. So what we do is that we we save cryptographic information done to in the initial calculation, and we reuse reuse it in the next encryption and decryption to drastically reduce the cost the cost of it. So this library aims, of course, to to be integrated into existing end end applications and sits and it aims to sit between the application and network layer. So quickly, we're taking a look at the architecture of the of the library, which is implemented in a modular way. So first of all, the cryptographic scheme where we which will we implemented from scratch in order actually to provide this this enhancement and and and this modification to provide the revocation mechanism, for example, the optimization mechanism, etcetera. And other, of course, section mainly the communication section, which deals with inter network interaction, of course, of the of the library, which which translates to key key exchanges and key management, etcetera. Library, so it exposes three roles. So for the authority to generate and generate keys, distribute them, and revoke access as well, and, of course, the encryptor and decryptor role. So to summarize this library, so it aims to provide an open source, decentralized attribute based encryption for the end Indian community and, of course, for who who's ever interested about data centric confidentiality and or cryptography in general to maybe contribute to to and to utilize the work as well. With the library, so we provide as well a benchmark, which, you can find, you know, within a website. The website is not published yet, but the source code the source code of the website is in the in the repo, and we make sure to to publish to to publish the website. So we have the benchmark evaluation done on different hardware configurations where researchers can compare directly their work with it. So that's it. Thank you. Thank you so much. Thank you.
[01:42:16] Lixia Zhang: Hello? Go ahead.
[01:42:19] Tatet: I have a question. Have you ever lived evaluated the performance overhead of the library of the library resource country that diversities such as IoT or HR devices?
[01:42:39] Farhat: Could you please repeat the the last part of the question?
[01:42:42] Tatet: Have you evaluated the performance per head of the library resource control devices?
[01:42:52] Farhat: Resources? Resource constrained devices. Oh, yeah. IoT devices. Exactly. So we did on this actually, there is more, the Raspberry as well. So three different hardwares where we publish it on the website and show for granularity is each, cryptographic function. So to encrypt, this is the cost in milliseconds for in each hardware configuration. Yes.
[01:43:19] Tatet: Okay. Okay. Thank you.
[01:43:20] Farhat: Yeah. Thank you.
[01:43:23] Dave Oran: Hi. Dave here. So we know that the the cost of signing every single packet when you have a large object is, you know, quite high. So the one of the conventional solutions for that is to use a manifest and and amortize the cost of signatures across a manifest. I'm curious how you think that I mean, this is like future looking, but how do you do you have any ideas about what you think the right way to integrate manifests into the library so that applications can do their their interaction with with with the system based on large objects controlled by manifest as opposed to having to do the interaction for every single packet.
[01:44:13] Farhat: Actually, in the initial work, we we did assume a there exists a manifest, actually, a produced distributed by the producer to actually keep track of the different keys and content name keys used of used during a large a large session of transmission. In our own work, we we assume the streaming streaming streaming session, and we utilize manifest actually to keep track of maybe revocation, but mainly the content name of the keys that need to be decrypted in order to to to to decrypt the data.
[01:44:54] Ryo Yanagida: Alright. Alicia, please.
[01:44:59] Lixia Zhang: Yeah. First of all, thank you very much. I thought, Ken, I was first. Anyway, thank you for doing this work. It's great. I wish you had a like, we we interconnected them better earlier so that we can have more exchanges. I just forwarded the NTN technical report that that also shared your view about this security layer between the application and, you know, the transfer of the lower layers. I think we shared a similar idea there. The regarding using a manifest for large amount of small data, the we actually have a recent publication on that. I'll look at it from my website. Unfortunately, that hasn't been updated yet, but I'll send you the pointer afterwards. That is actually work done mostly by University of Memphis. They they use Indian to disseminate mobile health data. So there's large numbers, small size for data, and now very nice way to apply manifested from that. I think, Tina, I had something else to add. That's about our latest encryption progress. For that, I would like to mention that.
[01:46:23] Tianxiang Li: Yeah. Yeah. Oh, thank you. So so I have first, I have another question that is because I'm speaking I'm speaking on behalf of both only developer and a test bed maintainer. So I thought earlier that you have a size regarding only and its relation with test bed. Could you revisit that a bit?
[01:46:42] Farhat: Yes. Of course. This?
[01:46:48] Tianxiang Li: Yeah. Yeah. Yeah. So what do you mean by my authority goes down? I'm just curious. I didn't quite get. Sorry.
[01:46:56] Farhat: Actually, we've been talking about governance. So I'm connect I'm under the governance of an authority PKI architecture, so I have an authority that distributes me, the the the necessary keys. But, when I'm trying to access content that is different from my domain, which means that the producer that produces the the the content is under the authority, of another domain. So here, we have a governance problem where each the producer and the consumer are under the authority of different authorities. So and when trying to resolve this solution, one initial idea, of course, is to say is to create a central authority between them so which manage both both domains. But, of course, it brings other mainly governance problem in this case.
[01:47:56] Tianxiang Li: I see. I see. I think because we didn't, like, sell our application that frequently. So I want to mention there are two important updates in recent only. That is first, now our application security is completely orthogonal to the infrastructure security. Now what they show, like, on the right side of the size, the test path is only we are we use it at traffic transit. It does not middle not only with the application application as security. Now we are not only is using pure self control trust domains trust and. So there's for now only, you don't we don't directly get keys from, say, UCL window. It's completely to the workspace creator itself. And second is that I don't know if you are aware of the recent trend of especially in ITF ITF about the message layer security. Essentially, the latest trend of doing the group encryption, and only now it's only it's also supporting that. That is whenever the membership changes, it automatically go to the keys back some crypto crypto games. So we don't have to face the replication problem. Yeah. It's facing a different problem now. You don't we don't need to invoke group keys anymore because key is automatic and this is negatively have forward secrecy. Just I know it's based on the early early work, but I just want to share the news.
[01:49:24] Farhat: Well, if I, if I, might answer this. So when we define group communication, so we have a content that we have a lot of consumer that shares the same key. Right? So we share the same key. When so when admitting a new consumer or excluding an existing, consumer, and if we are still using this, hybrid encryption screen, so using isometric and symmetric key, we'll have to change the symmetric key that is used in the communication. And, of course, here, I I I pull up this, Indian application just for a just for example, for a for a scenario example, for a communication example, to showcase the the need or no no need of central or or decentralized authorities.
[01:50:22] Lixia Zhang: Can I want to say something? Or
[01:50:26] Tianxiang Li: I think yeah. What I want to say is the latest trend is that there is no group key per se. The latest trend, as I can help, at least in ITF, is that for group communication, you will use this message layer security. And whenever membership changes, essentially, you have a tree of keys. And when the membership changes because when the membership changes, the root of the tree changes, and that automatically rotate the keys by the some ratchet scheme. And
[01:50:56] Lixia Zhang: I would short term explanation. So the latest, the only release actually adopted the ITF standard and IOS message layer security that essentially, you know, it's it's a devout to the solution, which is the user. That changes the encryption key every time that the membership change. And, also, you can have your mind to trigger other than membership change. Other your mind to trigger the key updates. It's all built in. We we just benefit from it.
[01:51:25] Tianxiang Li: So that we don't need to explicitly reorder case.
[01:51:28] Lixia Zhang: Right.
[01:51:29] Tianxiang Li: It's
[01:51:30] Lixia Zhang: So so we can look at the MLR RC. I forgot which one is it. This is standardized. It's just not.
[01:51:42] Ryo Yanagida: I think in the interest of Ty, I think we should take the discussion further at the mailing list. But thank you very much.
[01:51:47] Lixia Zhang: Thank you. I think we can
[01:51:52] Dave Oran: do something in a few minutes.
[01:51:53] Ryo Yanagida: Alright. Do you think you can get this done in three minutes? Okay. Alright. We have formal talk that is proposing sorry. I'm I'm I'm trying to control two I'm trying to do two things at once. So we have a proposal from Liu to draft, I think.
[01:52:18] Shelley: Okay. Thank you.
[01:52:19] Ryo Yanagida: Hang on. Hang on. Hang on. I need to give control. Vishay, I'm gonna mute you if that's okay.
[01:52:28] Shelley: Okay. Good afternoon, everyone. I'm Shelley from Nangy University. Today, I'm your our director on name basis computer service. Decorable space terrestrial maritime engine net networks. The key question is how to decover service and reusable result by stable names, not temporary endpoints. Conventional endpoint to discover or convince the endpoint is stable. In our scenario, this assumption is weak. Maritime gateways, LEO satellites, and the rest your clouds may provide a changing service instance or temporary cat catcher's resource. So endpoint only, the cover is a. The cover should also describe what is available, whether it it is valid, and whether it can be tracked and re reused. We can send a maritime, no terrestrial and terrestrial end domains include gateways, satellites, and and sets catchers and result stories. The discover function is logical, not necessarily centralized because connecting maybe intermediately. Cats or exchange record master carry dash source is under well validity. This draft for objects, service name, service instance, data objects, and result objects. Our service name give stable identity or service instant instance result at a site. A data object may be input model and or configuration or result object is reusable output output. The cover record binded these objectives with metadata capability, validity, policy, and trust information. The draft define require requirement only. The draft discussers for use case, maritime analysis of the music, satellites access, catcher's result or reuse, and operation during partition. Together, they should and that's discover master's portal intermediate connect connectively cross domain policy and safer result reuse. The first the first requirements group is a stable naming and the capability description Service name should remain stable when instance more restart or replicated service record so the describe a capability versus and dramatic method with time stamps and validity provide. The the the second group is a description description awareness and the result reuse. Recorded needs need need a explicit validity and a expire record recorder should not provide current reachability. For reuse, results must be on the tool service identity, words, input data, permit, and exclusion context. The third group is charter. Authorities and development. This covered card must be integrated, protect, and attributed to authorized publisher. Cross domain trust must be explicit for the recommend of the design. So the work with existing RT network, native RTM forwarding should not be required everywhere. This draft is related to and DTN DTN SD support service instance discover, but lacks fully validity provenance and result reuse smartness. C COTS focus on traffic stream via disrupt folks discover mid date before stream decisions. Let me conclude. Cross domain and system needed to cover beyond the endpoint look up. The cover, so the separator, stable service name from a temporary exclusion logical Record also the carry capability, validity, for instance, provenance, and policy in information. Reusable results are are useful only when reuse conditions verifiable. Open question remain on recorder format of trust reuse policy and integration with COTS, I think, or DTA mechanisms. Thank thank you. We are coming are welcome.
[01:58:09] Dave Oran: So given the time, I'd like people to who've looked at this to take comments onto the list, and we can continue the discussion there. So thank you very much.
[01:58:20] Tianxiang Li: Thank you. Thank you.
[01:58:24] Dave Oran: So let's just wrap up. The one thing I want to cover right here, and we'll also post the list on this, is that the good news is that we had a tremendous amount of interest in interacting in person and, of course, remotely at this ITF. So it's a continuing interest in this research area. And we had more talks than we could accommodate even in the two hour session when, of course, given the constraints of scheduling at the ITF, it was actually quite difficult to get a two hour session. We wanted this to have a less time than that. So given this, I'd like to get feedback from the community as to whether it might be a good idea to have a meeting before the San Francisco meeting in November, where we can accommodate some of the talks that that we we postponed out of this meeting we couldn't accommodate. And also, maybe to get started on some work around FLIC and some and the versioning draft that's in process and other things like that so that we're not sort of like piling everything up at the last minute before San Francisco. So I'm gonna post to the list what people think about the the advisability of perhaps scheduling a meeting. It would probably be mid to late September, so we split the time. And people are back from vacation, and for academic folks are are are back on campus. It would be obviously a more online meeting, not an in person meeting. So look for that on the list, please, and please weigh in on whether you'd like to, a, have the meeting, and b, if you have a talk or a specific that you'd like to discuss at the meeting, propose that so we can put an agenda together well in advance. So we are just about out of time. I'll remind folks that we do plan to meet again in person in San Francisco. I don't know which of the chairs are actually gonna be there and will will manage one way or the other to to make that happen. So gotta also give some thought to what we would like to have happen there. Do you have anything to add? Great. So thank you, everybody, and off to the the plenary. Cool. Yes. Thank you.