Internet Engineering Task Force 103, 8 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF103-ICNRG-20181108-0900

Description

ICNRG meeting session at IETF103
2018/11/08 0900

https://datatracker.ietf.org/meeting/103/proceedings/

A

Yeah good morning we gonna get started quickly shortly. Could somebody maybe close the doors.

A

Okay good morning, thanks for coming to icy energy, we are therefore ran by a woman and I'm the co-chair. This is icy energy in Bangkok as usual. Let's consider the ietf IPR policy, so just very briefly, it's quite similar to the ITF IPI policy. If you see anything or present anything that is related to IPR, you expect it to let the group know in a short timeframe: yeah we have a mailing list. We have a wiki.

A

The wiki is the place where we typically store all the say, current meeting information, this meeting, so we are super grateful that we already have a note-taker thanks again now. In truth, we not sure you want to use the ether pet, but if you do there, you find the link on the slides or on the ITF.

B

Agenda and also, if any, would like to contribute to the minutes you free to write and eat the pet directly. If you want to add something.

A

Yeah, all this all the material is online already. So somebody follows this remotely you get all the material there. This is our agenda for today, so we have two hours, so we start with two use case presentations.

A

So Simon is gonna talk about ICN architectures in smart buildings, and then we have Kanchana who will present a quality air quality monitoring.

C

A

Case this is followed by a block on ICN management tools, CC an info and so compared to their ping and traceroute. We have a brief update on net me. Ravi is going to do an update on the ICN I wrote a draft and Thomas will present an update from the ICN lope and work any need to fish this vendor any comments.

A

A

Those of you who haven't been following every meeting recently so we had since Montreal. So last idea we had two interns, one after the AC and conference in Boston in September and one just last Sunday in Bangkok. So I'm not going to give you the total detailed summary of all the presentations they are. So the everything is online I'm going to talk about in the next slides a little bit about you know, work items that popped up and so relevant things that that happened there.

A

Okay. So if you would have to describe what I see energy is actually doing in terms of technology, so we thought a picture like this could be helpful, so I mean I, see. Energy is a same IT project group that tries to do continuous work on, say, ICN, technology, development and experimentation, and so you could say we have something. You know like a core specification, some things like C, T and X semantics and messages.

A

We have. You know work that looks a bit into getting this implemented on specific link layers, for example. So, like Thomas s, lopen work, for example, h ICN could perhaps be seen in this category and then we have saw in the in this so after core spec layer. If you want a couple of extensions, so mobility support things like let me, for example, or other work outside of ice energy like height, we have work on named evolutions of it like infrastructure services. There are some proposed extensions, so rice.

A

What method implication would be one and yeah also say helping or say yeah extensions like flow classification and quality of service mechanisms and so on, and so some of those actually, you know kind of, extend or modify things like the cost cost specification or the the note behavior, for example, rice and has a curtain extended behavior met knee as well.

A

So it's not actually not clear layering, but you get the idea on the far right and we have things like management tools, info pink, for example, and then we are we looking at applications and how they interact with the system how they could use, make use of these different facilities.

A

So that's how we currently so in a very high-level kind of would like to this kind of describe the technical work here. Of course, there's also other work going on things like deployment considerations, terminology.

C

A

So on that not on this slide, let us really more the technical.

C

A

Yeah I hope this explains a little bit. Let.

C

A

C

A

Comments or whether we missing.

C

A

Which it's quite possible quick update on our work items, so you know we had these two specifications so see any messages and semantics. So basically they passed all the ports here in the group and also in the ISSG and fathered me. We are currently waiting for the IETF chair to move this to the next level. That would be reviewing the ihe and I'm finally ship this to the IRC editor, so we're trying to progress this. It's a it's a bit slow right now that progress there.

A

D

A

The flip, so this manifest.

D

A

So how you could describe I see an object that form a larger file, for example. So this draft unfortunally is currently expired. So we're talking to the teal office but I mean everybody's quite time. Conference with Chris has another focus now. On the other hand, we think this is really really important, work and really useful and really like to get this out at some point. So if anybody you know wants to, you know have a long, lasting contribution impact on ICN and is interested in flicking.

A

Maybe just talk to Chris and Christine on whether maybe they're there they take. We need some help, and so by the way. So, when I showed this other picture, I mean before so when.

C

I mentioned specifications.

A

Like CTN eggs, for example, so that doesn't mean like, for example, in an ITF working group context. This is the one solution that the group endorses. So what we are really doing here is research and experimentation, so we can easily have thought several incompatible competing proposals and still publish each of those incremental our sees, for example, so it doesn't mean that it's he connects. Is the ICN actually specification? It's it's one and half the things that people brought to the group.

A

Certainly I see. Energy is open to other work as well. Okay, we recently finished in this group. We thought the ICN in disaster scenarios draft.

A

There were some comments in the IR 3 review, and so we really would like the authors to consider these comments and come up with an update, so that also hopefully should happen in the next week's we have the deployment conservation draft. That is basically half finished. Last call here in the group. We also can be waiting for the ITF chair to initiate the review at the iOS G.

A

We recently adopted CC and info, so Tasha son is gonna. Talk about this in a bit so I don't need to say.

C

A

Also adopted the IC, an application to to lopen that works with what Thomas is gonna talk about later. So, let's get to this later, we also adopted two drafts on home resolution, so one is called the name. Rutan's requirements were frenemies Ellucian, there's coming more the motivation and requirements it was once name and the other one is called architectural Conservation's of ICM using n is so bit more than say, broader picture and architectural impact right. Please fill out the blue sheets, interestingly, at the last, so not this Sunday, but the Boston interim.

A

We had invited people from obviously first to give us a first say overview about the global name service, GN s that they developed in mobility first, and so we think that could actually be a fruitful discussion. So there there's a solid body of work in that in that project, and so the people we talk to I actually interested to to see how that could perhaps help ICM nor at least have our discussion. Again.

A

We have the terminology draft so but I'm kindly updated. This recently was like yeah actually updates, mostly we just discussed in a little bit. So Batson is kind of come back to you on the mailing list to you know, ask for additional comments. We think it's it's relatively complete and it could be one of the candidates that be for the next draft. We want to finish up here and publish eventually we had the negative lead moment of IC in ite and that works draft, so there was also planted on Sunday and there.

C

Is an email on the that.

A

Is discussing next steps so I just want you to that right now and yeah rather later is going to talk about the IC and I go t draft. So how I would he can leverage ICN features that me so the mobility they could support was updated. What happened is that Cisco declared their their IP arts or recently.

D

A

It's the usual Cisco.

C

A

So tapers to the update for the author's who couldn't make it this week, ping trace route as well, we'll talk about this later. So this is the say about that simple or basic past discovery and testing facility.

A

We have a couple of things related to Q s, so one is the flow classification draft, so how to encode equivalence classes in ICN and what consumers producers and folders should do with it could be a basis for us.

A

We had Gregg's and colleagues courses, draft on IP, tunneling CCM, so we're actually interesting proposal to do ICN provided multi-plane to IP without using the existing or legacy.

A

That is something where we could also sort the thing about next steps. So I think last time that was presented, people felt it was useful work.

A

Yeah any suggestion from your side.

A

Okay, so then, let's do like this.

A

Yep, so we let's initiate like a review on the main list, so please.

C

If you interested in.

A

Doing IP o wise CCM, never look. We have the ICN over 5g, next-gen, coop attack, sure draft hasn't been updated and we have the dynamic inter inter domain, which is support framework for ICN. They was also presented, I, think one or two meetings before and hasn't been updated.

A

There is new work, so I mentioned the flow classification early amped, so there's an additional draft on POS, so that is petrov currently is describing how to basically use it. This surf like model, however, there's a thread on the mailing list discussing that the other options and we had a really interesting discussion on Sunday and maybe please check the the presentation.

A

And the minutes yeah there is a new draft on remote method invocation that we blended on Sunday. That's intended as a general basis for NS end like interactions in ICM, and we also have new to have a. We are so basically one.

C

Application of.

A

And then, and a couple of other drafts that I don't only do tell about right now so they're also in the data tracker, hasn't been recently updated. Please let us know if you want to say anything about this or know anything about it. Otherwise, let some fun.

D

A

Start with the first presentation, and then it's gonna be Simon.

E

Thanks good morning, so I will be presenting the use case of applying ICN architecture in smart buildings and.

E

The interesting observation here is that we've been doing that for a couple of years within go to sick with the system known as Bluetooth mash. That involves both the low-power short-range radio transport technology, including, like multi hope, network and the application layer for building automation as well. And what was surprising to me kind of maybe a year ago, is that many concepts that we developed there, we're kind of counter wouldn't say maybe counterintuitive, but they were definitely against the conventional wisdom, because everybody else was doing like a node-based.

E

Address routing and point-to-point unicast communication and we came with the concept of hey: let's use, let's optimize the network for massive multicast and let's use pub/sub paradigm, and then we realized that the friends at IC energy are like using the same concept for the big internet, so that was very encouraging and and refreshing. So so that's what initially brought me here to this group and Bluetooth mash is today it's not a an IP based system, so we are moving into that direction.

E

So my interest here is as well to like figure out how to merge the IP based approach and whether and how the ICN concept should be brought into that in that system. So did. The highlights here are that, from the practical perspective we were looking for, simplified configuration and named addressable data really helps there. We were looking at scalability and no points of failure in a network, and we realized that we need to use like at the transport level.

E

The network must support multicast as a primary method of propagating messages, and pub/sub is really the right way to go and dealing with bigger systems and bi bigger.

C

Systems I mean like.

E

Building like this one, it's probably in the range of twenty thirty thousand lights, for example- and it will like buildings like this, one will soon have equal amount of sensors. They don't have there yet, but but but definitely like the trend is that each light points in a building is equipped with sensors and is a sensor itself, because it can provide maintenance data and such so speaking about the lighting applications. So the the concept here you are on the left side, you have the traditional approach.

E

Illustrated on the right side, is the the ICN approach, so in a lighting system. So the square boxes are light. Fixtures like office trophies and they have little antennas representing that they communicate over a wireless network and doing ABC are representing.

C

E

They can have multiple sensing elements in in a package and the blue box is the controller. So the traditional approach has been that sensors ABC are reporting some data and that data is collected by the controller. The controller runs the control, algorithms and then issues control messages that control the light fixtures, so the lights. First of all, like the basic scenario, is occupancy. So you enter a room, the lights come up, you leave the room and after a while, they go into didn't, go off and that's how everybody has been doing that today.

E

So the first observation that we had was that there is some necessary traffic coming from the controller to the light fixtures, because if you realize that the controller is a piece of software, then today you can distribute that across the network. So you don't need to have a single controller that controls the whole thing.

E

You can have a copy of a controller embedded into each each node, so that alone saves a huge amount of traffic on the network and also makes the network much more redundant, because you suddenly have a completely distributed system and the second observation was how to easily match the sources of information with the consumers of information. And, of course, what is represented here by the hashtag like Twitter, like paradigm of pub/sub, is really applicable here, because that really decouples the controllers or controller equipped light fixtures.

E

They subscribe to given information like the lights in this room are interested in occupancy in this room. So that's the information that they are interested in, so they want to subscribe to that, and- and if that the information is addressable, then of course the whole system is naturally easy to configure and the sensors they publish and they publish again, it's really not important how many sensors you have in the room, it's important that they all contribute to the whole block of information referred to as occupancy in in room.

E

We are meeting to write so meaning to occupancy. Is our addressable info block and many sensors in the room contribute to that publish to that address technically and the light fixtures subscribe to it and, of course you can have more advanced configuration, as illustrated here so luminaire may also be interested in subscribing to ambient.

C

E

Level information, so that's referred to as daylight harvesting, so the luminaire is closer to Windows. They are dimmer and luminaires they're further out are brighter to level the light level in.

C

E

In that case, you need at least two pieces of addressable information. What one is the ambient light level and the other is you can see, of course, in my multiple zones, so that depends on how many, how many light sensing elements you have. So you might have a zone, that's closer to the projection screen and the sensors that are further out, and then you may want to set the thing that that close, the projection screen. It is dimmer because that makes the projection better visible and also, as illustrated on the right side.

E

The luminaires themselves can produce information because they produce information about their status, their health, their operating parameters and that's very important, and that information goes to another address. That is like a system health address and that may be subscribed to by variety of system monitoring devices like little boxes that display ok. This is running ok or the the network operating center that that can display the overall health of the entire system and of course, you can mix and match. So it's really a peer-to-peer system.

E

You don't have a clear distinction between who really is a consumer, because the consumer is also a producers. So it's a it's a flat peer-to-peer architecture that anyone can contribute the information and anybody can can subscribe to that information- and what's interesting here, is that this decoupling, by addressing the information, gives us the opportunity to really simplify the configuration because, like yeah I'll get there I have one more slide. One configuration example that is also illustrated here and it's color-coded, so the luminaries in the upper row.

E

They are denoted by the orange antennas and they subscribe to the orange light sensor and once at the bottom, the green ones they subscribe to. The green light sensor and in roman era, has a occupancy sensor and they are all in the same room. So you can imagine that all the lights, although all the occupancy sensors they publish to the same address the orange light sensor, publishers to Zone one address, the green light sensor publishes to Zone two and then they subscribe accordingly and again.

E

This is a completely flat system with no privileged host or a controller, and it's completely distributed. So these are the principles and Bluetooth mesh. As I mentioned, it's been out there for some time already and it's commercially available since July last year.

E

There are today about close to 100 different qualified products and they are interoperable with each other, so the installers can mix and match sensors and drivers and and switches dimmers from different manufacturers, and it all works based on on that part on that on that paradigm. So it kind of proves itself because already there are case studies that that showcase buildings that are equipped with with exactly the cities this system and the benefits from the configuration, simplicity and and reliability are really huge.

E

So the three highlights that I would like to illustrate here is is how, for example, simplicity of configuration and maintenance is is achieved once you have this indirect binding between producers and consumers by the layer of addressable information of operations such as exchanging a broken luminary are very easy because you just exchanged the device, and then you only need to subscribe it to the information on the sender side, nothing, he needs to be changed.

E

So it's it's very from a maintenance perspective, very very simple: scalability comes naturally and and it's even more natural, taking into account the fact that this is a wireless network. So so you don't have isolated between parts that the information is going. It's always broadcast media, so notes are overhearing each other. So it's inherently multicast by nature. That's how radio systems are built and and and by distributing the controller application to the notes. Then we are like having the the amount of traffic immediately and then, of course, because sensing is not only for one application.

E

Occupancy sensor can contribute to lights. It can contribute to Hedgehog system. It can contribute to space utilization application. It can contribute to whoever who- who knows what and that's the beauty of that- that the sensor just published its height, there's occupancy in the room or there's no equipment in the room and whoever wants may subscribe to it and the sensor doesn't need to be reconfigured so that ends up in a very robust, flexible and simple to configure system, so that reliability aspect is also very important because we really have achieved here.

E

The no single point of failure setup because it's hot it's all distributed, so it marries the concept of ICN with the concept of distributing, which is the the trend that is, that is really taking up today, and it really makes sense to push the computing to the very edge. So each node has as its own controller logic and it's capable of subscribing to whatever information it needs, and then it makes its own decisions and if it fails, only one node fails and the rest of the system keeps operating.

E

So it's more like a swarm type of an organism. So it's a collectively intelligent system where each cell is just a contributor to the behavior of the overall systems. We are like getting all the all the benefits of that approach. So that's it I'm sure. If we have time for questions or not, and please.

F

Thomas might have a handbook question: do you have implementations for this? Yes, I one now, do you do I see n over Bluetooth I mean that is thing like the UCLA and people and we are working on. Do you do this directly on the alto coupling or how do you do this? We so Brutus mash is a.

E

New architecture or topology available from Bluetooth since 2007 t.

C

E

To cup it doesn't use, l2 cut, isn't.

C

E

Based on Billy, it's based on purely radio, but it only uses the radio layer and then everything on top is a new stack and.

F

Where do you, where do you sit as.

E

I, as I mentioned, there is no IP in that system, so we cannot say it's icns, like we understand in this group. It's a concept, that's very similar because it's pops up, it's multicast, it's just different, addressing and different payloads, but but there has never been an.

G

F

But I mean ICN brings a networking layer here and that is also not foreseen by Bluetooth. So you should. There should be some some.

F

Interface on on the Bluetooth, where you put your ICN on top.

B

Spirit, yes, exact, oh yeah, we.

E

B

Run the night, the.

E

Protocols I thought I made it clear, but thanks for.

F

E

F

E

Icn style, yes, and now what we are looking for is to how to bring the two really together, because we find that architecture very applicable to the area that we are proposing. Bluetooth match for like smart buildings and now we're looking to how to inject the ICN through ICN layer in between the application and the transport network.

H

Differend one comment: one question to the question: first: so it: how do you think about how to design the namespace for these things? Because that's sort of protocol independent, but how the how the names get assigned and what semantics get put onto the structure of the names seems to be something the whole everybody could learn about you're independent of whether you know you choose one ICN protocol architecture or another or actually bypass it directly to the application so I'm. Curiously, we.

E

Also can provide our names there's the addressing space for the network is short that resists 16-bit addresses, and there is also a concept for the of 128 bits addresses that can be used for the pub sub relationships and currently whom they are just randomly generated. The addresses themselves, the long addresses- and we really at the network layer, we don't have a name space- is managed.

C

E

An external config utility, but this is definitely something we are looking into like how to solved it right.

H

So, on the other, next one is a comment and may have more to do with the actual product design. Here then, with the architecture, I was involved in the design of a system. A few years ago that was deployed at the MIT Media Lab, which had this nice property that you could tell the difference with whether the bulb was burned out or the device was offline and there were sensors on each of the the fixtures they were actually monitoring the other fixtures.

H

So the light sensors weren't actually separate there were light sensors on each fixture that could figure out where other neighbors were and whether they were working. Have you thought about anything like that? So.

E

E

First, this product here in the lower left corner, it's a sensor that you can buy today, it's in in distribution and it's actually a combined sensor and fixture controller. So the output of that device is the light level, so you can hook it directly to the power supply of the light and it monitors of it has an ambient light. Sensing element has the occupancy sensing element. It has temperature sensing element and yeah it exactly is capable of doing so. We have to.

A

Cut the line up after second whistling, but.

I

You mentioned it's like twenty thirty thousand bulbs and you have a lot of publish and subscribers, but I don't see. I know you didn't talk about how these multi casting routing itself is managed. It's broadcast. I can understand broadcast happening in this single room. So does it mean that you scale you basically manage the system by just localizing the network, and this network doesn't deal with anything to do with the other network in.

E

Another room: yes, so it supports the concept of subnets and subnets very nicely confined the traffic, because traffic does not propagate across subnets. You can configure a subnet bridges, so it hops from one subnet to another and the the flooding is controlled with TTL and message caches on on each device. So it's it's confined and so, for example, ambient light sensor in this room. It's unlikely than somebody in the other tower in this interest in informations, there may be a gateway, but the scaling factor for gateways.

E

Currently we see as around 200 300 messages per second. So, if, like ambient light, sensors are very talkative so to speak, they fire.

C

E

Of times per second, so if you have a number of them in the room, then then your air space feels up quite quickly. So that's definitely coming into a hybrid physical structure that you have gateways that offloads to a faster backbone and and the last two hops, maybe are wireless. So you only have routing between the bridges.

I

But yes, subnet is broadcast. Yes,.

J

Westford occur, I sigh and I actually specifically wanted to talk about the naming problem, because I I've been thinking a lot about that.

J

The way we need to address names in the communication world is often very different than how we address names contextually as humans, and it's a really hard problem and- and things like you know, when we have 50,000 lights in a building that gets much harder because humans, like to think about things, have please turn the lights off. That works in my house. I can tell my local listening device turn the lights off and it does, and if I tell my phone here, turn the lights off. It might turn the lights off in my house.

J

That's not what I meant if I want to send something to John's phone John is very contextual: II dependent is probably the person closest to me, but if he's on a different carrier or a different network, we don't have the ability to do that today and that particular really hard problem.

J

You know really needs to be addressed for situations like this and so there's a lot of work to be done in that area. That's true, okay,.

A

Thank you very much so Simon quick question is there anything that you would like to get from icy energy, for that I would have your work well.

B

E

I think because now we are working on the design of this IP layer because, as I said, we have the networking layer and the application layer bound together. We want to inject IP in between, so the application like the lighting control can run over IP as well as IP can run on top of the mesh under Bluetooth. Now, of course, there's pretty straightforward to do using the classic IP six approach.

E

Now what we are looking into are: how do we take advantage of the ICN concept because we consider it very relevant and that's still a design work, so we are kind of more listening, so what this group is doing and- and and that's yeah looking for input at this moment when we are ready with the IP design, I, think that I will be able to share that with with the group and then maybe collectively we can come up with the unified architecture, because that's definitely what we are after. Okay, very.

A

Good, thank you thanks a lot okay moving on, so we are extremely glad that we have Kanchana here today, so Kanchana actually previously pioneered the introduction of the Internet.

C

A

Thailand and she's now considering to do the same for.

C

K

Thank you very much, and this was totally unplanned. We met in the lobby and I was asked.

K

What am I, what am I working on so this is, you know a I'm working on air quality monitoring in Thailand the problem of air, for it is very serious, particularly in in term not of Thailand, because a lot of crop burning and as you can see that the previous Oh has put very serious warning to ask that three point: three million deaths linked to outdoor air pollution, and you know the the reason why am I get problem with my? My vertical respiratory system is because of this.

K

So this is the the picture of the northern Thailand during the breeding season, which is around March April. You can see that with the debris the near the safety PM level was only twenty five, my, but what we observe in Thailand was over 100 in the north, so it really serious and problems mainly caused by hot spot.

K

You know people burning their crops, so what happened today is that our Pollution Control Department have their own very big sensors placed around the country, but it is not sufficient because you only is cost around three hundred thousand US dollar store the whole country had you know less than twenty in a station that measure this kind of information.

K

At the moment there are a lot of people who are who get interested in this area, and a lot of them are using I, don't know what the unit sensor and then upload data, but the government said is it this data is not reliable.

K

Now. Another observation that the opposite. You know the government does is to use the satellite images to detect their burning in this areas and they also issue but banned period, where any burning is illegal. During the two months period.

K

So we propose to use sensors to do ground level, monitoring the PM 2.5, which is the other thing that costs your lung to. You know, keep creating a lot of health problem. So with this one, we try to try to make sure that we can provide timely warning to the local communities that get affected by PM 2.5, so that people can stay indoor not not going out today to to inhale the PM 2.5.

K

So in my mind, I I was thinking about in the end, since I met Li Jie in 2011, when she I listened to her talk at a conference and I think ah this is something I've been waiting for. I wanted to use the network more than just sending information. I wanted to be able to compute and using the network. Just like you know, very big, distributed computers so that that I mean the idea of using Indian started since 2011, but I didn't know what kind of application I can try this and the end on.

K

So with this particular problem, I found that it fits very well with Indian, because we are dealing with a very remote area. Where, then, the network is very often disconnected, so you cannot rely on a centralized system to do any data analytic. First, you know feedback crew to provide the feedback to the community. You will really have to have your own decent decentralized system, and you can you should, since you have this centralized system in a village, nobody is willing to pay, for you know some for electricity to run, centralized system even innovation himself.

K

So if we can distribute computation to every node, then the Lord is you know, distributed to everyone and I. Think the Indian concept fits very well with that. So another thing is that we have you know multiple data sources where each node produce stream of readings and all the time. So if we can leave that in order to do that job, we can also always take the stream and do some computation locally.

K

So this is what, in order to do this kind of project, you need to convince people in the you know the domain expert in environmental engineering or environmental people to listen to you, otherwise that they don't they don't think what you are doing is serious and you need to get the help in order to set up more stations, so I spend time to work with them, and we we started by putting our sensors in villages in the north of time and on the Tiber mist border, where what happened did this year?

K

That was the worst affected area. So we set up these sensors in so I can remember how many villages, but about 10 centers altogether.

K

This is the PM sensor that we used plant plant tower p.m. PMS, seven, zero, zero, three I think it's the one that's commonly used by the you know p.m. sensors okay. So this is our anode. We worked with our colleagues in University of Saban and I, think Macau and met several others universities. So this is our node.

K

You may notice that we used hulu neo with one key, because we plan to run computation in each node and we used. We have SD card to store readings, even when the network, when you don't have the network, you can keep the data and then upload it. When you get connection, our node has a Wi-Fi connection, but we are putting Lauro and on this node at the moment there are sensors that we have is 4 p.m. 1, 2.5 and PM 10. You just tell me when.

K

We upload the data to the cloud and we have our website that you can have a look. At least you know the data run all the time. 7 24 hours, this visitor URL.

K

Now, after we collected data from the decision, we try to involve the people, data and data science, people and environmental researchers to analyze our data, so the, but they found that we should separate our data into and for songs, and then they analyzed how they died and to be you know, they used our data to study the movement of the PM 2.5 with respect to burning sources and with respect to the wind and finally, they work on prediction model where you can use the data to predict, what's going to happen in any particular area which is which could not be done.

K

Indeed, with the existing. You know an existing warning system, because the currently, when you want the people, you give the warning for the whole province, not a particular village, and normally it's very inaccurate.

K

So now this is what we found. You could predict the PM 2.5 quite accurately from our data, and we found that the burning I'm, sorry p.m. level relates to the burning period, relate to the number of hotspot. So you we are now convinced and we are going to move forward. So we moved to step 2. Now that where I want to insert my idea of in the end to system so and what we want to do, as you know, as I said I, when I listen to this yeah I thought.

K

Oh, we can do computation on the network so and then I found you are talking about in network computation, so we match the air quality. You know is meaningful for people in the affected affected area. So we need, you know to do computation, even though the network get disconnected, and you can warn the people in the affected area immediately.

K

So what we need is the programmable Network, the what we need. You know the kind of question that we need to query. The network is something like to search for a possible source of fire. Ok, so if you have this kind of interest you, instead of asking for a particular stream of data, you should be able to stand your query to the network and the network can find you know you can write a program that say this kind of question can be handled by searching for sites with higher and higher p.m.

K

at that particular time, and then you can find traced back to the source of the fire. Of course, you can take, you know, learn. You can also use the wind direction to guide your search, so this kind of computation should be done locally, and the next question that we can do on this kind of network is that the each community affected of community would be interested to know what, were you know, the PM level for tomorrow, the very near future? Not you know weeks ahead, so they they would send interest to find.

K

In order to do that, that note has to do some. You know some modeling and prediction, and in order to do that, you need to get of data from the neighboring nodes and you have to get the reading from the wind sensor and then feed that to the prediction model, and then you can provide a prediction. So this is the kind of thing we think that fits into the ICN framework.

K

So what we are doing now is that that we continue with the project we try to expand sites. We are trying to scale and put our nodes in other countries, because there are many colleagues are interested in using our node. We are trying to expand to allow Philippines, Indonesia and Malaysia as well. Thank you thank.

A

You very much that's super interesting, so we have time for one question.

F

D

Us much choice.

F

So, thank you very much for this inspiring talk to my suite from happy Hamburg. Actually, first question is a simple one: wouldn't it be useful for you to have a small energy autonomous nodes that use harvesting when you, of course, would be too small use smaller nodes, then you use in the moment yeah.

K

These node that I just showed you will be the node that you know they would like it's like a gateway. Where you do processing, we will play, we are building smaller nodes and which just provided reading.

F

hmm But the maybe the more interesting question do I get you right, I mean, if you say, you're searching for the highest pollution value or something that you're actually asking for a routing scheme that that I mean routes along there's, something like the steepest descent or something like this. So you know Maxima and we.

K

Found that, if you are sensor, is nearer to the source of the fire, the PM rebel is higher. This.

C

K

We can use in the end we send the interest for higher and higher p.m. then you can find a geolocation of that particular sensor. Yes,.

F

K

Means that we want to find local the source of the burning yeah.

F

I understand who wouldn't this actually translate into a routing problem so that actually, your interest is guided along the yeah yeah.

K

The interest you increase the level of the PM in your interest and the solution I mean the once you send the interest. The note that answer to you would be the one that is closer and closer to the source.

K

A

Thanks again for bringing in this to us on very short notice and making yourself available, please keep us informed about the programs.

A

Okay, so we now am entering the second block. We want to talk about management tools and without further ado. I am.

G

Ok, so hello, so today, I'd like to talk about.

A

G

So we published the paper with the name of the countries and submitted the same countries as an individual draft, and now it's revised with a new name, which is a CC anymore, because the con tres is a little bit too complex a lo difficult to understand the real meaning. So we change a name and now last month it's a accepted as a research, acute draft. So this is a initial version of CC n info. As such good draft.

A

G

Takes them? Okay, so what seasoning one can provide? Actually I already mentioned and I already talked about a benefit and advantage what kind of information or what kind of status we can obtain using CC any four. So it's a really powerful networking too, and also precisely because it's really powerful networking tool. We need to have some function to enable some access control, ports, the cooperation or information disclosure, so this is also included into this draft.

G

So this is a basic behavior CC. Any info consists of two messages. One is a request message and the other is a reprieve message and a request.

G

Message is initiated by sinful user, which is a consumer usually and afforded toward the publisher, based on the Phoebe entry in a hop-by-hop manner, and the request message includes: request, block and report blocks I detail later, and the repair message is operatory initiated by caching lauter or the first allow the attached, publisher or publisher itself and hold it back towards 684 user along the pit entry, and this three primacy include reply, block and replies sub blocks this one also a little later so so this is newly defined.

G

The the message newly defined the similar type values, so the CCNE for message itself is compatible with CC NX, 1.0 TLB format, but request message consists of a fixed header. This is Allegra and message for mothers. One and also liquid, spoke TLV, lipid, pretty arabic and named clearly. So these two requests bhaktir by report bacterias on you and the reprime message, also consists of fixed data as well as a fixed. The request block TLB report rectory named Jared.

G

They are same of the request message because we just use same message and replace the type feared message. Type are sorry, miss message, type field to refer message and appended the reply block or sub block chain based. So these are the new type bodies we need to understand.

G

So packet type, request, reply, top-level type, oppa hope, type and CC annex message, type.

D

G

Well, I made animation, but it's already finished.

G

Ok, my animation is.

L

Not really bleach, so your.

A

Point rendered in Roseau.

L

A

So it doesn't show the animation okay.

G

So, okay, so that this is not so meaningful anyway. So initially the consumer sender initiated request message and the liquid message type is specified into this field. Pt request actually, but now it's already animation is already done. So it's now it says reply but injury. It's a request and the intermediate routers insert zero block, Lippo Tobruk inside hop-hop-hop, headers, step-by-step and finally, the last hop lot over publisher itself, changed message, type field to reply and appended the reply block and repressive rock infamies.

G

The information that his.

L

H

It actually runs faster than this.

B

H

Can yes, I can.

M

Hear you can you hear me well great I was curious, even though the animation didn't work. Presumably, are you sending just a single interest and then it is generating multiple responses, as it winds its way through the network, or were you sending multiple, that's a multiple interests, each of which goes somewhere different. So.

G

This kind of multiples, past March past support, will be explained beta. So could you just ask again later sure: okay, so so because regularly Oleg that it means that if there is no well okay, okay, so.

H

This is a request message and.

G

The new redefine several point: several several type field and several type TLB every field and I should quickly show this rider and request broke reporter salt. Please read the draft because it's a to detail.

D

G

Reprime message it's broken, the figure is also broken. So please read the draft.

L

G

Yeah: okay, oh.

G

um Sorry, it's really broken so anyway, so CCNE for provide us on unique behavior, which is which means that it's not regular, intercept.

A

So was this new Chromebook setup? Pdf is really the best format.

G

A

G

So, okay, so the request and reply communication is not really same of the ordinary interest and the data communication. So the question are the the lady asked me. So one interest may initiate multiple reply message. It happens but regularly regularly means as a default as a it's. Okay, as a default.

G

As a default, so the seasoning for message is works as.

G

Works like ordinary in terms of data communication, so the strategy, even though the some router has a multiple upstream interface, so some specific.

G

Ok, so I go back so different, so different operations from the regular interstate require the system. If we could, because it's easy for request should not result in pita creation into out during the message transmission.

C

And the season.

G

For reprise must not be catchment allowed us, because it's something like a measurement to and the for march past support allowed us should not leave me the pit entry created by city. I have requests on the timeout bar expired. This is a unique point. This means that, even though you receive the one request, if you request amount fully, you want to fully discover the potential pass for getting the some specific content. Then your pit entry cannot be removable. So, of course, there is timeout body.

G

So, finally, that some message may be discarded, according because of the timer as expiration, but there is a timer, so you can have the potential to receive a multiple requests or replies from upstream louder's. Well, I understand this is a good point to discuss so can I go.

F

G

So, first the questions.

F

I mean this seems to me like, like a unique opportunity for an attack. I mean this. Is a nice attack vector to to flood the pit? Isn't it.

H

Maybe um so similar vein, but maybe a more positive cast, making this a separate message, type means you don't necessarily have to do resource allocation. The way you would for interest data exchanges, which means the fact that you're breaking flow balance, allows us to rethink how we do the resource allocation for doing these operations. um One thing you really like to know when the request message arrives: it's what's the worst case number of reply, messages that might come back.

H

mmm Do you have something in the request message that bounds that, because, if you had that the resource allocator could keep track of just how much bandwidth is could might be needed on the reverse direction to return the replies. Have you given any thought to that.

G

So I think there are several not definitive but several solution. One. The simple solution is something like a later limiting, so you can just vary some apollomon you can stop. Even though there is someone something like a bogus to be pry happened, then the love digest can discard everything and he doesn't need to reply back to consumer.

H

Yeah, the problem: we should talk offline about the problem with the scheme like that, because if you want to do that, these these messages now have to be way lower precedence for bandwidth than normal interest data exchanges, which means they won't work when you need them the best. But most let's go talk about the other.

G

Fly again, okay, but in general my feeling that laid control can help something, and also some if we have some doubts, something like a bailout, a verification mechanism inside this protocol, then maybe bogus traffic can be also discarded so but anyway. So this is a very detailed, so I want to go the next right. So this is a really important discussion point and one of the important open issues, so maybe I will back to that kind of discussion.

C

G

Expect that this kind of discussion happens here so I already mentioned that so how we can enabling multiple support the legally as a default. So the CCNA in for message exchange is behave as behave as something like ordinary interest and data communicate data communication, because CCNA will request as a default comprise with the strategy and season user. You use a could trace the actual boarding pass. So usually if the strategy allows a single pass, even though some router has a multiple fever entries toward some specific content.

G

Finally, the the consumer. They see with a single data, because pit entry was already removed so regularly. If we follow that kind of regular behavior, then we don't eliminate some program, but as option we should have some potential to capture the whole potential voiding pass information or the potential cashing places. Someone may want to retrieve such kind of information, so as an option. We should have some capability to allow that getting the multiple little apply toward the to consumer and port information. So this is also okay, just keep it today and discussions.

G

So there are several. So this is a initial button of such craft and I know. There are several open issues and the discussion do we need to discuss so, especially for March discovery, and this one is also a little bit of details, so we can just skip and no no go back, go back yes and the neighbor modification. So actually, as an academic paper, we already published how the neighbor can verify each other without having something like a CA, so something like I, say central management system.

G

So we already published a paper transaction network science and engineering, but and I may have a chance to refer this paper for the Levi's draft or.

C

G

Is really useful? We also have a plan to submit as a different or another document internet draft and we can discuss more and, as maybe you have a lot of a discussion. So please keep in touch and let's start the discussion, and if we have some interesting, the comment and I'm really happy to hear and okay. So today I'm happy to announce our new implementation.

G

We call civil- and this is a software platform enabling CC and based communications. It's open source written in C, so you can just ask access to HTTP, safe or not net or just capture this QR code. Now, then, you can vote no.

G

So there are several interesting function that interesting implementation functions to be implemented, and it's a there is a to demo. Simple consists of two main demo is: definitely this is affording them its basic demo and there's ICS monitor. This is a separated daemon, which support enables the content store and since F initely itself is the right weight and it can just connect to CS, monitor D via UNIX, socket or T, are TCP socket and also usually I. Hope.

G

The many researchers or engineer want to develop their original implementation, but they are usually I, don't know usually, but some many times don't need to care the pit management or fit management itself. So, for example, if we, some of the researcher engineer, want to develop the caching algorithm replacement, algorithm or some other algorithm or transport mechanism allow demon, they can all implement as a separate plugin liabilities.

G

So plugging lava is just built in the sample, 780 or CS manager D, and they can extended easily there and create their own CCN communication between blocks, and there are several operational tools. Your keys are also supported and also, of course, the second safe point is. This is a CC and info already implemented so next page. So this is a very, very simple demo, so we just capture the screen and CCN of people. Ccn : rush, newness science- and this is topology consumers here and published here, and that this is route route in cash.

G

So and we set up a 10 millisecond delay for each and then the consumer center request and toward along the feeb, and then the seasoning for request is alive that are 5, then out of 5 reply back toward the consumer, so this is a one-way da. He can see you can see, and this is round-trip time and there is a cashier information here and this content is so the sizes and cob and how many interests he received and what kind of a chunk here is stored and the expiration time and so on.

G

And this is a so someone just want to trace the network condition and he doesn't care, for example, caching, condition, and he would know the march past condition instead. So in that case, consumer here and the cache is there r2 and r4, and this request message is transmitted and toward art were the publisher. But actually the album is split.

G

The request message and the once request message is sent to toward r2 and once the request message sent twelve feet, maybe or alpha or some somewhere here and finally, are the 2 and alpha reply back to see. So he received the two messages after he received two messages. So why is from Delta 2 and the other is route from route of all and each has a RT key.

G

So this is a final site, so season 4 is compatible with CC and extra format and it's a powerful network to providing various information, and it's already provided in c4 support surface. Of course it's really ongoing until there are maybe lots of back I know, but we have been working for to mature the quality and we are really sure that we need to others many open issues, but maybe step by step, and we revise the ID and the comments is always welcome. Thank you, fantastic. That was.

N

A nice surprise, I have one question happy concerning the scope. Writing some kind of scorpion.

G

Yes, yes, actually, the our specification already mentioned about something like a expanding link, search, something like expanding advancing exists, so you'd image the hop count and then the new, your request must be stopped at that hop count and or operatory. If you already know the caching information within, let's say the NEX, the small network with which is, for example, our hop count is 3, but you don't know that from 3 to pop count, 5 for example, then you can specify a boundary between 3 and 5. Then you can search the three and five.

G

How many caches are located for your content, so it's already specified and our implementation already support this one. Thank you. We need.

A

A little heavy support here and I think so. I just checked the license for c4. That seems to be the special and I should heal Eisen. But it's like permissive and mighty license like BSD.

G

Second close to so it's a very a circle.

G

C

Can copy modify? Yes, it's.

A

Very right right.

G

A

Okay, so why are we getting set up again here and so Dave is not going to talk about ping and traceroute, so.

H

We're running a bit behind one time, so I'm going to do this at Lightspeed. Some of you have seen this work before it fell into kind of a.

H

Hibernating state, but now that the the research group has gotten interested in really moving forward on management, instrumentation tools, we kind of brought it back. What happened this screen? Okay? So on our view- and you toshi-san and- and some of us have talked about this- a lot is that there isn't a one-size-fits-all instrumentation and management tool for things.

H

Ccn info is kind of your big toolbox that can do a whole lot of things and get really rich information back from from the elements and in a nice en network, the ping and traceroute are much more like at least conceptually the equivalent IP world tools, which is their intended to be extremely lightweight and usable by end-users, to at least get some sense of how things are working. So my the contention is where's. The free button.

A

H

H

Is that we need some lightweight tools for troubleshooting before employing more heavyweight heavy-duty tools like CCN info you'll, see that these have a very different kind of target and a very different kind of approach to how they're done so. The first of these is ping, and you can think I, pee style ping in your brain is your mental model for this?

H

What we want to be able to do with ICN, since it's a richer architecture in many ways than IP is to get information back about the the targets of requests in an an ICN world. So the questions we'd like to ask with this is, is a particular ICN forward or reachable is a producer application reachable and is a cached object on the path to a particular can produce err, reachable and in the process of doing multiple of these just like we can do in the IP world.

H

You can run several of these and to get some statistics like average and and dispersion on round-trip times. So one of the things we note here is that if you want to talk about the forwarder since we're in a and routing by name environment for ICN, you need to give names to the things you want to route to. So in this case we're not necessarily interested just in getting to application objects. But we need to talk about the forward errs, which means forwarders need names now, I would claim independent of any of these particular tools.

H

You don't have a manageable network at all unless the the forwarders have names on their own, so these can either be globally routable under the name of their administrator or use some kind of forwarding hint within an administrative domain in order to get to the forwarder.

H

What we've seen in the IP world is that some operators don't like to externalize the names of their internal resources, because it for one reason or another, may open them to outside attack or competitive analysis of how their theorem domain is working, but at any rate, the forwarder names need to be known in some way.

H

The second question is: is an application producer reachable so we'd like to discover the forwarder that has the local connectivity, in other words, in the same system instance with the application and then because we support caching and ICN we'd like to be able to cut off one of these exchanges and answer that there's a cached version of a particular object that is available on path at a particular forwarder.

H

The other thing we'd like to be able to do- and this comes up in the CCN info context as well- is to be able to do our TT measurements in the presence of multipath. This is this is a generally difficult problem. Some of us have tackled it in the context of trying to do multipath congestion control, so we basically adopt the same since the same group of people who designed both we adopt sort of the same overall approach to doing this.

H

So we use a path ID identifier in the data message package and then presume that this path steering work. That's been going around in the research community for the last couple of years. We can import into here and use path. Steering to steer ping messages over particular paths. The way you obtain these path, IDs is, you can do path, discovery.

H

The actual packet encoding is an echo request and an echo reply. Now. The interesting thing in the CCN architecture is remember. We have both message types and packet types. The message type for this is still an interest message, but the packet type is echo request, an echo reply, and this allows us to emulate the actual forwarding, behavior of interests and data messages. Almost exactly a couple.

H

Just minor points, which is the user, can direct this directly to get further management administrative information, so the information coming back can be used as the target name for doing a CCN info style, deeper query of the network and, of course, replies need to be signed here in order to avoid any kind of reflection, attacks, so I'm in the interest of time I'm going to skip some of this, it's all in the it's all in the draft and move quickly on to trace route.

H

Now, what we did with trace route is remember in the IP world, trace route is done with exactly the same packet type as ping. It's a echo Qwest echo reply packet, it's just the processing is different. We follow a similar architecture here, but there's some differences, so we'd like to know what the path of the forwarder is: what's the path to a producer application and what are the pads to cached objects, so we want instead of just getting reply. Is it there?

H

We want to look at what the paths are and do hop-by-hop RTT measurements on paths, so the differences here from an encoding standpoint is we have two new packet types, although again it's an interesting response and the core message: core mechanism is what came up just a few minutes ago that it's an expanding ring broadcast. So we use hop limit expiry in order to explore the the diverging paths, as would have been done with with IP trace route. The same way and that's it I'm done comments on the drafts they've been adopted by the RG.

H

We we hope to progress them forward.

C

Over the next few.

H

Months and potentially get them get them to last call thank.

A

You you can stay there and do net me. ah Yes,.

H

Okay and now for something completely different, so there's some work, that's been going on primarily at Cisco I, don't work for Cisco anymore. In case people haven't noticed, but I still collaborate with the team there on a number of things, this being one of them, so since none of them can make it here today, I've been sort of called into service to present their drafts. So this is not my work. This is their work.

H

So what? What is what is map they do very quickly before I go into? The updates is ICN needs mechanisms to support producer mobility. Consumer mobility is kind of naturally built in to the CCN and Indian architectures. We don't need to talk about it much when you do producer mobility on a mobile network. There are only a few feasible ways to do this. You can do anchored mobility with a with reflection point back in the network.

H

You can try to make your routing protocols converge so fast that you can track directly via routing the movement of a producer or you can design some kind of custom mechanism and map. Me is kind of a compromise custom mechanism. It assumes that your routing can converge reasonably fast, meaning in some small number of seconds, so this creates volatile state that allows you to track producers and deal with their mobility during the time that the routing is rican verging. So this draft has been around for a little while there is Cisco IPR on it.

H

I think that's mentioned somewhere, but I'll mention it right off on the top, so I won't present the whole draft. Obviously, in the interest of time and people can read it, but there have been a few changes since the last time we went through this. The first is that the the original spec had sort of like a full-blown retransmission management scheme, so it had its own kind of transport protocol properties for the control messages that were going back and forth between the the diversion elements that did the the bypass routing. These have been simplified considerably.

H

It turns out, didn't need all those mechanisms after building it and trying it out a bit. Secondly, there was some assumptions in the in the previous version of the draft. Was that what you were talking to as an output face was simply a layer, 2 mobile network interface to the to them to a mobile network? This this scheme obviously has much more broad applicability to that. So the descriptions have been broadened to deal with any type of face, including tunnels IP. You know IP tunnels, UDP tunnels, any kind of tunnel so that that's been expanded.

H

Last time there was a whether it was in Cambridge or previous meeting. We had a presentation on the socket interface that has been designed for H, ICN and potentially other ICN flavors, and it's now this scheme is now implemented for that that socket interface, so it the code that you get is workable with the with the socket interface that that's been provided by Cisco for H ICN. So where we are here, is that, despite the name of the document, it's been missin aimed originally and the chairs had.

H

You know too busy to worry about that too much. This is not yet an RG adopted draft, even though it's named as if it were, although it's marked in the data tracker correctly um we'd like more feedback where the authors would like more feedback from the from the IC energy community find out whether other people are interested in taking the implementation and using it for various things and see about we'll talk more about adoption of this and whether it's a good idea at in Prague. Thank you thanks a lot Dave.

A

If we're doing this quickly yeah, so we think this is a nice useful mechanism that could help us loose the mobility in some scenarios. Please have a look and let us know, and that the other us know what you think, all right, so we're moving on Robbie is next update on the ICN IOT draft.

I

So this draft has been in this group for some time, so the basic goal of this draft is I mean it is a modern information. In fact, so the idea is to basically present how ICN it would be a good kind of network stack for those to have to serve several IOT applications and so I. What I'm I mean since it's been there.

I

I hope people who are interested would have gone through it at least once and so I'll not go into the history of the draft I search, but just focus on the changes that we are made.

I

So primarily we have cut down on the authors list so primarily to the set of authors who have been actively contributing to the draft and we have wrote a tight H and who's been contributing now.

I

So this is the primarily the table of content of the draft. I could spend some time, so the basic idea is to, as I said, tries to motivate ICN for IOT and I think it kind of resonates with the kind of points that Simon brought out saying that you know I see IOT networks, family information sentiment. They just producing information, so all you need from an IOT network is to get that piece of information or if you can talk in terms of a consumer publisher model, it is fundamentally the same so so in this.

I

What we try to do is to primarily in section 3, is to identify some of the general requirements of from an IOT perspective, so in terms of naming security, privacy and so and so forth. Then then we in section 4. We basically talk about how the current architectures failed to scale primarily because I mean you know.

I

Iot is it's a plethora of stacks there, and so primarily, this huge set of interoperability issues all the age issues a final fundamentally handled later, the application get to a level, and that's a basic point that this section four brings out and then section five is where we talk about how the different constructs of ICN can be used to meet the requirements of the things that we mentioned in section 3 and the different design choices you could make within ICN to meet those requirements so yeah. So that's about the the main meat of the trap.

I

So going into the into the changes that we did I mean mostly it is about. Most of it is very editorial. I mean there was some redundant discussion that we eliminated and some and we kind of moved some of the discussion into different to make it more relevant where we felt was. It was lying further out in the draft, so in section 2 we have the this. This section was kind of hidden somewhere in section I, think section 4 or something so pulled it up, and so then we then we have the Services scenario.

I

So initially that was kind of the section 2. So the main idea with services in are you again. You know IOT is a very siloed kind of an area so at what we provide, there is discussions with on specific scenarios and then see how ICN could help those specific scenarios. So then there was some discussion on naming where we had some discussion on particular.

I

This was the requirements kind of the part of the draft, so we had some specific solutions being discussed, so we eliminated that contextual communication in terms of long term short term context, and so this was there's some kind of we tried to merge kind of make the discussion more kind of seamless to read, and then some renaming of this section. So primarily this is the the main changes that we made to the trap and since we do not do it in the last IETF we plant, we were happy.

I

We wanted to bring this back so that people can have again a good view, review of it and provide as much feedback. So we had some feedback from Thomas on some references and we should I didn t trade, because I I thought we could get in more inputs before coming up with a new version. So so more comments and requested for this thing: Thanks yeah.

A

Thanks Ravi I mean if people have more ideas, please talk to Ravi.

A

That's okay thanks! So Thomas is next update on the low pen specification.

F

Okay, so this is just a brief update on on the low pen draft, which we have talked about a couple times. This has been recently adopted as a research group item, so it's the version 0 now again and what has been updated since the last.

F

The last version of this document is basically the CC annex, stateless compression schemes that haven't be hadn't been defined yet, and then we only had to find Indian and others a renaming. We then we use ICN Lok and as a name to make it more inclusive for the different ICN dialects and security considerations were added. Just a brief recap. What is the objective of this draft? First of all, may I say in lopen compliance or had defined a convergent layer for low power, lossy networks, in particular a two 2.15 for adapt.

F

The hello adapters to the link constraints of this low power loss in that word and then define a couple of compression schemes which are first of all, that stateless compression for the theories and second stateful compression and I come to this in a second stateless compression is basically about more efficient encoding and the omission of redundant information wherever possible, and that means first of all, we try to get the TV's to smaller, smaller encoding.

F

For instance, a boolean bit vector vector can be reduced to a bit and we also try to remove a lot of fields from the header wherever possible if if they are not needed, for instance, length if you have, if you are in a more or less confined scheme, then you can adjust this to fixed-length and you don't need the need to carry this also remove redundant header fields and there's an overview of the to understand. Missed that point, are you yeah.

F

Anyway of the two flavors Indian NCCN X, so what you see? What does grey here is the stuff that is basically attacked or or reduced by by the stateless compression. What we do is we use the 6lowpan dispatch fields which which are used, which I need it anyway, because we want to make the slope infantry they're compliant and we encode bits and that's the lower line here. We encode bits about about the presence of compressed fields.

F

According to the to the protocol, so what we see is- and the N is a bit leaner- see see an X has much many more options. So that means we have a longer dispatch field here.

F

So just giving you an idea how this looks so in ND n, we have this long type length value vector and that that can be reduced in for the simple example that you have an the name: ACM Boston, but yeah as you see there, then you see that we can can reduce this to to a shorter encoding here, and that was basically cutting out 18 bytes in this case, for the for the interest and for the CC annex interest in the same case, even cutting out even more, but it I mean the original.

F

The original encoding had been longer saiful compression. To recap. There two approaches: one is too similar to the the 6lowpan approach to put a context, specific state like prefixes or other stuff, in in common knowledge that is identified by the by context identifier. So you don't need to carry it in the packets because it will be redundantly communicated, for instance, common prefixes, common suffixes common options, and the second approach, which is that's unique to add to an ICN approach, is to replace the the names in the in the.

F

If you send an interest, you send a name, and if you reply to this, actually the name is replied again at you. You elide this name by, or we like this name by generating short-short local ID, so making it sort of a stateful hop compression. This has a following as a message, much stronger impact here.

F

So if you look at the the example of the interest, if you compress this only using the common prefix out and you're in the compression in this example by about 40 percent in the data case, where you omit the full name, then we are really down to to something that is very small, which is important. Just recap.

F

These these link layers have very short, NTU sizes, and it is a it's a real advantage if we can put packets or if you can can construct packets, that that fit into these small in sizes of 127 bytes or so so.

F

This was more or less to give the the overview and what we we are now at is we. We have a draft that has a sort of shape and we have. We want to stimulate a couple of discussions. First of all, the India and CCN X faults. So the question is: is this? Actually this were these other compressions, as you like? That is it? Does it meet me?

F

The the the the perspective of of the groups also question that some type and length restrictions in the compression, so names can be only a certain number of by its name components, and so on question is: is this okay?

F

Just to recap, we can always send uncompressed interest in data, so it doesn't mean that we are where we are doing onto the network, but if we, if we compress them, we have some restrictions and question is: are they feasible and do they actually match the common use cases? Are they actually that the useful things to do and in our call to the community is on the implementers? We are working on implementing stuff and we are originally started at the collaboration with the Indian Ooty team and you see a UCLA.

F

Actually, the Indian Ooty team was recently formed and the question is yeah: are we ready to implement this together and others to others? Are they willing to adopt this encode I mean making this code yeah and to all, of course, are we in line with hue, with key use cases, and or did we miss anything that is really relevant here? So please, please, speak speak up on this, and our next steps will be continue. Implementations get get more code, running, get more experiments, get more real experiences.

F

Get an implementation for the CC NX, which is for us, is just a pretty renew, and the question is: do we have any we only use of the CC and light so are there any other people willing to work on implementations for CC NX, and regarding the document I mean we are planning to have a major editorial improvement just to make this document more readable, make it better, and that should be soon.

F

That should probably be released way before the next IETF and then we are, of course, asking for feedback to get this in a finish in a contentious state with a research book. Yeah thanks that was it okay,.

A

Great thanks: are there any immediate answers to promises, questions.

L

So what could we say so we.

A

Need to do all I can like one or two revisions. Maybe get this done before Montreal will be. An optional depends a little bit. What.

F

The feedback is I, don't.

A

F

A

F

Very controversial feedback, then we have to deal with it. If we converge quickly, then yes.

A

Yes, okay, yeah sounds very good thanks. So just to put this into perspective- and this is a really interesting piece of work because it enables us to you know, run the semantics of ICN without translation was in say, convergence layer that is specifically adapting to the needs of constrained networks and very elegant way to basically have end-to-end as in communication on the semantic level, and maybe that's actually something that you guys want to look on before you lose work great thanks. So thanks a lot, everyone for you know being so good on the time.

A

So that gives me actually a chance to do little exam with you. So I hope you paid attention for the German speakers, after all, has no bite so in the beginning, I kind of try to give you this overview about the like the technical activities in icy.

C

A

And so, if you're a networking person, you will surely see that there's some essential piece missing for a comprehensive communication framework and it's supposed to do something useful anybody.

A

So we have packet forwarding service, we have technology, your management, you're thinking about apps mobility,.

A

What is still needed to prevent the collapse of the ICN internet.

A

H

A congestion control right.

A

So routing and congestion control, so it's not like there's no work on congestion control. There there's been really good work. It's just hasn't been brought to eyes the energy, so so in case you're. Looking for a way to make a you know dent in in ICN a nice energy, it could consider either one of those topics all right think that that was just a quick reminder. I wanted to communicate.

H

By the way, yeah both of those are careers, not projects.

A

Okay, great. That brings me to the end so yeah we are planning the upcoming meetings. So probably you will have the same set up in in Prague depends on, of course, a bit on what people bring to us and in previous year, not this year, but we are. We sometimes did it interim in January, so we haven't prepared anything yet, but if people want to do something host, something please talk to us.

A

Better, quick internment in Tokyo, not sure whether we can align with that but yep. Let.

H

Us know the default state is that the next time we meet will be in Prague yeah, so someone wants to meet sooner than that we'll work with you to arrange it and make it happen right. Okay,.

A

Thanks again for the good presentations and things.