Session Date/Time: 23 Jul 2026 07:00
[00:00:05] Eve Schooler: Hello. Yeah. It'll be easy. All you'll have to do is the clicker.
[00:00:08] Ali Rezaki: Oh, that's
[00:00:08] Michael Welzl: great to do. Nice.
[00:00:09] Eve Schooler: Nice to meet you.
[00:00:10] Andre: So
[00:00:12] Michael Welzl: let's pick the chair slides. And then we can get the slides. Mhmm. Although we need to click. Mean
[00:00:21] Chairperson: Would you like some water? Do you want water?
[00:00:24] Michael Welzl: I can my own control.
[00:00:30] Eve Schooler: Would you like some water?
[00:00:31] Michael Welzl: No. No. Thank you. Okay. Alright. Let's get started. It's the top of the hour.
[00:00:44] Ali Rezaki: Yep.
[00:00:44] Chairperson: Okay. Fine.
[00:00:45] Michael Welzl: Alright. Good morning, everybody. This is SustainG. Sustainability at the Internet research group, not proposed research group, as we will describe soon. Here's the note well, all the standard text. I'm not gonna read everything to you. I hope you've seen it before. Otherwise, you find it on the IETF and the RTF web pages. You agree to being recorded. You agree that everything you write and everything is gonna be made public. Thank you. And then we have RFCs to take a look at for further details. Yeah. More about recording. If you participate online in particular, yeah, as soon as you turn everything on, you're going to be filmed and recorded, and it's gonna be made available afterwards. There's a there are some rules about IPR disclosure. You need to, well, make it public, say that that there are IPRs timely, not much later. And, yeah, you can just read these rules. The IRTF, different from the IETF, focuses on long term research, not on standards. This is not immediately directly as it is a standards body. We're just associated with it. We can publish documents, experimental and information at once, but they go they got their own boilerplate. It's a special thing. We don't do standards directly. Yeah. Here are some links for people in case you have these slides open and want to click them.
[00:02:28] Eve Schooler: And I would encourage people who haven't logged in to the tool who are in the room to please use the local tool so that we capture that you were here. And then we know how big to size the room,
[00:02:41] Dave Oran: and we know
[00:02:41] Eve Schooler: how to reach you should we have follow-up. Thank you.
[00:02:44] Michael Welzl: Yeah. SustainG has a very detailed, very long, and very broad charter. Here is the very much shorter version, which is that we want to contribute to the advancement of the Internet as a fundamental part of of sustainable and resilient societies and the planet through conceptual and evidence based multidisciplinary research collaboration. So, again, the point is this is about research. Right? We welcome papers. We welcome research activities. You your turn. Yeah.
[00:03:22] Eve Schooler: Oh, I did want to also point out a number of interesting things. Our first three talks are by individuals who are PhD candidates, and at least a couple of whom are within about a year or even less, maybe weeks of graduating. So please make note for those of you looking for interesting people to join your research teams or if you wanna follow-up with them about their future plans.
[00:03:46] Michael Welzl: Okay. Yes. So the agenda is again, why would I read the agenda to people? You're to be here. You're going to experience the whole thing. Quite interesting. A group of a few talks focused on carbon, quite a few, actually. Then the sustainability, well known URI. We don't have a plan to adopt that as a document in this group. It's not a research activity per se, we believe. But we are giving this full twenty minute slot for discussion because towards publication, Andre is going to want to have our feedback. So would be great if you could take a look at that document and, you know, file find find an opinion and and state your opinion and be active in the discussion on that item in particular. And then we're gonna report back from a workshop that we organized just before this ITF meeting. Yeah. You'll see all that. It says Ali, Eve, and Michael, but there's also gonna be a slide by Marisol, and then there's also a slot file for Dirk. So this is one mistake in that side. Fiona?
[00:05:02] Eve Schooler: As many of you who are already on the email list know, we have quite a few participants who are good about sharing, pointers to readings, and we decided we would reward one of those people. So welcome to Hasham El Bakkuri who has been, you know, in some senses a curator of reading lists both in a previous email list called eImpact as well as our own. And so we've sort of elevated him to be this role that we've never had before, which is a librarian to help us keep track of the recommendations about readings. And we're not exactly sure on what form that will take, but it'll probably be a link somewhere off of our Wiki. But if you have thoughts on what that should look like, we would welcome them.
[00:05:54] Michael Welzl: Librarian is so much better than Wiki editor.
[00:06:00] Dave Oran: Okay.
[00:06:03] Michael Welzl: A quick status update. We had our group's exam. I keep calling it exam. I it's not an but we had an an IAB review where they look at the group and, you know, give us some feedback, and then we are told about the activity and what we're doing. And that wasn't really apparently formally the role of that meeting. But after that meeting, our has approved that we move on from being a proposed research group to a real one. And truly, we had we were in that special situation where in the agenda, for some reason, they kept writing us as as double proposed. Like, we're proposing to be a proposed group. We're not we're nothing. So just like Pinocchio wanted to be a real boy, we were really keen on being a real group. Now we're real. So Yeah. No. No. We're just taking the truth. Only truth here. That is it from us, and we can already
[00:07:00] Eve Schooler: We can begin with our first talk.
[00:07:03] Michael Welzl: Yes. Let's do that, which is
[00:07:09] Dhrupun: to the DNS.
[00:07:11] Michael Welzl: Yeah. Okay. Share slides.
[00:07:16] Eve Schooler: And, hopefully, you can see the your own slides down there.
[00:07:19] Mirsha Chakiri: Oh,
[00:07:19] Eve Schooler: yeah. And feel free to
[00:07:20] Ali Rezaki: Can you Yep. Click.
[00:07:22] Mirsha Chakiri: Thank you.
[00:07:23] Michael Welzl: Should have control.
[00:07:26] Mirsha Chakiri: Let adjust.
[00:07:27] Marisol Palmeir: Does it move?
[00:07:28] Eve Schooler: Oh, there you go.
[00:07:30] Ali Rezaki: Okay. Yeah. You have twenty minutes including questions.
[00:07:33] Michael Welzl: Are you are you starting the timer, or shall I?
[00:07:35] Ali Rezaki: Yep. Yeah. Okay.
[00:07:38] Chairperson: Timer doesn't show up here. It shows up there. Okay. Is the timer showing
[00:07:42] Laura: up there?
[00:07:42] Eve Schooler: Yes. It shows up down there as well. Okay.
[00:07:44] Mirsha Chakiri: Hello, everyone. Good morning. My name is Mirsha Chakiri. I'm a PG candidate at University of today 20. And, today, I'm going to, present our works on leveraging DNS for CarbonAware server selection. Well, as, you may already know, as the Internet scales, its, environmental impact scales as well. So now, the Internet increasingly depends on larger scale always on infrastructures, and the international agency, International Energy Agency reports that the data centers accounts for, 1.5% of the global electricity now, and it is projected to be more than doubled by, 2013, reaching out around 9,045 terawatt hour globally. And, this electricity consumption is not carbon neutral. So, the scientists, throughout recent years have been exploring paths for, decarbonization of the Internet. And one major direction is to use better of, electricity or use greener electricity. So prior prior works have studies integrating, green energy sources to the data centers or shifting workloads across time and place, to, reduce carbon footprint of the services or, in general, anything that is running on the data centers. And, also, there there's been some activities on reducing the data transmission itself by using either current BGP, add an extension to the BGP, or using alternatives such as path of eroding SIEM. However, while many hyperscalers use DNS to achieve geographical load balancing in their system, the potential of DNS, for, reducing the platform footprint of the services, has been unexplored. So as you can see, the carbon footprints, really depends on when and where you use the carbon you you use the electricity. So on the left hand side, you can see the profile of carbon intensity that's depends on the available generation sources. And as you can this is clearly can be seen that if you change your workload throughout the time, you can reduce the carbon impact of your workload. And this is also true for different geographical region because each each region depends on its own regional grid. So if you move the workload towards different regions, you can also make use of greener energies. So oh, the graphics doesn't work here, but what happens in in every client server connection is that every client, there should be a client here, uses a a DNS to look for a domain. And the DNS comes back with an other set, including, usually, a couple of IP addresses. And, from the studies, it is shown that, mostly users try to use the first IP address to get to connect to YouTube. I mean, the service that they want, in this case, YouTube. However, these services are geographically distributed nowadays, and these are the points of presence that we find through our measurements for YouTube, for example. And depending on which region you are in, the geographical GeoDNS would give you the results that are point of presence that's mostly closer to you. However, nowadays, even if in Europe, there are plenty of points of presence of YouTube close to each other, and this is also true for other, larger scale services as well. So, and, as we saw earlier, the each of these regions may have different carbon footprint due to the availability of the renewable energies. So the idea is that, again, the graphics doesn't work here. The idea is that if we are able to associate to each one of these return IP addresses, the site or the point of presence or the region of that IP address, then we can incorporate carbon awareness by adding carbon intensity value to each one of these IP addresses, and then we can, incorporate, carbon awareness into our decision making. And, so by re by redirecting the user to a site that has lower carbon intensity than the other, it will reduce carbon impact for the same amount of computation. So in order to quantify, the potential of, DNS based carbon server selection to reduce the carbon emission, we do a measurement to evaluate how much carbon we can reduce, and we also look into the network delay impact, load balancing, and we analyze the trades off between that. Other words, we want to evaluate how much we can save without, hurting the performance. So our measurements consists of oh, wow. I don't know why the image here is not always there's an image here, and it's not even sure.
[00:13:50] Eve Schooler: Just you can describe it.
[00:13:51] Mirsha Chakiri: Yeah. Okay. Yeah. There there's architecture of our measurements that also I will just describe it. So we we are using 255 globally distributed vantage points using Akita's architecture infrastructure that spreads about 46 countries. And we we send measurements from a terminal to the Arquipelago controller, then it distributes these measurements toward each each worker node, and then they perform first DNS queries to obtain the IP addresses on the region, so from their different resolvers. And then they do ping measurements to evaluate the network data toward each one of those IP addresses. And then after that, we, enrich this, data with IP geolocation from IP in for datasets, that updates daily. And then we we enrich the dataset again with carbon intensity data that is marginal carbon marginal operational carbon emission using what time API that provides five minutes granularity of the carbon intensity data per each region. So our measurements suit for four months, and it's consists of cycles of thirty nine minutes with one minutes deviation. That's because we don't interrupt the measurements. We we we just do some kind of synchronization in between, but in total, like, it takes about thirty nine minutes. We do these these measurements on 40 different domains, YouTube, Bing, TikTok, and United Nation websites. So we selected them because we wanted them to use geographical DNS based load balancing, not Anycast. And then, we try to select them in a way that they are using different, hyperscalers. And we also use, different resolvers to see the impact of selecting the DNS resolver. So in order to evaluate our outcomes, we compare each selection strategy by a baseline. So first, we establish a baseline that models the default behavior of the system. And by that, I mean, like, using the random selection from the resolved IP addresses. The single resolver greenest selects among the RSETs resolved by a single resolver, the the one that is the has the lowest carbon intensity. And then there is a multi resolver greenest that aggregates the data from all different resolvers that we are using, and then it selects the one that is lowest among all of them. And then finally, there's global greenness that is we we do that to to estimate theoretical upper bound, which is selecting the globally the greenest IP areas, which means gathering around all the information from all the vantage points. Well, so, again, we, there are CDFs there, so we go, towards, like
[00:17:23] Eve Schooler: Just so you know, we'll, we'll work to get the correct slide PDF version up on the web afterwards, so please have a look afterwards as well.
[00:17:32] Mirsha Chakiri: Yep. There should be some CDFs here to show the distribution of, carbon intensity value and RT to change. You'll see it later on the slide, but, I will move to, the scatter plots. Here, we have three different scatter plots, each, for, one of the IP selection strategies. So, first, we have single resolver strategy. And as you can see, we plots the carbon savings versus the RTD change for each points of the measurements. Here, each point here is the measurements, and you can also see the distribution of the savings and the RTD change here. So for the single resolver case, the the savings was kinda limited, and it went up to 17% depending on the domain. And you can see that here, the domains might have different profiles. And while while we move to the multi resolver greenness, the carbon saving increases substantially. However, we can still see that the RTD changes is still is still concentrated around zero, and it has a symmetrical shape. So it is more spread with respect to the single resolver case, but still it has, like, about one to two milliseconds on average change while it has a higher saving values. And but in the case of global greenest, the profile changes completely. We can see a very high savings, around 95 percent average. And then we can see that, however, the RTT distribution now is not around zero anymore. It shifts up to one hundred to hundred milliseconds. And to also analyze the difference between the resolvers, we plot the different carbon savings distribution for the resolvers. The main the key takeaway here is that selecting each resolver didn't, seem to have so much difference among them. But while we aggregate them, we can see that there's going to be, higher carbon savings. And this is also true for, RTT. So for RTT as well, different resolvers doesn't seem to be much different. But when you, change to all resolvers, there's, a bit more, like, desperation. Oh, no. This one is also not working. So we also do load balancing analysis in order to see that, how much our selection strategy affects the load balancing. In order to do that, we use approximation of IP level, selection frequency, with respect to the baseline. So we try to estimate that how many times this, IP is selected when you select it on baseline and how many times it's selected when you're selecting it using a carrier number strategy. So so in order to do that so, finally, we also do some analysis on the selection amplification, and we report the ninetieth percentile of that, which shows that in the case of bay in the case of single resolver, the selection amplification is, something about three times more on 90% of the IPs. And when we move towards multi resolver, it gets higher to nine times more workload on the selected IP addresses. That's criteria. And then but our like,
[00:21:31] Dave Oran: in
[00:21:31] Mirsha Chakiri: global greenness, the situation becomes really so it substantially increases the work workload on the greenest ones on, like, about 27 times more. And, also, the there there's not even that relation anymore between, like if if we plot them, like, do the scatter plots, you can actually see that's, other it changed the whole behavior of the base of of the, baseline selection. So overall, the DNS server selection can potentially, reduce the carbon emission without changing the infrastructure of the services and by by just, putting the the Carbon Ever Resolver between clients and the service infrastructure. Then we showed that the single resolver selection had modest saving, but it's it introduced a neglected network delay. You're also find numbers. I don't know why even the numbers are not shown here. But here, like, the delay impact is about, like, less than zero point one milliseconds. Then multi resolver, like, it it increases current savings while it has a minimal network overhead of, like, one or two milliseconds. And then but it hires a selection amplification to night time. And, then we have the global, we use as a theoretical upper bound, which is a nonconstrained selection of the IP addresses. It has a very high, savings. However, it has unacceptable level of latency, like, additional latency, which is about one hundred to two hundred milliseconds. So for many of the applications, it might not be usable. And then it also increases the load balancing to 27 times more. And here are some next steps that we are considering right now. We are implementing and evaluate the Carbonover DNS by implementing it in the real world and evaluating on the realistic mix of domains using actual query logs. And we we want to introduce carbonable TTL that implements and and CTL that adapts the prefetching or the caching time itself to due to the duration of the values and the, like, a common intensity, how how often it changes. And then we also we also intend to analyze the network path effects to study how green server selection changes the hop count or the different path that's the routing path that it takes. And then we finally also on the same parallel port, we are also identifying the original benefit, means, like because due to different so we have different point of presence in different parts of the board. So we we can, originally analyze that which parts, can better benefit from this server selection. Thank you. And I will be more than happy if you want to discuss it further, and here is my contact.
[00:25:08] Eve Schooler: Terrific.
[00:25:15] Michael Welzl: Somebody has explained in the chat that the PowerPoints are also uploaded, and you can download them. If you will download the PowerPoints, you do actually see all these images.
[00:25:26] Mirsha Chakiri: Okay. Great.
[00:25:26] Michael Welzl: And I'll try to see if I can make a PDF out of it. It's gonna be Yeah.
[00:25:32] Mirsha Chakiri: Yeah. I don't know it.
[00:25:33] Chairperson: Is the one who wrote on the text. I'm I'm converting PDF, and I will send to you about you can check the out.
[00:25:39] Mirsha Chakiri: You so much. Thank
[00:25:40] Ali Rezaki: you. That's
[00:25:41] Michael Welzl: Thanks a lot.
[00:25:46] Eve Schooler: Okay. Any any questions? Alright.
[00:25:54] Michael Welzl: Okay. Okay.
[00:25:55] Chairperson: Wonderful. Thank you so much. Thank you. How
[00:26:06] Michael Welzl: do I take it back to control first and then Yeah. Stop the slides and then share the slides. Yeah. I get to this and click this, and I think we should be good. Yes.
[00:26:25] Sou San: Alright. Hello, everyone. I'm Sou San. I'm a final year PhD student at Oxford. And today, I want to present to you our newly published paper in SigMatrix, which is about assessing the carbon footprint of traffic flows. So today, billions of digital activities are happening on the Internet from video streaming to gaming to cloud applications, and they all consume energy and generate carbon emissions. Now the problem is that users have no visibility into the carbon footprint of their activities. And while the emissions related to the compute part are increasingly studied, the network part remains difficult to quantify, and there is no standards to get this application level emissions of the network. And our goal in this work is to estimate the, network carbon emissions at the flow level. So why is accounting for the network, emissions hard? There are many challenges. One is, like, every flow is passing through multiple routers and autonomous systems. Another challenge is that these routers differ in power efficiency. So one router can be consuming more energy than the other. Furthermore, the source of this energy is also different between different routers. So one, location can have green energy, whereas another one can have fossil fuels. And then most importantly is that traffic is mixed, which makes the attribution per flow even more challenging. So the goal in this work is to estimate the per flow carbon emissions using only existing mechanisms and hardware. Now, fortunately, routers already have some counters that can expose interface utilization packet draws, but also traffic statistics. And at the same time, the measure of how green is energy at every location, which is called carbon intensity, is increasingly available through API. And our mechanism combines both, approaches to get the per flow carbon emissions. So starting with the router part, the first step in this work is to be able to convert the traffic statistics into power consumption. So the first step is to derive a router power model using existing counters. And here, I want to clarify that in this work, we focused on the switch ASIC. So I will be using the the terms switches and routers interchangeably as modern devices can support both functionality simultaneously. So we revisited the router power modeling experimentally using three different types of routers in our lab. They are picked to have the same size, which is 32 times 100 g links, and they have different target applications. So for example, one has programmability, one has low latency, which is better for AI training, and another that has deep buffering, which is better for core networks. And here, this is just a sample of the results that we got from the power measurement study, and you are welcome to check more results in the paper. So, in this, figure, you can see that, we are reporting the throughput. Okay. This is the throughput that we read from the switch counters, and this is the power of the switch that we are reading from power distribution units, PDUs. And what we're doing is this is for synthetic traffic that has a single packet size, and we vary the packet size from 64 bytes to 1,500 bytes. And we are checking at different throughput levels, so at 20%, 50%, 80%. Now in terms of results, like, obviously, the power increases with higher throughput. For the smaller packet sizes, have higher power, obviously, because we have a higher packet rate. And we have some packet rate limits for small packet sizes, and an interesting result was to see some power jumps at specific, packet sizes. And, for example, for router one, this is at two forty bytes and four forty bytes. And what's happening here is, increasing the packet size by just one byte resulted in a power jump of up to six watts or even 12 watts in a different router. And this is due to data bus misalignment where we have underutilization for the last few bytes of a packet. Now we also have these power measurements for some real traces from Kaida and from Google services. But, yeah, you you are welcome to see it in the in the paper. So based on these measurements, we want to model the power of the routers. Now the question is how complex the model should be. And for this, we evaluated different, models, like regression models, tree based models, and some others like neural networks. And surprisingly, while the linear regression model was found to be the best one in terms of, accuracy, like, the determination score was more than 96% over all the traces, and other more complex models did not improve this value. It was, like, kind of also, like, overfitting for some for the real traces. And the linear regression model is can be easily implemented on the router with low overhead, and the the form is either power plus alpha times throughput plus beta times packet rate. And the value of alpha would be in watts per bits per second, and the value of beta would be watts per packs per second. So now this formula or this model is just at the router level, and the next step is to extend it to the flow level. So we want to be able to attribute this router power and carbon to individual flows. And here, we have a distinction between two types. So if we look at this part, which is the dynamic power of the router, and this is the result of processing the traffic flows, and here, we will be calling it or it it will be linked with consequential emissions of flows. And as the name suggests, this is the result of processing these flows. Whereas for the idle power of the router, which is independent of the traffic flows, this one would be linked with attributional emissions. And here, well, the other power is there regardless of processing the flows or not, but one can argue that, well, this router is kept on. It cannot it cannot be turned off because it is waiting for these flows to come and to be able to process them as soon as they come. So this idle power can also be attributed to the individual flows. Now how to attribute it or divide it among flows? This is a policy decision. Do we want to do it equally among flows? Is it based on the bit rate? Do we account for the router utilization? All of these are a policy decision that, well, the community needs to discuss and to say, well, maybe the other power should just be this the responsibility of the ISP. So this is something, like, people should be agree on one definition for it. And as you will see later, this will make, like, a big difference in the scale of the attributional emissions. Now the third step in this work was to collect the carbon trace of the flows because this flow has a whole path, and we want to be able to collect these metrics. And in this paper, we discussed three different tracing options, and each has a different application and benefit, I would say. The first one was to have in network telemetry. So if an application wants to optimize its performance based on the telemetry that it gets, then the correct approach here is to have the in network telemetry where it can send some telemetry packet every thirty minutes, or I would discuss this, and it can get the aggregate carbon metrics of the whole path. Now how frequently to send this telemetry packet? It really depends on how frequently the carbon density changes. Is it, like, this is typically every 30 minutes, but also whenever the, network, conditions change. And this can be based on, like, on a threshold. Another option is to have packet level tracing. Now this one has obviously more overhead, but on average, that would be less than 1% for the packets. And here, like, every packet, whenever it's processed by the router, you can add to it the carbon metric, but this should be an aggregate value. Otherwise, if you add it per hope, then it the overhead will be much bigger. Now another option, which doesn't have any overhead, is the ISP level tracing. And here, because the ISP is already collecting some logs for maybe billing purposes, and the traffic feature can be added into the system. And an example here would be, for example, Netflix asking an ISP, like, what is the carbon footprint of my traffic or the traffic of my users? And in this case, the ISP would be monitoring Netflix traffic accordingly, maybe for a fee. So this is just one option. So to get a sense of scale of this of these models, we also have a use case simulation using NS three, and we have this code on GitHub so that people can also experiment with other use cases other than video streaming. But this is available on GitHub. And in this in the paper, we use the British telecom topology, the BT topology, which has more than a thousand nodes and 3,000 links. And the traffic pattern would be streaming from the caches that are collocated with metro nodes to all other nodes in the system. And we consider different video qualities like HD, full HD, and ultra HD. Now this simulation complements our measurement study because it gives a sense of, like, how the flows are mixed at large at a large scale simulation and also because we have the diversity in the carbon intensity at a national scale. So for example, in The UK here, we have 14 different regions, and we consider the carbon intensity variation in these regions. Now in terms of results, very briefly, we have more results in the paper. This here, this is the CDF of the consequential emissions, and we divide them based on the video quality. Now, obviously, if you want to watch the video at a higher quality, then the consequential emissions will be higher, and this is what you see here in the yellow line. But this is the consequential emissions. For attributional emissions, as I said, because we have different definitions, then the scale will be really, really different. So in black, this is in black here. Okay. Okay. In black, you have the consequential emissions, but the ones in green and blue, these are all different estimates based on the different definitions of the attributional emissions. And you need to notice here that this is a log scale. So we here, we see, like, two orders of magnitudes difference. And this highlights the need for a standardized carbon accounting for the flow level emissions. So in summary, the high level takeaways of the study are, first, accurate flow level carbon tracing is feasible, and it only requires access to the existing router counters. We have the different definitions or different scopes of the emissions of flows. We have consequential attributional emissions, and these differ by orders of magnitude. And that's why we need a standard framework for network carbon accounting. And finally, from the simulation results, we can see that using average carbon values, like the carbon per gigabyte or something, what that people are using is inaccurate and is unreliable. A final note is that we had some ongoing work on deploying this on a national UK test bot, which is the Joiner platform, which allowed us to to also have these measurements on a different variety of routers. And, yeah, the code and benchmark are available on GitHub. So here, you can see the the GitHub repos. This is for the current paper, but also for our previous works on carbon aware routing and carbon aware scheduling. And this is the paper from Sigmetrics, but also we have an Internet draft that we submitted, like, few weeks ago, which is based on this paper, but it's more like how people would implement this and how they extend it. And I want to highlight also that, like, the way we did the measurements, we also wrote it as, like, a proposed benchmark that people are also welcome to test maybe, maybe in a hackathon or something. We can we can discuss this further. Yeah. And I'm happy to take your questions.
[00:39:45] Dave Oran: Hi. Thanks, Dave. Work. Really curious question. Did you see any asymmetric routing, or were all these paths symmetric? Because if it's asymmetric routing, you have to figure out what's happening on the forward path and the reverse path separately.
[00:40:00] Sou San: You mean in the simulation?
[00:40:02] Dave Oran: No. Well, in in any of the measurements you did.
[00:40:05] Sou San: So in the In
[00:40:06] Dave Oran: other words, did any of these real the real flows actually experience asymmetric routing?
[00:40:11] Sou San: No. So for the setup of the measurements, we used a snake configuration where all the ports of the switch are forwarding the traffic. And this allow us, like, to be able to push the switch to a very high utilization level to be able actually to see the difference in the power. So all the ports are actually working. So we we checked if we have an asymmetry in terms of pipelines, but we didn't see that.
[00:40:40] Dave Oran: I mean, on the whole route, the an asymmetric route where the the in the flow, the flow packets going toward the server are over one path, and the packets coming back from the server, the user over a different path?
[00:40:51] Sou San: So we the pattern, as I said, it's from all the metro nodes into all other paths. So we have a very variety of paths in this simulation. But we did we yeah. Actually, we we have the reverse path included in the flow estimation. So but we didn't separate them. We didn't separate them.
[00:41:14] Dave Oran: Didn't separate. Okay. Thank you.
[00:41:17] Michael Welzl: Yeah. Hey.
[00:41:18] Juukumann: Good good presentation, Juukumann. Can you go back to the for for the power consumption measurements you had here?
[00:41:25] Ali Rezaki: Yeah.
[00:41:25] Chairperson: Sure.
[00:41:28] Andre: Are you in the queue?
[00:41:29] Eve Schooler: Are you in the queue?
[00:41:30] Michael Welzl: It didn't go to the
[00:41:32] Dhrupun: that's that's okay. That's can
[00:41:33] Eve Schooler: you say your name for the for the
[00:41:35] Sou San: This one?
[00:41:36] Juukumann: Because what I was looking at is at at pretty much idle.
[00:41:40] Eve Schooler: Yeah. I know him, but the the audio consumption
[00:41:44] Juukumann: and then based on the throughput, I mean, the change in the power consumption based on the throughput is pretty much
[00:41:50] Michael Welzl: No. No.
[00:41:52] Luis: Is it throughput?
[00:41:55] Sou San: Yeah. So maybe I have the I have a different figure, but less
[00:42:00] Juukumann: side is doesn't doesn't mean that the throughput is the at the zero throughput, you still have a high high consumption. Right?
[00:42:08] Sou San: Yeah. So, for example, at zero throughput yes. Yes. So, for example, this is for the other routers that we have as well. Yeah. The idle was, like, one thirty four watts, one eighty watts, and two thirty six watts, which is really high. But, also, the dynamic range is not small, so it's not negligible as well.
[00:42:24] Juukumann: Yeah. So, effectively, what matters the kind of the volume of traffic doesn't really matter in the big picture. What matters is where you are routing your packets.
[00:42:33] Sou San: Well, it depends on the scope that you want to look at. So, for example, if for the consequential emissions, like, that are the direct impact of your flow, you will see you will look at the dynamic range. But if you want to look at the attributional, which is based on the idle power, then, yes, it can it can be more than an order of magnitude bigger than the consequential emissions. Yes.
[00:42:56] Juukumann: Yeah. Yeah. So in that sense, your formula, then what matches is the first part Yeah. Effectively. And then the load based is, you know, microscopic in a big picture.
[00:43:06] Sou San: It's not microscopic, but it's like well, definitely, the idle is still high.
[00:43:11] Michael Welzl: Yes. Yeah. Okay. Thanks. You're welcome.
[00:43:16] Marwan Fayed: Hi, Seveson. Marwan Fayed, Cloudflare. So just a a a comment. Because I can imagine as people start to make these arrangements and communicate data back and forth, there's a who's lying, who's trying to compete. Right? So one of the things that might be interesting to think about going forward is reporting, and in particular, some sort of shared or reporting mechanism. Because these are you can imagine these are commercially sensitive numbers, and and networks wouldn't want them to leak. At the ITF, there's work on privacy preserving measurement, which is designed specifically to measure things that people just otherwise can't without without us safely. And later this year at SIGCOM, I believe there's a logging, zero knowledge proof logging mechanism that's being proposed. Still requires, I think, some truth, but I can imagine as this becomes more important, third parties will want to get involved in helping to monitor and create markets and so on and so forth. And so it might be worth thinking about, like, how is this done outside of the path or between the two parties.
[00:44:16] Sou San: Yep. Yeah. Definitely. And I want to add also a comment because here, what we want is to have an aggregate value of the carbon metrics. Because if you want to have it per hope, then, clear. This will be, like, this will violate, like, privacy issues and these things, ISPs would not be willing to expose this information. Yeah. So that's also a different scope of this work. Yes.
[00:44:37] Michael Welzl: Thank you.
[00:44:37] Marisol Palmeir: Thank you.
[00:44:38] Michael Welzl: Great work.
[00:44:42] Sou San: Yes?
[00:44:44] Dirk Kutscher: Luis? Is
[00:44:45] Chairperson: there anyone else in
[00:44:46] Michael Welzl: the Yeah. Luis?
[00:44:47] Ali Rezaki: Yeah. Yeah.
[00:44:51] Dirk Kutscher: Thanks, Sam.
[00:44:52] Luis: Interesting. One question here. The the routers that you saw, are all of them monolithic routers? So are not those modular routers? Because that that could introduce another variable. So regarding the the car that you go through, the interface, and so on so far. I was wondering if in the this joiner infrastructure, you will play with that kind of modular routers. Or
[00:45:14] Sou San: It was also similar kind of routers.
[00:45:17] Luis: The monolithic ones.
[00:45:18] Sou San: Yeah. Yeah. But also, like, if you want to maybe one way is to include all the other variants into the idle power that you then divide among all the other flows, but this is just one way.
[00:45:31] Luis: But there will be a dependency where the flow is delivered through the card and so forth. But my point is that maybe
[00:45:38] Sou San: Yes.
[00:45:38] Luis: Yes. Be considered as well for for that other kind of router that will be more present in the backbone and and so on.
[00:45:44] Dave Oran: Thank you.
[00:45:45] Sou San: Yeah. Thank you.
[00:45:48] Michael Welzl: Okay. Next person will be me. I frankly didn't fully understand why you say you need to have access to the counters of routers. Would that be the traffic counters for getting throughput?
[00:46:03] Sou San: Oh, so the whole point is so that you don't need a power distribution unit in all for all the routers in the system because putting these into the ISPs would be very expensive. And instead of that, from the counters that are already existing, you can, from the power model, then infer the power. Okay. So you don't need
[00:46:23] Michael Welzl: the The reason I don't understand why you need the counters at all is because I mean, my understanding from the beginning was that this is about a user wanting to get an idea about its own flow. Mhmm. Now the user can measure that end to end. You would see your own packet rate. You know the size of your packets. You know your throughput. And the model is linear. Right? So that would allow you to tell your your share of the whole thing.
[00:46:46] Sou San: But the metric that you want to collect along the path also depends on the network conditions that you read from the counters. Like, the current throughput, the, like, the current number of flows at the at at a certain router. So you need to get this
[00:47:03] Ali Rezaki: But
[00:47:03] Sou San: at every hope.
[00:47:04] Michael Welzl: But when it's linear, do you?
[00:47:07] Sou San: Yeah. I mean, the metrics
[00:47:09] Michael Welzl: Okay. Yep. Yeah. We can
[00:47:10] Sou San: Especially for the attribution report.
[00:47:13] Michael Welzl: Oh, okay.
[00:47:13] Sou San: I would say.
[00:47:15] Andre: Right.
[00:47:17] Eve Schooler: Yes.
[00:47:18] Tony Lee: Hi. Tony Lee, HPE. Talking back about chip power consumption. My rule of thumb is that static power is about 80% of power consumption, And so it would make a lot of sense for us to focus on optimizing the 80%, not the 20%.
[00:47:38] Sou San: Yep. Well
[00:47:45] Marisol Palmeir: Hello. Marissa Palmeir, Independent. Thank you, Susan, for all the work that you are putting together. I I don't know if you plan to continue on this work. One of the things that is coming to my mind about the either power and how you attribute as well, temperature is also important as a condition. I don't know if you have that kind of data to be considered in your model as well. And another thing about the flow, you know the starting point of the flow, the endpoint, but it's crossing across different ISPs. Then this attribution is relative, right, to to one ISP. But it depends on the location, how you translate that in carbon, and the complexity can be kind of big. And one last thing I would like you to be, Jan is taking care of the controller. He's going to lead the controller work in the green working group. It will be really good as well to have your feedback on that work. Okay. Yeah. Yeah. Sure.
[00:48:48] Ali Rezaki: Thanks very much,
[00:48:49] Sou San: Thank you.
[00:48:50] Dhrupun: Okay. Thank you.
[00:48:57] Michael Welzl: Alright. That brings us to the next.
[00:49:01] Mirsha Chakiri: How do I how do
[00:49:01] Michael Welzl: I take take back control? I'm learning it. Stopping.
[00:49:17] Dhrupun: Hi. Can everybody hear me?
[00:49:20] Michael Welzl: Yeah. Yeah.
[00:49:21] Dhrupun: Oh, yeah. Okay. Yeah. So thank you, everyone. So I'm Dhrupun. I'm the study, a DPU students from the University of Oxford. And today, I'm gonna present my work in our fridges, enabling dynamic freaking scaling on network switches through public routing. So today's network consumed 240 to 340 terabyte of electricity globally, and this number account for 1.3% of the global electricity demand and is growing 30% annually. Like, in the meanwhile, we have the guys such as NetZero and also the Paris agreement to force us to reduce the power consumption and the carbon emissions. So in this situation, it's very important to reduce power consumption of the whole network. And as one of the most important component within the network, the power consumption of the network switch actually counts for a significant portion. And we found that, actually, there's a a issue that raised the network switch power consumptions. And this issue is that the power for the network switch is not proportionate to their performance. So as you can see on the figure, the red line is the ideal condition. So if there is a 100% server, then we consume 100% of the power. If there's zero traffic, means the network switch has stopped working, that issues consume zero power. But in the real situation, the the network switch power consumption is blue line. So even though this through zero traffic, it still consumes about 80% of the power. So it also shows on the result from source and slides. And this is because the network switch is designed to work in twenty four seven and max man call frequency to cope with those unfinished ball network traffic. So this makes it still consume significant cover even as their traffic load because they need to it it don't know when do the traffic count, so it it can just, like, working all the time at the maximum call frequency to make sure you you won't have the low processing performance and avoid the packet loss. So to to save this problem, obviously, to improve the public efficiency for the network switches, good ways to use dynamic frequency scaling, which is DFS in short. And DFS is actually a low power design technique that dynamically adjusts the clock frequency of a chip based on its current workload and is based on this equation. So p is the power and f is the frequency. So if you reduce the frequency, then the power should be also reduced linearly. And this technique has been successfully applied on CPU, GPU, and CGI and many other chips. However, when we're trying to implement this technique on the networks, which we found three challenges. So the first one is the unpredictable workload as I just mentioned on the last slide. So on the network switch, on on each single network switch, we don't know when will the traffic will arrive. We don't know how much will the traffic arrive. So everything is unknown. Like, we we can't predict the future. So so we can't, like, do in the very timely call frequency on the network switch. And the second problem is a severe consequence of packet loss. Like, on the networks, we should be able to avoid the packet loss. Otherwise, it will cause, like, trans retransmission or even increase the delay. And so there's a strict requirements of resource and the latency overhead. So for the work workloads problem, we we found a way to show that is to use the carbon routing. So carbon routing is a routing strategy that aims to identify the past with the lowest carbon emissions by leveraging carbon intensity. And the carbon routing can do the pest recoagulation at interval fifteen to sixty minutes, and it can also deactivate and use links through carbon biotraffic engineering. And covering routing gave us the opportunity to know, like, how many traffic will come to to the network switch at next time interval and also kinda let us know how many ports you can shut down for next time interval. So just imagine if your network switch have four ports, and the government routing announced you that two of the ports can be shut down at next time interval because there will be no traffic going through at those two ports. So at that situation, you can just easily switch your call frequency to half of the maximum. In that situation, you still have enough processing performance to to process all the packet, and you can save the power. So the final result is what we draw on the figure. So the red line is the rail network traffic, and the blue line is the network traffic we predicted based on the network based on the common routing. And although we we can't accurately predict the the whole red line, but we can create a roughy line just bond the traffic. So this has to make the DFS effectively working on the network switch and save a lot of the power. So based on all these things, we propose our new architecture, NetFridgeS, The whole architecture based on the NetFPGA plus platform and the green measure is shown on the wall diagram is added by NetFridgeS. It leverage common routing. As you can see on the right, we got common routing controller, So it calculates everything relative with the camera routing. It introduced the concept of freezing pipeline. So as you can see, inside the pipeline, like, this blue pipeline, I I actually cut it into several segments, and we insert the inner buffer between two of the segments. So freezing the pipeline means when the whole network switch working normally, the buffer is just a buffer. So segment one pass the packet to buffer and then buffer pass the packet to segment two. It won't affect anything. And when we want to during the frequent switching, we want to keep all the packet within the pipeline. We we we we don't want to drop the drop the packets. So we stored the packets within the segment one just to the inner buffer rather than pass it to segment two. So this can make sure we doing the frequent solution quicker. And, there's the auto buffer to isolate the pipeline with the MAC. So when we're doing the frequent solution, the pipeline can't process any packets. And, also, we don't want to drop any packets. And as this is situation, if the packet comes through, we just the only thing we can do is just to store them in the auto buffer. And by using the inner buffer and the auto buffer, we can ensure that they're packet loss and also the seven microsecond frequency switching delay. To evaluate our architecture, we apply this net fridges to three different network switch architecture. So the first one is reference switches, say, standard l two forwarding and Mac learning network switch. And the second is NRG is a two to simulate the data center network environment. And third is mentioned mentioned is a programmable switch network programmable switch with the isolation function. And the results shows our pipeline propagation delay increased by only thirty four nanosecond, and this is mainly because we insert those auto buffer between the MAC and pipeline, and the auto buffer is asynchronized five forty. It it replaced the originally synchronized five forty. It just introduced some more delay. And, also, we keep the pipeline functionality and throughput unchanged, and we achieve negligible resource where we have this zero packet loss. And to the power saving, which is a most important thing we care about. So as you can see on the figure, it's very clear. So our orange line is the original architecture, and the green line is the architecture we proposed. And it's very obvious the green line achieves better power proportionality. And to this and, specifically, we can achieve up to a 78% reduction in power, and this reduced 47% pipeline power consumption and the lowest lowest with only 0.35% additional power consumption to the pipeline at maximum throughput. And all of this happens within the one hundred and twenty seven milliseconds frequency switching time. And this frequency switching time is actually the maximum. So if you doing the frequency switching to to the frequency higher than the lowest frequency, then you can achieve the frequency switching time much lower than this one. And to evaluate the effectiveness of our architecture within the real network, we simulate it in two real world network topology. So the first one is gAnt It's an education now European network, and the second is British Telecom. And the the result shows we can achieve up to a 22% reduction in overall energy consumption and up to a 28% reduction in carbon emissions. And, also, we evaluate the cost of applying our architecture to high performance measures, such as Intel, Broadcom, and video Cisco. And with the result also shows that the cost is less than 1% of memory source. And, also, we can still shipping sub microseconds level for frequent and switching. Yep. So to the summary, in this work, we propose a new architecture that enables efficient DFS on network switches through leverage common routing, and we achieve several microsecond frequent switching. We can reduce fiber consumption by up to 78% and the minimum throughput. And, also, we reduced carbon emission by 27% in real network topology with negligible overhead. And finally, one thing I just want to mention is that this work is we already applied the pattern for this work. So if your company interest is in this work and want to apply that on your product, please feel free to contact me. So that's it. Thanks so much.
[01:01:16] Chairperson: Anyone in the queue? No.
[01:01:18] Eve Schooler: Okay. I have a question. Thank you for a great talk, Dhrupun. I'm curious about two things. The first is I know that there's, you know, part of what makes this work is that you have access to Kate, the Carbonware traffic engineering work that is basically carbon aware routing, and it allows you to predict what the load is gonna be. Are there other mechanisms in the network that might also give you that capability, to decouple you from the dependency on Kate? Are there other ways to predict the the loads? So,
[01:01:57] Dhrupun: another scenario I can think about is, like, within the data center. Of course, like, you know, it stays, like, machine learning, all sort of things. Their traffic is very predictable, so you can't know the links status before you really run the machine learning training or inferencing. So I think if you use an app for just inside the data centers, you can, like, still beneficial even with all the case.
[01:02:22] Eve Schooler: Great. And, kind of a follow on question to that is, so what next for this work? Do you have any sense of, where you wanna take it? Do have some ideas about next steps?
[01:02:34] Dhrupun: So because I I currently have another work on working on the, like, new architecture for high, throughput network speech. So it, after that, we can, like, combine this two, like, apply this one to to to the architecture and try if we can working with even higher surface on the, like, network speech.
[01:02:57] Eve Schooler: Great. Thank you again.
[01:03:00] Dhrupun: Yeah. Thanks so much.
[01:03:02] Ali Rezaki: Thank you.
[01:03:08] Michael Welzl: That's very interesting stuff. Alright. Now we come to Malorie.
[01:03:16] Chairperson: Oh, and
[01:03:17] Eve Schooler: Malorie is remote.
[01:03:19] Michael Welzl: Oh, yeah. I wasn't
[01:03:20] Eve Schooler: We didn't real hi, Malorie.
[01:03:22] Mallory Knodel: Hi. Hi. Sorry. I couldn't be with you in Vienna.
[01:03:29] Michael Welzl: I was also surprised. I thought you that's okay.
[01:03:34] Mallory Knodel: Yeah. I hope it's okay. Lovely. Great. Okay. Thanks so much for, giving me a short amount of time to introduce this draft. It's been, around for a couple of years now. I think once the IETF and IAB had a had a workshop on this topic, it seems to me that there was a ton of focus on energy as we've seen, from the excellent presentations already this morning. There is so much work to be done in this area. It seems like an interesting exercise to try to actually, though, look at all of the different dimensions of sustain environmental sustainability, and and not dwell on any single one too much, but just try to have a draft that did the exercise of going very broad, and allow others, point and point the direction towards projects that could then take these questions deeper. So I thank my coauthors, Chris Adams and Michelle Thorne, both from the Green Webb Foundation who've contributed to this draft. So I've sort of already set this up a little bit in my introduction to what this draft is trying to do, and you can certainly read, the summary of the abstract here. But in general, what we mean when we talk about, environmental sustainability issues beyond carbon are things like, you know, natural resources, the use of limited things with limited space, you know, even as so far as spectrum, not just land use and things like that. So, again, the goal was to actually, in the beginning, elaborate every single piece of every single environmental impact and then to move beyond that outline, which we we felt at some point was satisfactory satisfactorily broad, and then use this as a basis to do a comprehensive literature review in a way that could point researchers, to the existing literature or sorry, to point, you know, protocol developers and folks in this community to academic research and the existing literature on those things to learn more about them and to hopefully to seed new work in the IETF and IRTF. So we are in the second draft, I think, at least of this. I think there might have been a third draft, but it did make it into the data tracker. So the difference between this version and the original is that we now feel like we have a section by section survey of what all the impacts might be. So we talk about carbon a bit just like we do all the other things. We talk about land use, water use, spectrum, minerals, natural resources, and waste. And we've, in this version anyway, have at least for every section, at least one citation. Now it I think various feedback acknowledges that, it's not actually comprehensive enough yet and wait for it. That'll be towards the end. So we do want some additional work and thinking on this for from this group if if we could get it. We have a an actual principal section. So it's not just a survey. It really does then try to draw in some principles to, actually start mitigating this situation. So that's new. That's a new section. We have a few reasons or pieces of motivation in the introduction. We recently added in this sort of, you know, ESG framing just to be, I think, consistent across the industry. And so that's also new. It's it's a brief mention at this point since the draft isn't terribly long at this point. We've had a couple feedback rounds from the community. And I think I already mentioned this, but it was, yeah, from the original IAB workshop on on these issues. Okay. So just briefly to give you an idea of what's there, you can obviously read the draft fairly quickly, but we consider land usage. So, you know, not just not just on Earth, actually. We think about space as well and things like also in the sea. Right? So under sea cables and things. So we we try to think about space, spatial spatial impacts. Ecosystems, we do talk about the impact on, you know, animal populations, that sort of thing. Water use is really big in data centers as as well and throughout, really, the sustainability considerations, water water shows up quite a bit. Spectrum is something that we considered, somewhat related, to space. It's certainly related to satellites, but it is a limited resource, and we want to talk about how, you know, it is something that has an impact. There's a lot of mineral usage in the construction of, you know, networking equipment, and the continued mining thereof, and waste as well. We wanted to do a full life cycle. So e waste being a a really quite major, global issue is also considered. These are this is just an overview of what the guiding principles we use are. This these these very short descriptions, I realize, don't give you a lot of detail on what they mean, but I don't have enough time to go into each and every one of them. So I'll just keep it relatively, high level. You can certainly go look more. I think what the idea was that we wanted to give folks a sense that there was a way to move towards, solving some of these problems rather than just sort of cataloging a whole range of mistakes. That said, if, you know, Chris or Michelle are here, I think that this guiding principles is also, like, a really important part of advocacy. Right? And to, be able to offer some pathway forward for these problems. Whether or not these principles live only in this draft, for example, or might actually be better placed in other drafts, maybe as a sort of open question. But I was happy to welcome it in, because I do think that these principles, like, you know, within planetary boundaries, for example, I'll just call out that third principle, like, very much speaks to, I think, some of the content that we were able to uncover as we tried to do this broad survey of impacts. And so on my final slide, just, wanted to dwell a bit on where I think this document might go and how I think it could contribute to ongoing work. We, I think, have elaborated the categories thoroughly. Although, of course, one of the early asks was to folks to help us, think of things that we might have forgotten in terms of environmental impact. But now, really, the journey is what are the most authoritative sources on these kinds of impacts that we can point to? Now recognizing that a research project like this, it's in some ways kind of a summary of knowledge exercise, does not age well and sometimes needs to be redone. But putting that aside, I think what the value could be very helpful for folks in our community and in networking more broadly to have a sort of source list of places to go to look for what are the issues. So when we talk about, I don't know, depleted spectrum or we talk about the impact of undersea cables, you know, we've gone through the effort of elaborating where that research is being done, who the experts in the field are, and hopefully can point folks in the right direction. So I will actually maybe stop there. You can look at the GitHub and certainly pull requests are welcome. We've been using the issue tracker quite extensively for this draft because of the way that it's been shaping up. But I wanted to, yeah, pause there because I see enough folks are in the queue that I didn't want the discussion in this section to run over into the next presenter's time. So I'm happy to to stop at this point.
[01:12:23] Eve Schooler: And we have a little bit of extra time. So
[01:12:25] Mallory Knodel: Oh, good.
[01:12:26] Eve Schooler: Let's definitely, work on the queue. Michael.
[01:12:31] Michael Welzl: Okay. Thank you very much for bringing this to sustain Sustainogy. I I think, I will say that the breadth of scope of this is extremely welcome here and that we are trying to not be a group that looks only at energy saving. However, I have to admit, I was a bit disappointed that your presentation now didn't really get into research ideas much or any proposals or suggestions on what could be done, which, again, I think is what the scope of this group should be. So to give you an example, I have myself been thinking a bit about embodied carbon of devices, but that would also relate to waste And that we could look at upgrade cycles of equipment that happened within service providers and consider that there could maybe be research ideas around bringing down the peak load that people are seeing. Mechanisms like pacing and so on could have an influence. We could investigate that, and that might possibly reduce waste. I don't know. This is just one particular personal idea. But what I was hoping is that this document could be sharing ideas like that or suggestions like that in the direction of, well, the many things that you that that you listed here. You know, water, air use, land use. I don't know. Like, all kinds of things. So did did you give some thought to these possible research directions?
[01:14:05] Mallory Knodel: Right. I mean, I feel that the document itself is a contained SOK in a lot of ways. So in that sense, it is a sort of limited use research project in and of itself. Whether or not the draft should elaborate on research questions, I'm open to adding those. Right? We could do a proper literature review that would be comprehensive across all of these. And then maybe in each subsection, we could then draw out future areas of work. If that if putting that in a in a draft or a a document is what this research group wants to do, I think that that's something that would make sense. Sure.
[01:14:54] Michael Welzl: I I would ask. I I mean, we haven't discussed that as a group of chairs, but as one chair, I would think this is a prerequisite for that being possibly adopted in the group.
[01:15:04] Andre: Yeah.
[01:15:06] Mallory Knodel: Sure. Yeah. I like I said, I think that this document is a research document. It is a like a like a summary of knowledge. Like, it's but, anyway, we what you decide is research is prerogative of chairs, obviously.
[01:15:26] Ali Rezaki: Well, that shouldn't sound like we are making, subjective decisions here. It is basically, as you said, drafts that, emerged during the e impact times. Right? You had presented the first version, if I'm not mistaken, over there. And I draw your attention also to certain terminology work that took place during the times of the impact, and those drafts also live on. And and there is significant work in ITUT study group five, as you might be aware. They define the broader, ICT sustainability space and create methodologies related to that. So that's a wonderful resource. And nowadays, they are looking into circularity, the nine hours, eleven hours. So, I think we have moved, on from the times that people only thought of energy or carbon, which is very encouraging to see for us. So what Michael says and what I support, is that we are now at a stage to come and say, okay. Now what are the actionable research questions that we can address, beyond the definitions? That's, that's the feedback. Thank you.
[01:17:03] Mallory Knodel: Thanks. Yep. And it's in those are referenced in my document, by the way, the ATUT work. Sure.
[01:17:13] Michael Welzl: We have Laura Laura.
[01:17:15] Laura: Hi, Mallory. This is Laura. I have a question.
[01:17:19] Eve Schooler: We can't hear you. Can you adjust the mic?
[01:17:23] Laura: Okay. It's better now?
[01:17:25] Michael Welzl: Yes.
[01:17:25] Laura: Okay. So I'm from Brazil, and I have a question, but just for context contextualize my question. Last year, we did a presentation on the topic of sustainability and green networking, and the water issue come along. And people asked it, but why are you so worried about water other in subjects other than capacity, the one you you said? And in Brazil, we have, like, huge data centers being built in regions that are not not don't have a abundant supply of water. And other than the supply, we have water pollution problems because these companies, they come to Brazil because we have or or how do you say it? Or environmental regulations are not that strong than they are in the North. So these companies, they can often take water from our water supply, and then they just use the water, and then they release the water back into the public system. And sometimes this water come back polluted. And and and, anyway, I said this in this meeting, and people did not believe me. They said, like, no. This is a polluting machine. Why a company would do that? And it raised among me and my colleagues the the issue that people, from Europe and not not North America, they are not even aware that, we are going through this problem at, I don't know, Brazil and other places. They're not the focus of the the sustainability efforts. So this the water pollution issue is just an example. And what I wanted to ask you is if you think that this draft is appropriate is an appropriate place for us to add these considerations because I think we we need to talk about the the research challenges and so on, but we have several problems. Like, they are not visible for most of the community in the IETF. I'm sure the folks from Taiwan, the example you used, they also have similar problems. Like
[01:20:25] Chairperson: Okay.
[01:20:25] Laura: They I'm I'm not going to to talk more. Actually, that this is my question.
[01:20:31] Mallory Knodel: Sorry. Short answer is yes. There is a focus on pollution in the draft throughout. I mean, pollution can happen in sort of all of these different realms. So, certainly, I think
[01:20:48] Laura: No. But I don't mean pollution. Like, a pollution was an example.
[01:20:52] Eve Schooler: We need to begin the next talk.
[01:20:55] Sou San: Oh, sorry.
[01:20:56] Eve Schooler: I So if you could just be concise and clarify, and then we'll move on, and we'll continue the conversation and the
[01:21:02] Laura: Of course. No. The pollution was not my it was just an example. I meant, like, the in the in the general, the things that are going on in less third world countries, I didn't want to
[01:21:17] Eve Schooler: Yes.
[01:21:18] Mallory Knodel: I would not say that this draft is focused on North America. I think that this draft is meant to be very comprehensive. And so recognizing that environmental impacts are disproportionately in global south developing countries, it would make sense to have a lot of citations of research from those areas. So if folks have any suggestions for adding additional citations on any of the various topics, I welcome that. Thanks very much.
[01:21:51] Sou San: Take care.
[01:21:51] Laura: I'd love to contribute then. Thank you.
[01:21:54] Michael Welzl: Thanks. Thank you.
[01:21:57] Ali Rezaki: Dave, did you want to say something? No.
[01:22:00] Michael Welzl: He has already stepped out of the queue. In the chat. That's okay. Thank you very much. People should take a look at this draft and give feedback to Malorie and use the mailing list. And with that
[01:22:14] Ali Rezaki: Thanks. Thanks, Malorie.
[01:22:16] Michael Welzl: Yeah. Thank you, Malorie. Indeed. I'm trying to give I think it did already. Yeah. Alright. So with that, I hand over to Andre.
[01:22:36] Andre: Hello, everyone. From Romania presenting remotely. Thank you for having me here. As a disclaimer, so this is my independent individual work. I'm not affiliated with any organization. I was trying to develop an Internet draft for an informational RFC on something that I found, that is missing. So unlike my former presenters, this is rated, like, on the application layer, like, presentation of of the for the information of sustainability. So not on the lower levels of measuring that information, but on the front facing. So that in one sentence is the well known sustain sustainability URI, which I meant to be, like, a unique and universal location, which should be well known for sustainability data. First version with a minimal, schema, which should be both backwards and forward compatible for the future for publishing any kind of information and the numbers and the verification links so that they could be verified and any extensible fields for any vendor or any other entity that wants to report anything, like an organization, an origin website or a device or a service or anything on an HTTP origin. So that includes on a website, on a blockchain gateway, and anything else that provides an HTTP endpoint. So, basically, this first slide covers the whole presentation. This is what it defines, and it's not limited to once where that is published, so to that web server, to that. So an organization can also publish the organizational level figures in line with the regulations that might be implemented or not in several countries or regions, like EU, CSRD reporting, and any other precedents and to be compatible with, revised work like, greenhouse, protocol and any other for blockchains for for chains. Alright. So the goal is to have a single discoverable location, minimal machine, which is a standard. And a competitive schema that could be applied for, basically, any sustainability reporting. As a non goal, so there's no measurements included, no load levels, no attestations within this actual link and the result on this link or the JSON the actual JSON at this link. And does not replace anything else, but it's what I found that is missing at the moment. There has been just one previous content, which was related mostly to the h HTTP headers, But I found any such available link. By design, it should be Web Ready API and machine to machine so to be easily consumed. This comes from my background, which is in software engineering and development, web development. It also should be human in the poll and ready for the future for the AI and the agents
[01:26:53] Michael Welzl: and so on.
[01:26:57] Andre: The problem that why we need this is because I think, like, the same group already knows and the working group, Green, there are all kinds of draft or kind of technical that publish this data, but it is not it's fragmented. And organizations are so like the one I worked before, which was very grid conscious, so to say, that, published each year. So each scope, scope one, scope two, scope three, we had as employees. We need to make those surveys about how we go to work and stuff like that. And in in yearly, they would present this organizational sustainability report. But for these organizations, there's no way to present it somewhere very clearly somewhere on the Internet. So the gap is the publication, sometimes measurements, and sometimes no universally known location to publish. You would find on the GitHub all the architecture schemas that I the diagrams and the images that I have there because I implemented the software as well. And there would be this there'll be clients, and there will be the server or which can be used on each web server, and then there there will be the publishers. And among the publishers, we can use we would have a Versal translator, which would use any existing so there is Microsoft Sustainability Manager, for example, from where organizations publish their bid. There is Salesforce as well and so on. What they should be metadata from the routers and published anywhere else. So this would be translated universally to the schema that I had proposed here, and this would be published in that well known sustainability URL. There is some existing work, like from the Greenwood Foundation, for example, which has a similar carbon.txt, And I spoke also with about it. So they are complementary because they had this disclosure in it. So, also, the schema has it. They can work both ways. So they would be published here in the schema and also to measure the estimate with the c o two. This is a basic look at the schema. Just now I'm working on the third version. So if I get get there some some input from sustain group or from anywhere else from working g green group, I got from the mailing list or I tried to address everything so that I would have this schema that would have these metrics would be validated. And to make it future compatible, I I kept only a few mandatory fields, and the rest are optional. Oh, that's right. And the target would be any kind of target for this which published this data. Also, it can have some parameters for, like, time series and queries, but this would be cached. So, basically, it's just a versioned file of sustainability. So it's not an API. It's just a version sustainability file, but, which can cache data, in time series and other paths or other ways. The data model is also published on GitHub. It would have only a basic document JSON that I showed you before. And after that, the the extensions from the any other vendor or any other sustainability issues, for example, like Mallory said before in the presentation, there is a lot of data that in the future would be addressed by sustainability issues. This would be published in the extension. The software that currently exists related to this draft and this schema would be allowed to be published in five different topologies so that it covers everything. And now it's already deployed. You can see it on GitHub if you want. There's a standalone gateway server. It can be used there are two libraries published can be translated to other languages, meterwares that can be used in existing servers or as a proxy before any web server like Apache or NGINX. Static files can be published, like I said before, organizational sustainability published as static files, and they they would be the schema would would be translated and served directly to this sustainability URI. And any other modern serverless edge functions and any other scenario for any kind of consumer, like humans, browsers, end to end aggregators, and AI agents. These are just the basic security and privacy model that I've seen its practice in in RFCs of this time. And more than this, what's different is that I have 1% deviation of the real value so that an attacker or not, for a certain period of time, cannot cannot detect the the usage of energy of that target so that it it can attack use it in a different kind of scenario security scenario. That that's what different than the rest of the are just basic security used in other AFCs. The running code, you can check it on GitHub. There's a universal translator that is the schema and publishes on the well known sustainability. There are libraries tested. Here's just an example of Salesforce NSC NSC where their kind of records, we can translate any kind of schema, let's say, any kind of published format JSON or something else could be used by this gateway or any other gateway and be transforming this final result. What I tried to do, I tried to to present this to working group, Green, and also thank you to the chairs of Sustain that accepted this presentation. And the previous version, I I posted it with with Yana and with the independent submission stream editors as an informational AFC. But my main questions, I'm not the ones in this slide, is if anyone knows how this would be adopted and by which group where would this kind of work would belong, in which group to be adopted, or if I continue with my independence submission. And if anything, like, anywhere from from any other groups, like, because it's a research group and would know even better how how this could become an universal schema, for example, to be sufficient, like, to have an information on LFC which would be sufficient. If you already have the data because you have done all this work on all kinds of sustainability energy and carbon consume carbon emitting and energy consuming. So you you would probably know better from the how how this schema would be and the the backwards and forwards compatible, how it could be easily I mean, it is easily extensible because it is just a a new section, which should be valid even if the RFC is frozen. So this would be an information on RFC, and it will be frozen without And then these are my questions for the sustain group. And if sustain group also has other questions at the end. Then I have this
[01:36:01] Michael Welzl: My apologies. Sorry, Andre. It it's up to you. You can go on, but please be aware that the discussion is part of your time slot. And probably the discussion is the most valuable thing for you here.
[01:36:13] Mirsha Chakiri: So up to you.
[01:36:14] Michael Welzl: I mean, you can go on or maybe stop.
[01:36:17] Andre: Yes. I I'm stopping here. So this is the scheme. That's all. So that's why I'm getting back maybe to the questions. So, yeah, that's those were my questions, and if sustain has any recommendation or suggestion or questions or anything. And thank you.
[01:36:37] Michael Welzl: Okay. Thank you. I put myself in the queue first actually to try and clarify exactly what you asked for. So we had a conversation among the chairs, and we don't think that we had a right home for that because it's not a research document. This is really engineering. I believe, but that is without personal experience with that particular thing. So maybe Dirk could step in or somebody who knows better in case I'm wrong. But I personally think you're on the right track with independent submission. What happened is that we got a notification from the independent submission editor that we might be one of the groups that has the right expertise to give you some feedback. So I think the correct procedure forward is to discuss feedback here, have some feedback here, get it also on the mailing list. And with that feedback, try and go back to the independent stream pub publication. Yes.
[01:37:34] Luis: Thank you.
[01:37:37] Michael Welzl: Okay. Okay.
[01:37:40] Juukumann: Yeah. Juuk, come on, Ner.
[01:37:42] Eve Schooler: We cannot hear you.
[01:37:43] Juukumann: Yeah. Thank you. Let's go.
[01:37:45] Michael Welzl: You're too tall. Become smaller.
[01:37:49] Juukumann: Let's try this better. Yeah. Thanks for the interesting presentation. My maybe my main concern is that you are presenting an answer, but I don't know what the question is. So I'm kind of missing the the kind of why statement that why would any web service, you know, provide want to provide that, you know, potential future regulation is maybe a bit far from the, you know, need today. Second question so I have three questions. Second is where would you where the service provider get all those items in your data model, which is very extensive? And then maybe the third one is that if you consider modern web pages, you know, you have hundred and hundred, 150, 200 objects coming from all around the world on from various CDNs. Then how would that work when you have a 100 different objects coming from a hun you know, various places, dynamically allocated advertisements, and stuff like that? So how would that work in the first place?
[01:38:52] Michael Welzl: Thanks. Okay. Thank you.
[01:38:55] Andre: So first, the why is mostly the regulation on the fragmentary telemetry that is so for organization to actually have a place to report so it's not only about the website, but an organization to to publish their yearly report. That there is already use here, SRD, which is will be required. I think this month, they they lowered the the so they need to companies with over 1,000 employees and so on. In July 2026, they they entered this regulation. So it's actually mandatory. So that's the why. And then the schema is it's the basic schema is very simple. So anyone would go to that organization, would go to the their web server and would see the schema where they have the URIs for the methodology and the publication of results. The rest of the schema is meant it's optional. So that is the answer to the to this question. So just basic metrics or a new array to where they actually have this published. And the third question, I think, yeah, it may not apply to all those fragmented. It it is an aggregate an aggregated, well known URI for that. So each individual, web server could publish their own, like carbon.txt does. So it would be implemented as carbontxt does now from the Green West Foundation. Anyone else could publish the ACI score, like a software or API score or anything else because it's compatible with that. And the rest could be aggregated, so they would just publish a current organizational sustainability report. So those are the answers to those three questions.
[01:40:58] Chairperson: Very good. So I'm Jan Lindblad, and you asked earlier where you would want to take this group, this work. And I think the group that is, in my mind, least, most suitable is the green working group. Similar questions are being discussed there on the same sort of level of concreteness. So that's my recommendation. Also, in order if you if you're interested in making this fly well at the ITF, we have some, conventions when it comes to modeling languages and stuff like that. So we use the Yang language for modeling stuff a lot. And if you're interested in modeling this also in Yang, I mean, you don't need to give up your existing model, but also modeling it in Yang, I can probably help with that.
[01:41:42] Andre: Thank you. Yes. That also was my opinion. I'll try to to push it there also to to work in Green Group.
[01:41:54] Jan Lindblad: It's me. Right?
[01:41:55] Michael Welzl: Yes. Yes. You
[01:41:57] Mirsha Chakiri: are
[01:41:57] Michael Welzl: a bit
[01:41:57] Jan Lindblad: As the developers, I'm I'm co chair of Green precisely. Somehow, Jan has spoiled what I wanted to to say. Though, I this as it is right now, this model this model, this this proposal, etcetera, is a little bit on the fringe of the of the current green charter. For sure, this is the kind of work that could be discussed there. Whether it could be right now with the current charter suitable to be adopted is something that we should have to discuss. And probably, the guidance that Jan has provided would would help in in making it more edible by the by the Green Group.
[01:42:42] Andre: Thank you very much. And that's all. This is an at the upper layer. Like, I've seen the work in the presentation from the green groups. And this is the upper layer. So it's the front end front facing parts, the the HTTP layer, the the application layer, where we could aggregate all the other layers from the green framework, which was presented on the young models and everything else, which actually does the measurements. But this is only for front end application layer. So it's on the the Yeah. The upper. And then the current existing working green group work that I have seen because I'm not familiar with all of the work.
[01:43:23] Michael Welzl: Okay. I hope that helped you. Again, you know, please feel free to comment some more on the mailing list on this work.
[01:43:34] Andre: Yes, sir.
[01:43:35] Michael Welzl: Alright. And with that, we'll to you green or the independent stream of whatever you call. Good luck.
[01:43:41] Chairperson: But thank
[01:43:41] Eve Schooler: you very much for your interesting and and thought provoking comment presentation.
[01:43:45] Michael Welzl: Indeed. Absolutely. Thank you very much. Okay.
[01:43:57] Eve Schooler: So we're gonna discuss now the workshop that was held last week. We have a little less time than we scheduled, so everybody who's part of the presentation, let's just keep it brief. It's it's meant to be more informational. So, and we will have a follow on, when we write up the report for the workshop.
[01:44:20] Michael Welzl: Okay. Do you want me to have
[01:44:22] Eve Schooler: Sure. I'll start. I'll start. Okay. So just for context, as some of you know, back in 2022, the IAB, sponsored a a workshop that was called eImpact, which led to a very prolific email list, which then spawned green and spawned this, research group. And, that was followed by a series of workshops related to the topic of eImpact, which was the environmental impact of Internet technologies. The first being a carbon aware networking workshop, the second being a Dagstuhl seminar on greening networking towards net zero Internet or something like that. Our research group proposed proposed research group was launched. Oh, but then this Passau we call it the Passau workshop because as you'll see on the next slide, if you could go to the next slide.
[01:45:17] Dhrupun: Yes.
[01:45:17] Eve Schooler: We we were inspired by the participation of Hermann de Meer in the Dagstuhl seminar and invite him to come in here, he gave a two part talk last year, exactly a year ago. And so as a consequence of that, as someone who does energy informatics and focuses on the power grid but is also quite knowledgeable in networking, we decided to jointly organize this workshop. And it was called the Internet Meets the Electricity Grid, Technical Standards and Societal Challenges. It included three keynotes, one invited talk, three panel discussions, and, obviously, the most important was a discussion on next steps. We also visited Germany's largest manufacturer of energy storage systems, and that's our group there, both local and remote.
[01:46:11] Michael Welzl: Alright. Yeah. So we had a total of 32 participants plus one invited remote talk. That's not the one person you saw in the picture. That person was actually a normal official participant, but, yeah, couldn't come for for medical reasons. There there were 23 academics, 10 industry participants, four early career attendees. And among the whole list of participants, 28 were from Europe slash UK, four from The US, and one from China. Maybe you can guess who that would be. Our old boss.
[01:46:54] Eve Schooler: Then
[01:46:57] Michael Welzl: we yeah. We we no. This is a list of like, if you if you add these numbers up, it's gonna be more than the participants because this is this is including overlaps. We just we identified 17 people that we would classify as ITFers and six as not typical ITF participants but network experts, seven that were representing electricity grid, energy or power engineering, five combined networking grid experts, people that basically worked in both fields, five of them from the policy end and one sociologist. So we did make an effort to this is why I was invite invitation only also. We really made an effort to, well, not have all of us from the ITF get together in another place and do the same thing again, but instead bring electricity people there. That's a geographical picture of where people were from. Then, yeah, we had a you know, this is just the the briefest of overview of of of what happened. But, again, as Yves said, we will have a real report. We had a very nice keynote on internetification. Well, so the basic scheme was that we had panel discussions that were informed by a keynote that happened before it on that specific topic. So that first keynote was on communication, energy supply systems, interlinking worlds causing complexity. I will have to say that we had so many people coming to us afterwards saying this was the best keynote ever It was really, really great. And we I asked workshop participants if they were okay with sharing the slides online by next week. And I can already confirm that, that keynote speaker has already said yes. So I have them, and I will put we will during next week, we will put slides online so you can see at least slides of what happened, and these are pretty interesting in this case. And then also, you know, we discussed ways of making the grid more dynamic. We called it intensification of the electric grid. It seems to be that shifting energy instead of power and doing things more dynamically with the use of battery storage seems to be the way forward in the long term for the grid in any case. And there's some interesting research going on in this. Then there was a
[01:49:24] Chairperson: It's also
[01:49:24] Michael Welzl: Oh, yeah. Yeah. Okay. Then we had gratification of the Internet on the other side of things that will be how we can use information from the grid within the Internet to do interesting things there, like some of the things we've heard here as well. And then a debriefing on the workshop that happened that was specifically about, well, data centers, really, compute energy nexus and
[01:49:49] Sou San: Yeah.
[01:49:50] Eve Schooler: I did wanna say that that was an interesting even though it was about data centers, one of the things that interested us about it was their methodology for drawing people from different communities and getting the right people in the room. And and also the fact that, you know, we were trying to tease out what are the differences between getting people together who were regionally near each other versus having a more international group as well as the contrast with us looking at standards versus them looking sort of more broadly.
[01:50:23] Michael Welzl: And by the way, with these kinds of slides, we're not trying to hide who who the people were. We're just trying to make it more readable. All you need to do is click on the link. The issue is that the panel discussion, for instance, we had four talks within the panel discussions with names listed, with titles listed in some cases, with, like, you know, many, many, many names that the whole thing would be cluttered. If you want to see who, you know, who was there and who's who who participated where, you'd all you know, click the link on the top, and you get to the program where you see it all. Yeah. Then we had this social technical panel on the next morning with a keynote on Sirius Solarpunk, social technical method for sustainable energy Internet infrastructure, and then discussions around the reality check on implication of the co design of the Internet and grid futures. And Yves is burning to say something, I can tell No.
[01:51:15] Eve Schooler: All good.
[01:51:15] Michael Welzl: Okay. I'll answer it.
[01:51:17] Eve Schooler: Ali?
[01:51:17] Michael Welzl: You want to say. Yeah. Yeah.
[01:51:20] Ali Rezaki: Well, thanks. Indeed, this was part of the workshop that went beyond the engineering and technical questions, I would say, that it also showed us a methodology, an example of how sociotechnical research can be done. And indeed, there were implications for both the global North and global South, and we appreciated this additional interdisciplinary perspective. One comment I can say in terms of what we observed maybe is that there is a tension nowadays between the electricity grid and the ICT world in the context of AI data centers. And, indeed, this came out prominently and that, it is also a sociotechnical question that we should not ignore the communities, the surrounding economic, regulatory, governance issues. And there are implications, although data centers are not strictly the scope of networking, which we can learn from. So much to say about that, but let's move
[01:52:48] Michael Welzl: on. Right. So there was another panel on cross infrastructure measurement and signaling and discussion about next steps, which was, of course, the most important bit here. Here's an overview of outcomes and next steps, but I'm not going to tell you because Dirk is going to tell you better. Just a moment. One more slide, one extra slide before we get to Doug. And that will be Marisol, who would speak to this. This was one of the outcomes, like one of the potential outcomes that could happen. And you have one slide, one minute.
[01:53:20] Eve Schooler: One minute. Two tops.
[01:53:24] Marisol Palmeir: Yep. Basically, with basically, linking with everything that the church has been summarizing about the workshop, our brains start to work. Right? And, the communication collaboration as well, I think was there even in words for the moment. But, I believe there is an opportunity for the ITF group to collaborate with other standards organizations and looking into what we have been achieving for the networking or we are achieving or we are going to achieve for the networking part. The the proposal is is coming. Right? It's not yet proposed, but, it's an open collaboration, for everybody here. I have a window to I triple e. I'm working now for I triple e as an external consultant, But, here is the idea to collaborate in a liaison program because they have the distributors of the energy. They have the transport of the energy. The batteries is are there participating in I triple e. And if we could make this to work on with the use case, yes, at the high level, the the legal implications, the regulations, and the reports that needs to come now in real time measurements because they are asking for these hourly reports. I I think this could be a good step forward to do something from the idea as well as as a collaboration.
[01:54:55] Michael Welzl: Yeah. So please get in touch with Marisol. I think if you are willing to collaborate on this. And, otherwise, use the mailing list as well.
[01:55:03] Ali Rezaki: Yes. Feel free
[01:55:03] Michael Welzl: to use it. Mhmm. The next slide only says thank you, which is a thank you to Doug for taking over. Share the next ones.
[01:55:13] Dirk Kutscher: Yeah. Thank you very much. So just let me say, this workshop was really an excellent example of, you know, how the
[01:55:23] Eve Schooler: Yeah. You probably need to make it tolerant.
[01:55:25] Michael Welzl: Yeah. Of
[01:55:30] Dirk Kutscher: how the I IRTF can work. Thank you. So thanks very much again for putting this together. And just to respond to Marisol, so we are not doing standards here. Right? So we are a research organization. So we we don't do so many liaisons with other STOs. But, of course, we welcome contributions and also discussions with you. And yeah. So these are just some some, you know, ad hoc thoughts I together after the the workshop. And so I think it has really huge potential for exciting stuff. Let me let me skip over this because you know all of this. This is well, you you put all my slides. Okay. So right. So so this cross this workshop really led to some interesting, you know, new ideas. Also, we know what impact could possibly do. So so instead of, you know, just, you know, doing the traditional optimizing of links and bit level transmissions and so on, we think there's a bigger question in terms of, you know, how how should the end act actually evolve when energy becomes the first class resource. So we have been discussing this year also, like, you know, exposing, you know, carbon cost and and all these things, you know, adaptive services, graceful degradation, and so on. And then so some of the of the talks from the grid community also exposed some some interest in, you know, using technology that that we understand pretty well for making the grid work better. So protocols for cyber physical sustainability, coordination, also, you know, cross domain communication, resilient protocols, and so on. And yeah. So we my thinking was that so sustain might be the maybe the ideal place to develop this conceptual foundation and then maybe later influence Sunnett's making in the ITF. So identify these open these new open architectural questions, really link these communities, and then eventually have a meaningful technology transfer to the ITF. And so the two bigger questions, I think, Michael already alluded to them is, so is there something, you know, for the Internet architecture to consider for for future evolution to support partially, globally, not always really not globally, but somehow interconnected sustainability critical cyber physical systems. But also and that's probably a bit more, you know, open ended but potentially really interesting. So what can the grid community learn from Internet concepts? So principles that we have developed, but also not necessarily blindly adopting everything, but also considering some maybe mistakes that were made in in some of our technical and architectural decisions for a, say, more packet based or packet oriented good design, quote, unquote. And so so the question that then came up is, so can we Internetify the power grid? And so there are some promising principles that were mentioned. So well, these grids, especially in Europe. Right? So there's lots of interconnection, federation, local autonomy, communication. So there is a need for finding meaningful interoperability, aggregation, the second multiplexing, you know, things that we also do, like evolving the sis the system or creating ways to evolve evolve the system, edge intelligence. Also, now these systems these, like, renewable energy systems, you know, provide much more storage. So needs some totally different ways of dealing with energy as Michael also mentioned. But there are also some energies that may not hold. Right? So not everything is really, like, one to one. We cannot, like, freely buffer power, for example, or energy. And, yeah, physical flows differ from transactions. So but there are interesting questions that the community felt that could be discussed further, and I hope sustainably could be the place that can facilitate that. How much time do we have? Zero. Right?
[02:00:20] Marisol Palmeir: No. No.
[02:00:20] Michael Welzl: You've got about three minutes. One minute or two is, I guess, something big.
[02:00:24] Eve Schooler: Three and a half minutes.
[02:00:25] Dirk Kutscher: Okay. Okay. So
[02:00:27] Eve Schooler: Clock over there too.
[02:00:27] Michael Welzl: Yeah. Yeah. Yeah. Okay.
[02:00:30] Dirk Kutscher: So I'm in Oh,
[02:00:31] Eve Schooler: that clock is wrong.
[02:00:34] Dirk Kutscher: There was this, you know, notion of of of energy routing that that came up. So we felt, okay, but that probably needs to be defined a bit better. Right? So what is actually being routed here? Is it power, energy, flexibility, control intent, or or money? So what is in these grid systems? What is really an endpoint path? What do you mean when we when we we imply the buffer concept, what are these domains? So a couple of of of questions. And I think so that this is not very well explored yet. But so both communities had the, let's say, impression that there's really potential. And so at the workshop, there were some also first research projects. So in Germany, for example, that are building first first prototypes. So it's it's, I think, super exciting time where, you know, new concepts can be developed and potentially quite exciting impact. So what I I mean, this is this is not a not a not not 10 commands or anything, but just some ideas. What could be done is, yeah, to to so this is not not not totally new always. So people have been thinking about, you know, Internet concepts for the good, but now could be a good time to review that work. So some some of you may may know, like, Keshav, for example.
[02:02:11] Eve Schooler: From Cambridge.
[02:02:12] Dirk Kutscher: From Cambridge. And so other people also here in the ITF, they had been, like, a group earlier that had similar ideas. I think now is the time to do a critical review, maybe taxonomy of and so on, and then really stress test this Internet analogy. And so I I think this workshop hopefully was just the first one in a series of, you know, collaborations. And yeah. So I think it was really exciting, and it was really good event. Thanks very much for organizing this.
[02:02:44] Andre: Thank you.
[02:02:45] Ali Rezaki: Thank you
[02:02:45] Andre: very much. Yeah.
[02:02:46] Eve Schooler: Thank you, Dave.
[02:02:47] Michael Welzl: Thank you. Okay. One comment and closing the queue
[02:02:54] Marwan Fayed: up. Hi.
[02:02:55] Dave Oran: Dave Orantis. One thing I'd like us maybe quickly to capture. It's a small thing that came up inside conversations. I don't think it ever made it in the workshop, which is that the current grid has a deterministic and very carefully preserved separation between the control system and the protection system. And the protection system operates completely independently to make sure fires don't get caused and and down power lines don't don't kill people, and things go wrong. So if we we we need to start considering what happens if we start combining those things by making the Internet the thing that is the bridge between the protection system and the control system. Mhmm. And there's, I think, a lot of opportunity to think that problem through really carefully because it's going to be of, like, ultimate importance to whether this thing is, you know, actually gonna work. Thanks.
[02:03:50] Dirk Kutscher: Yes. I agree. Thank you.
[02:03:52] Eve Schooler: Thank you.
[02:03:53] Ali Rezaki: You. Last comment from Andre.
[02:03:56] Eve Schooler: Oh, Andre, did you wanna also ask something?
[02:04:07] Andre: Hey. No. I just wanted to advertise my work related somehow for sustain and future work. So my my previous employer were balancing energy grids with electric cars via Internet and software. So I had this you can find it on my LinkedIn. And if it's all and use for any of this research that has been done or it's being done here at Sustain Research Group.
[02:04:36] Michael Welzl: Alright. Thank you. Wonderful. Yeah. With that, we thank everybody, and sorry for eating or drinking a bit of your drink time.
[02:04:45] Eve Schooler: But thank you for your participation.
[02:04:47] Chairperson: Indeed. Both online and all.
[02:04:48] Ali Rezaki: Thanks so much. And as always, please continue on the mailing list. We appreciate it. Thanks. Okay.
[02:05:01] Dave Oran: Cool. Yeah.