Minutes interim-2022-eimpactws-03: Fri 14:00
minutes-interim-2022-eimpactws-03-202212091400-00

IAB E-Impact Workshop Session 3: Improvements

5:46 am - 8:01 am  Friday, December 9, 2022 | (UTC-08:00) Pacific Time (US &
Canada)

Cedric Westphal
heb
Maya Richman
Eve Schooler
Jari Arkko
Safiqul
Dom Robinson Greening of Streaming
Michael Welzl
QinWu
Lars Eggert
Bruce Nordman2
2435 355 3024
Marisol Palmero Amador
Qin Wu
Tirumaleswar Reddy
Call-in User_2
Eric Voit
Louise Krug
Martin Flack
Henk Birkholz he/him
Nina Lövehagen
Hosein Badran ISOC
Ali Rezaki
Cindy Morgan
Snezana Mitrovic
Eric Vyncke
Chiara Lombardo - CNIT
Marisol Palmero Amador DX80
Louis Navarre
Jiankang Yao
Beatrice Siccardi
Fieke
Colin Perkins
Pascal Thubert
Toerless Eckert
Jan Lindblad
Bruce   Vesna Manojlovic
Esther Roure Vila
Rob WIlton
Franco Davoli
Carsten Bormann
Daniel Schien
Russ White
Romain Jacob
Brendan Moran
Carlos Pignataro
Chris Adams
Luis M. Contreras Telefonica
Wim Vanderbauwhede
Gonzalo Salgueiro
Dawn Nafus
Suresh Krishnan
Noa Zilberman
Alex Clemm
Pernilla Bergmark Ericsson

WEBVTT

1
Eve Schooler 00:00:30.544 --> 00:00:31.234
Kirsten.

2
Carsten Bormann 00:00:35.105 --> 00:00:35.555
Oh.

3
Eve Schooler 00:00:37.504 --> 00:00:38.074
Afternoon.

4
Carsten Bormann 00:00:41.224 --> 00:00:50.704
Yeah, so I'm very early just to make sure I don't have the usual Webex, uh,
problems, but I actually have to read elsewhere for the next 10 minutes.

5
Eve Schooler 00:00:52.774 --> 00:00:53.284
You have to.

6
Carsten Bormann 00:00:54.724 --> 00:00:55.384
3 or 4.

7
Eve Schooler 00:00:56.344 --> 00:00:56.764
Oh, yeah.

8
Carsten Bormann 00:00:56.914 --> 00:00:57.334
Okay.

9
Eve Schooler 00:00:57.364 --> 00:00:59.254
So, do you want us to quickly test test.

10
Carsten Bormann 00:01:00.034 --> 00:01:03.814
No, I just wanted to join, so to make sure that the joining actually works.

11
Eve Schooler 00:01:04.054 --> 00:01:13.414
Just to join the presenting in Webex it usually swaps for me and many others
it's swapped monitors. So just be aware of.

12
Carsten Bormann 00:01:15.634 --> 00:01:18.274
Yeah, I I hope that Brendan is doing the presenting.

13
Eve Schooler 00:01:19.114 --> 00:01:27.454
So you don't have to deal with it. Okay. Don't worry. Everyone else has been
struggling with it. So we won't be alone. If you've run into any snappers.

14
Carsten Bormann 00:01:28.324 --> 00:01:34.114
Yeah, I usually present from a window and not from a screen, so I don't have
that problem.

15
Eve Schooler 00:01:34.685 --> 00:01:35.135
Okay.

16
Eve Schooler 00:01:39.545 --> 00:01:43.175
Good morning afternoon or evening wherever you are.

17
Dom Robinson Greening of Streaming 00:01:58.985 --> 00:02:03.515
Good morning. Sorry I was fighting to unmute there. I'm very well. How are you?
Both.

18
Eve Schooler 00:02:07.024 --> 00:02:10.444
Almost a week for me, it's quite early in California.

19
Dom Robinson Greening of Streaming 00:02:10.714 --> 00:02:13.894
All right mid afternoon here, it's nearly barbecue time.

20
Eve Schooler 00:02:14.674 --> 00:02:17.884
Exactly, it's nearly the weekend the official weekend anyway.

21
Dom Robinson Greening of Streaming 00:02:20.344 --> 00:02:20.884
Is.

22
Dom Robinson Greening of Streaming 00:02:23.374 --> 00:02:24.064
I'm just going to use.

23
Jari Arkko 00:06:15.995 --> 00:06:16.655
Hello.

24
Eve Schooler 00:06:18.695 --> 00:06:19.655
Good morning morning.

25
Jari Arkko 00:06:21.545 --> 00:06:26.675
Hi Eve, would you like to share or shall I share our couple of slides in the
beginning?

26
Eve Schooler 00:06:28.835 --> 00:06:31.295
Uh, if you're comfortable with it, why don't you share.

27
Jari Arkko 00:06:32.135 --> 00:06:32.645
Okay.

28
Eve Schooler 00:06:33.005 --> 00:06:43.835
I think I told you, I'm, I'm at someone else's house with a different
configuration for my computer so I'm hoping it'll behave today. The network and
everything else.

29
Jari Arkko 00:06:44.345 --> 00:06:47.045
Sounds like it so far.

30
Eve Schooler 00:06:47.345 --> 00:06:47.675
Good.

31
Eve Schooler 00:07:01.324 --> 00:07:21.424
Question for you about the timing for each of the talks, I think you had said
10 minutes. Is that more like a 15 minute slot? Because about 5 minutes of Q
and a, after each top or are you wanting to save the.

32
Eve Schooler 00:07:21.455 --> 00:07:22.265
Sorry.

33
Jari Arkko 00:07:23.225 --> 00:07:41.165
Okay, so we have 5, so, ideally, we'd be closer to 10 than 15. I mean, it's not
a hard limit, but if we spend 15, then we have only 45 minutes for discussion.
So, unlike the previous sessions, maybe there's more reason to be strict on
this 1.

34
Eve Schooler 00:07:41.615 --> 00:07:42.335
Huh.

35
Eve Schooler 00:07:44.045 --> 00:07:54.245
Um, so I will, I'll state that or 1 of us should state that explicitly. You
don't? Then I will. Okay.

36
Jari Arkko 00:08:10.834 --> 00:08:13.414
And you can see my screen now, right?

37
Eve Schooler 00:08:13.804 --> 00:08:14.374
Yes.

38
Jari Arkko 00:10:14.860 --> 00:10:22.085
And Alex, I, I see your slides on the, um, data tracker, but you will share
them directly from your computer, right?

39
Alex Clemm 00:10:23.045 --> 00:10:28.445
Sure, I can share them. I haven't tested this with Webex lately, but yes, I
have them here.

40
Jari Arkko 00:10:29.645 --> 00:10:30.035
Okay.

41
Jari Arkko 00:11:40.474 --> 00:11:52.684
Yeah, I think we will wait for. Yeah. Uh, 1 or 2 more minutes. Um, see, a bunch
of people are already on, but, um, maybe a bit more will join. If you wait a
minute or 2.

42
Jari Arkko 00:13:03.455 --> 00:13:23.735
Okay, maybe it's time to get started. I see. 30+people on board. Maybe a bit
more will show up, but, uh, it's already 3 past and so we have lots of things
on the agenda. Um, so this is the 3rd session of the workshop and, uh, we'll be
talking about, but then.

43
Jari Arkko 00:13:23.799 --> 00:13:44.944
Improvements and each school, or actually will will, uh, lead this session. I'm
just going to cover the reminder about, uh, the, um, ways of working or ground
rules. So, in case you're just showing a need for the 1st time on this session,
then. Welcome. And a reminder again that the.

44
Jari Arkko 00:13:44.974 --> 00:14:06.094
And it's recorded and recordings will be published. Your position papers are
public already. And of course, this is a professional meeting and we expect
professional behavior and no kind of harassment is accepted. And, uh, just a
reminder again that there's lots of people with very different backgrounds.

45
Jari Arkko 00:14:06.125 --> 00:14:27.245
So, um, do you explain clearly what, what you mean and people polite and learn
from the other's viewpoints? I think in this sense and in particular, we will
be talking about some of the technical things. So, um, do keep that in mind,
um, with that. I think I will just hand it over to you Eve and.

46
Eve Schooler 00:14:30.004 --> 00:14:48.394
Okay, when I advance to the next slide, so, 1 thing that was quite helpful
yesterday was to sort of reiterate what some of the goals were. And so we've
done that again today and look forward to you helping us to.

47
Eve Schooler 00:14:48.425 --> 00:15:09.215
Refine our objectives and to hopefully meet them, we clearly are wandering into
territory where we are discussing potential solutions today. And also some of
the feasibility behind them and their benefits and can we quantify those
things? Are.

48
Eve Schooler 00:15:09.664 --> 00:15:30.694
So that we can arrive at answering the questions, are the benefits significant
how do they make an impact? Can they, and how much they make an impact and, for
example, some of the points that investment made on Monday that were quite
helpful, were to consider, you know, we spoke a lot yesterday.

49
Eve Schooler 00:15:30.724 --> 00:15:41.974
Day about how energy usage has remained rather stable or static, but the
directives coming from the and.

50
Eve Schooler 00:15:42.035 --> 00:16:03.125
Where is the urgency to reduce our usage of both resources, electricity and
ultimately, carbon footprint and emissions and so 1 of the ways to consider
improvements is, you know, by how much is it 10% less per year or some of.

51
Eve Schooler 00:16:03.154 --> 00:16:24.274
Goal that we're trying to meet. Certainly there have been places like the, the
world research institute that have tried to quantify how much faster we need to
accelerate our efforts to meet these goals. Um, and, uh, in terms of say, the
introduction of renewables, the moving off of.

52
Eve Schooler 00:16:24.304 --> 00:16:45.424
Fossil fuel, and how quickly we need to move to the electrification of
transportation and so it would be good to have an ambition for our venues. Our
areas of impact another area that was suggested was to consider disaster
scenarios, uh, emergency situation.

53
Eve Schooler 00:16:45.454 --> 00:17:06.543
An extreme climate as baseline requirements. For example, in the United States,
the Noah, which is considered the National Oceanic Oceanic and Atmospheric
Administration, our trusted sort of weather and climate organization has said
that in the last decade, certainly in the United States.

54
Eve Schooler 00:17:06.579 --> 00:17:27.604
Number of 1Billion dollar emergencies has doubled, for example, and then other
kinds of ways to talk about improvements or caveats is to be aware, or avoid
techno optimism that everything's going to work out technologies. Our Savior,
the efficiency paradox that the more we save the board.

55
Eve Schooler 00:17:27.875 --> 00:17:48.875
We use and also, um, power differentials and the, the question to you as an
audience is are there other impacts elsewhere. What kinds of trade offs exists
what kinds of incentives that's certainly, uh, quite important too. And and who
are we trying to incense? Um, and, uh, as well as.

56
Eve Schooler 00:17:48.904 --> 00:18:09.964
Security issues that sometimes more than sometimes are at odds with our goals
for efficiency. And so the scope today is, um, there's no need to focus only on
the things that the even though we're sponsoring this workshop. So it's not
only the things that the can do.

57
Eve Schooler 00:18:10.204 --> 00:18:31.174
What can we do collectively? We are, so I would advance the slides if you could
Laurie, and we have 5. terrific talks today. Uh, we've allotted about 15
minutes to them. So, for all of your speakers, we're trying to stay within
about 10 minutes.

58
Eve Schooler 00:18:31.204 --> 00:18:52.174
For the talks, we're lucky to have a conversation on metrics. Of course
underpin everything. Alexander will be speaking to that. We're going to have 2
talks on general thoughts on the solutions and trade offs. Carlos, pregnant
tarro and Suresh. Krishna.

59
Eve Schooler 00:18:52.534 --> 00:19:13.474
General thoughts on solutions and trade offs that include routing, for example,
Alvaro return and Russ white will speak to that and importantly the data
formats that underpin much of this Brendan and and a return to our beloved
topic. Multicast.

60
Eve Schooler 00:19:13.505 --> 00:19:34.625
Discussion and debate around multi cast that lose Navarre and Michelle, we'll
discuss we have about 70 minutes of budget for discussion and if it's anything
like, the last few days Sprint, which is, which have been fantastic I really am
looking forward to that and please continue to drop your.

61
Eve Schooler 00:19:34.834 --> 00:19:51.304
Comments and questions as well into the chat window, and we will try to serve
as some of those service and surface some of those as well and please continue
to either jump in or raise your hand to ask questions as well.

62
Eve Schooler 00:19:53.014 --> 00:19:55.504
With that, I think we are over to you, Alex.

63
Alex Clemm 00:19:58.384 --> 00:19:58.564
Okay.

64
Alex Clemm 00:19:58.624 --> 00:20:01.054
Thank you, Eva. Let me just share.

65
Alex Clemm 00:20:14.104 --> 00:20:17.164
Okay, can you see, can you hear me and can you see my slides.

66
Eve Schooler 00:20:17.704 --> 00:20:18.244
Yes.

67
Suresh Krishnan 00:20:18.274 --> 00:20:18.634
Yep.

68
Alex Clemm 00:20:20.254 --> 00:20:40.114
Great yeah, so yeah, good morning or good afternoon and, uh, everyone so yeah,
so the 1st presentation, your concerns metrics this is actually based off of a
draft of the submission was based on the draft. Um, that you see, uh, uh,
referenced here along with a bunch of CO authors.

69
Alex Clemm 00:20:40.924 --> 00:21:01.684
Also there, so, um, let me jump into that. So context we don't need to talk
much about that. Uh, I think clearly, this is what the workshop is all about
the fact of basically how how we, how the idea of how the network community
can, uh, contribute towards addressing 1 of mankind's grand challenges, which
is basically reducing.

70
Alex Clemm 00:21:02.104 --> 00:21:23.014
Footprint, um, and, uh, yeah, I think, as we're all aware is networks are both
an enabler for solutions for solutions, but also contributed to the problem
itself. And then, of course, many contributors to network energy efficiency
today. Um, many of which go, perhaps beyond what the, where the can can
contribute.

71
Alex Clemm 00:21:24.394 --> 00:21:44.344
Um, uh, so we talked about the hardware advances, uh, transmission, technology,
uh, sustainable power sources, et cetera. Um, but, uh, the questions, of
course, which are ways in which the can contribute and even if, perhaps the
factors that the overall equation of things may seem small.

72
Alex Clemm 00:21:44.614 --> 00:22:04.144
Um, even if it's just a smaller slice of the pie busy, everything counts and
perhaps, even if it's not the well, we saw yesterday, Michael, uh, a diagram of
the of the of the moon and the stars and the planets and even if it's not a
major planet, maybe, if, uh, maybe a moon would make an impact, uh, already as
well.

73
Alex Clemm 00:22:05.524 --> 00:22:26.644
So, um, of course, we're networking can contribute. This is the subject of the
discussions or further discussion that we will have here. Uh, but there are
quite a few potential things, obviously areas to look at 1 area concerns.
Certainly, basically in the area of how you manage that, versus how you deploy
networks, how you optimize that works.

74
Alex Clemm 00:22:27.124 --> 00:22:47.434
And networking standards play do play a role and enable those and these are,
um, a number of things. So basically anything from you need to provision and
networks a, therefore you do need to dimension them, you need to manage over
subscriptions. We talked about the potential to peak shaving as a way to, to,
to contain the carbon footprint.

75
Alex Clemm 00:22:47.824 --> 00:23:08.944
And so forth, and the function of these are phosphorylated, uh, to to yeah. Uh,
ultimately to to management type of functions. And, um, uh, management and
other controllers have have been a long time about optimizing various
parameters. And in the past, we parametrized things such as utilization or or.

76
Alex Clemm 00:23:08.974 --> 00:23:24.334
Store or service level objectives, and so forth. And and at the end of the day,
energy usage is just another great parameter that can be, uh, that can be
optimized that way. And, uh, there are many other ways. I, um.

77
Alex Clemm 00:23:26.195 --> 00:23:46.925
Tracking functions, how do you plan routes, segments, paths and so forth and of
course, for all of this, how do you moderate also the trade offs because, while
we want to reduce the carbon intensity, we, of course, still need to keep in
mind that there are service levels that need to be delivered, um, utilization
that needs to be maintained to make things economical. And and so.

78
Alex Clemm 00:23:47.019 --> 00:24:08.164
Um, but beyond management, there's there are other aspects in control. Can you,
could you, for instance, would it make an impact if you can select from greener
path alternatives as an example? Um, the metric architecture issues, actually,
some of this came through also in earlier talks would be cash from a carbon
standpoint. Where does it make most sense?

79
Alex Clemm 00:24:08.495 --> 00:24:29.315
Here, obviously, again, trade offs involved. How much do we spend in
transmitting data versus storing it elsewhere? And potentially, even things
such as protocol designs, um, protocol design itself could be, for instance,
uh, would it felt funny if we, uh, play with a smoothing versus bursting of
traffic.

80
Alex Clemm 00:24:29.404 --> 00:24:50.464
And so forth, but regardless, but, uh, measures at the end are selected, it all
starts with visibility. And, uh, there's this if I was saying, if you can't
measure it, uh, you can't manage it. And 1 might add basically, or you could
not assess how effective are your solutions and you hit a device.

81
Alex Clemm 00:24:50.469 --> 00:25:05.644
Solutions that rely points on control groups and so accordingly you do need
visibility and visibility starts with the right metrics. This is really busy
the foundation for for, for everything else. And this is also this happens to
be also an area. Um.

82
Alex Clemm 00:25:08.015 --> 00:25:28.535
And where the may be able to make an impact. So, concerning metrics. Um, well,
the question then is basically what metrics do, we need to define what metrics
are needed. This is, of course, very much driven always by the types of
questions that we want to answer. How do we assess the effectiveness of a
solution? How do we compare between.

83
Alex Clemm 00:25:29.254 --> 00:25:41.284
Design alternatives, how can we optimize the network deployment? How do we know
if 1 is better versus the other? Um, et cetera, et cetera and so, and, and, um.

84
Alex Clemm 00:25:42.845 --> 00:25:43.355
So.

85
Alex Clemm 00:25:45.459 --> 00:26:05.824
This is also what should the metrics cover? Right? We have, of course, the
energy usage efficiency. Uh, the scope is the network itself, then there are
also, but then, the question is beyond the usage efficiency, that was the
question. Well, how are the energy sources? Right? Others sustainable so,
basically, this, this basic goes beyond the network in a narrow sense if you
will.

86
Alex Clemm 00:26:06.635 --> 00:26:27.725
Deployment and then you can get further, still such as for instance, um, yeah
the need for well, basically taking into account manufacturing life cycle, the
need for cooling and so forth all of those things. So, with the metrics, we
want to provide a holistic picture that can be provided that can account for
the whole picture at the end of the day. Not not.

87
Alex Clemm 00:26:27.759 --> 00:26:48.904
Just, uh, not just the part and that can help us basically address, um, the
question that we want to have and that can help us enable the control hub of
you have these other type of controls, which is depicted here. Um, and we want
to enable them and, um, again, based on metrics so, uh, getting to the metrics.
So when we look at the metrics, well, we.

88
Alex Clemm 00:26:49.024 --> 00:26:53.374
We'll look at how to how we so, 1 question is, how can we structure the.

89
Call-in User_2 00:26:53.374 --> 00:26:53.854
Matrix.

90
Alex Clemm 00:26:53.854 --> 00:27:10.054
Phase and, uh, the obvious way to start it of course, with the device and
equipment, but it itself probably is not enough. We want to know also basically
about the flows or service instances and so forth. Uh, we want to also assess
finds the.

91
Alex Clemm 00:27:10.059 --> 00:27:30.904
Intensity of paths and also talk about the network at large and, uh, here's and
basically and we want to address all of these, these, along all of the 3
verticals. If you will the energy usage efficiency. This is actually where the
current focus of the draft is. But we don't want to forget about the other
factors as well. So, with this, let me, um.

92
Alex Clemm 00:27:32.134 --> 00:27:52.114
Turn to some of the metrics, um, that we can identify just a disclaimer. It's
not a comprehensive list. Um, some may be speculative and we are also not
talking about the problems of how to instrument. Some of them, which is which
may be easier for some cases than it is for others. So, at the device and
equipment level and so.

93
Alex Clemm 00:27:52.385 --> 00:28:13.505
A little bit busy, but basically, they are, um, yeah, a bunch of things. You're
basically it starts with a standard suffered from what, uh, expect on, on data
sheets and so forth. So, basically, this is just the device ratings. If you
will, what are the power consumption when idle and virus slide, uh, loads at
various configuration and so forth and then for the current.

94
Alex Clemm 00:28:13.834 --> 00:28:34.594
Aspect of what this is actually using using. Of course we want to know what is
the current power consumption office system of a line card of a port and so
forth. Um, we want to be able to potentially, uh, know the path we want to
basically know this for different time intervals and systems start for the past
minute and so forth. And, uh, in addition to this absolute.

95
Alex Clemm 00:28:34.659 --> 00:28:55.804
Measures we want to also normalize or derive metrics so that we can assess the
actual efficiency. So we want to relate it, for instance, in terms of well,
okay, this is how much power we consume, but how does it relate to the to the
amount of traffic that we are, um, actually passing and so forth so well, then
in addition to the consumption metrics.

96
Alex Clemm 00:28:55.834 --> 00:29:16.954
As mentioned there are, uh, the other aspects versus funds and source
sustainability of course, that basically would basically increase the scope
because it becomes more we want to manage the overall environment, which might
include the power sources and so forth. Um, but among the things that can
certainly be done there is also to maintain a, something like power.

97
Alex Clemm 00:29:17.044 --> 00:29:38.104
Or sustainability ratings, um, which reflect, which are either obtain from an
energy provider, or which might reflect the operators, a mix of energy sources.
Um, and then, likewise, as we extended, that can be on power sustainability
ratings, that might be also device sustainability ratings. Uh, that's basically
raped the device as a whole. How Eco friendly is.

98
Alex Clemm 00:29:38.135 --> 00:29:59.195
Uh, replacement lifecycle considerations, uh, metrics where you could, for
instance, indicate how you how the energy debt incurred by the manufacturing of
a device uh, it gets amortized, uh, over the equipment lifetime. Um, yeah. And,
uh, and and of course, uh, and of course, more in the interest of time that we
just.

99
Alex Clemm 00:29:59.644 --> 00:30:20.374
Move on, um, so, uh, because, uh, as mentioned, it's also important that we
move also beyond equipment and so forth. It's itself because this where a lot
of the networking functions and operational things are also to be found. So,
um, uh, 1 important aspect concerns flows. How.

100
Alex Clemm 00:30:20.409 --> 00:30:41.524
Can we relate carbon incentives intensity to flows, or 2 instances of services?
So, uh, metrics of interest here are finds the, uh, amortize energy that is
consumed over the duration of a flow. Um, so basically, the power budget, if
you will, that could be a, um, uh, yeah.

101
Alex Clemm 00:30:41.674 --> 00:30:59.464
Assigned or associated with a given flow and also potentially, and this might
be important for optimization things. But what is the incremental energy that
would be consumed? That would not have been consumed? Otherwise, of course, we
heard yesterday. And this is basically an excerpt from the, from the, the
diagram from from.

102
Alex Clemm 00:31:00.215 --> 00:31:21.035
Um, uh, talk yesterday, of course, if we have a step function, then this may be
0. so this may not be interesting but in those case, it will be, of course, uh,
on the other hand, very important to know when these steps are occurring. So,
basically, we want to know basically, WH, when an action would actually trigger
the next upgrade cycle, that would essentially basically.

103
Alex Clemm 00:31:21.214 --> 00:31:42.154
Up level the thing to the to the next level and so, and so forth. Um, well,
then beyond flows are paths. So, uh, clearly, it's also, uh, W, W, we want to
optimize paths and perhaps optimize path selection and so forth. It may be
interesting to have, um, paths things such as paths and.

104
Alex Clemm 00:31:42.214 --> 00:32:02.884
Ratings these might be functions of the rating of the different pops that are
being traversed. So, does it include, uh, dirty devices if you will or is it a
composed of clean devices? Um, and the fact that could be anything right? It
could be a, an average it could be the some, it could be the maximum. What what
have you.

105
Alex Clemm 00:32:03.544 --> 00:32:24.484
Uh, and likely, we, we may want to know also basically, what is a normalized
power consumption across the path to make them more comparable. And then
finally and of course, it's the purpose of this. We want to basically, uh,
reduce the total carbon footprint of the network as a whole. So we want to be
we will also need to aggregate a lot of these metrics for the.

106
Alex Clemm 00:32:24.490 --> 00:32:45.305
Entire deployment and, uh, well, so just to to, before concluding the just a
few other considerations I want to mention. So, 1 aspect concerns of course.
Well, this W. W. W. well, the 1st step other metrics, uh, the 2nd step, these
things will need to be instrumented. Um.

107
Alex Clemm 00:32:45.665 --> 00:33:06.785
Uh, there are a couple of thoughts or more discussion items really um, energy
consumption may be easier to measure than actual carbon emissions. So this is
basically, certainly 1, uh, 1, uh, threat of a discussion here. And, uh,
likewise. Basically, if you want to obtain metrics across paths and.

108
Alex Clemm 00:33:06.904 --> 00:33:27.934
And so forth, basically, this, uh, this will be more than just instrumenting.
Uh, yeah, it doesn't mean they involved in mechanisms or what have you, uh,
more than just the instrumenting, uh, device agent if you will, uh, another
aspect concerns, um, certification compliance. So, basically, if we do use
these metrics.

109
Alex Clemm 00:33:27.939 --> 00:33:48.694
To optimize carbon density. This is, of course important to have
instrumentation. That is accurate. Otherwise it may be counterproductive. And
it may also be particularly important in regulation in monetary incentives, get
involved. And if if you claim offer a greener service, and maybe charge
something for it, just as an example, how would you actually know that? This is
true.

110
Alex Clemm 00:33:49.444 --> 00:34:09.934
Um, for consideration is, uh, 11 of the question is also how we can consider
how we can treat is not just as a problem for the operator, but ultimately also
attribute the energy usage to users and confront users with the choices of the
actions. Um, regarding the carbon footprint and, um, yeah.

111
Alex Clemm 00:34:10.325 --> 00:34:31.325
So this concludes what I want to say, I want to mention again. I believe this a
lot of these metrics, and what's related to this is quite actionable. And the
idea of this is, I believe, where we can make an impact. Um, and, uh, once
metrics are defined our several areas to look at basically next, uh, this
includes things such as young models potentially, particularly extensions.

112
Alex Clemm 00:34:31.389 --> 00:34:50.794
A certain, um, to support energy parameters, uh, of course solutions and use
cases to drive. Each of those needs need to need to be defined. And finally,
also, just mentioned is, as I mentioned, this is based on a draft. Um, uh, we
want to, uh, advanced that as well. All right. Thanks. That's all I have.

113
Eve Schooler 00:34:57.124 --> 00:35:09.634
For that excellent summary and talk I'm producing the chat window. A lot of
wonderful comments there. Any I keep talking to maybe 1 question.

114
Eve Schooler 00:35:19.144 --> 00:35:27.004
Okay, let's move on then to the next presentation, the general thoughts on
solutions and.

115
Eve Schooler 00:35:27.904 --> 00:35:28.504
Yes.

116
Pernilla Bergmark Ericsson 00:35:28.744 --> 00:35:29.284
I actually.

117
Eve Schooler 00:35:29.974 --> 00:35:31.444
Oh, there you are. Okay.

118
Pernilla Bergmark Ericsson 00:35:31.444 --> 00:35:32.014
Yeah.

119
Eve Schooler 00:35:32.014 --> 00:35:35.314
Have to help me. I'm actually not in my home today. I'm somewhere else in.

120
Pernilla Bergmark Ericsson 00:35:35.434 --> 00:35:36.214
Yeah, yeah.

121
Pernilla Bergmark Ericsson 00:35:38.914 --> 00:35:42.724
The changing screens and all that. I, and I know all about it. So no worries.

122
Eve Schooler 00:35:43.084 --> 00:35:44.764
No, that's your question.

123
Pernilla Bergmark Ericsson 00:35:45.064 --> 00:35:58.744
Yeah, so the question was really, uh, so you are presenting a lot of different
options here or possibilities or other and, uh, of course, there is a, there is
already a standards both.

124
Pernilla Bergmark Ericsson 00:35:58.809 --> 00:36:12.844
When it comes to and the performance, especially in relation to networks and,
uh, also in relation to emissions and so on from, uh, about this, like, uh, uh,
the European standardization.

125
Pernilla Bergmark Ericsson 00:36:12.934 --> 00:36:23.824
And the, so I was curious if you have done on the like, a gap analysis, or or
something in relation to your work, or if this is a later step.

126
Alex Clemm 00:36:25.324 --> 00:36:34.024
Well, I think a gap analysis needs to be done. Absolutely. Uh, this is being
seen as is the latest steps redefine the metrics are really coming up.

127
Alex Clemm 00:36:34.059 --> 00:36:54.454
The set of comprehensive metrics is, uh, uh, is, I think the 1st step and then
from that basically, then the question will be the next thing but, yeah, what
exactly what are the gaps and what of the metrics um, and how should they be
prioritized? Because there are a lot of possibilities for metrics. Some of them
may be.

128
Alex Clemm 00:36:55.294 --> 00:37:12.004
Useful than others or some of them, maybe, uh, well, or there may be also
certain use cases they may want to be prioritized that requires some of the
metrics, but not others, but that would be, uh, yeah, I think that would be the
outcome then of, uh, further discussions and and and and the next step.

129
Pernilla Bergmark Ericsson 00:37:12.514 --> 00:37:16.354
Okay, so so just to clarify the question that I think there are other.

130
Pernilla Bergmark Ericsson 00:37:16.385 --> 00:37:17.885
About this who has also worked.

131
Pernilla Bergmark Ericsson 00:37:19.205 --> 00:37:25.535
So, it was more gap analysis in relation to the metrics, rather than in
relation to data. Okay. Thank you.

132
Eve Schooler 00:37:26.435 --> 00:37:36.125
Thank you that's great clarification. Let us move to the next presentation and
it looks like Suresh is going to get the presentation over to, you.

133
Suresh Krishnan 00:37:36.125 --> 00:37:36.395
See.

134
Suresh Krishnan 00:37:37.534 --> 00:37:58.654
so um i just want to say like i think like a alex like and i like in colors we
kind of agree a lot of the things right like you know we i looked at the papers
as well so we have like you know very similar talks a lot of the things i do i
kind of want to emphasize some of the things where um we didn't really have the
same kind of scope in the papers right so um so one thing uh that's

135
Suresh Krishnan 00:37:58.684 --> 00:38:19.714
I think like, pretty much everybody in here knows, right? Like, with the scope
and scope to on scope 3 emissions and, um, so, 1 thing that was kind of like,
you know, new to a lot of us is that, like, you know, scope 1 and scope to are
mandatory to report and most of the jurisdictions. Um, whether it's Europe or a
U. S. or like, even like some place in Asia so those, like, get a lot of
priority, right? Like.

136
Suresh Krishnan 00:38:19.834 --> 00:38:40.414
in when like things are getting reported like you know everybody looks at scope
and scope too and how to like reduce that and um you know how to get to net
zero there but scope three is like kind of outside the control of yard right uh
so the whether it's usage of the products or like you know the energy that's
consumed like you know the like by the organization and how it's like you know
getting produced

137
Suresh Krishnan 00:38:41.344 --> 00:39:02.104
But, like, in our industry, right? At least in the networking industry, the the
scope 3 emissions are, like, much larger. So this is obviously, like, not to
any precise scale. But kind of to give you, like, an idea of, like, this thing,
like, you know, the scope 3, like, it's much larger than even scope on and
scope to put together. So, uh, we need to kind of focus a little bit on the
scope 3 emissions because, like, you know.

138
Suresh Krishnan 00:39:02.135 --> 00:39:23.225
Our organizations themselves are focusing on scope and scope too, because of
like, you know, regulatory and and legal, uh, things to report. So, um, and 1
thing I wanted to call out is like, scope 3 for somebody's, like, scope 2 and
scope 1 for somebody else. And I think this is kind of in the same direction as
what Alex was talking about, right? Like, you know, when, like, people are
operating gear.

139
Suresh Krishnan 00:39:23.284 --> 00:39:44.404
Some network vendor, right? Like, you know, they are really in the reporting
chain for that right? They need to report those things, but as, like, you know,
the networking industry ourselves, like, we need to kind of help the customers,
like, reduce their, like, scope and scope, which could be our scope 3
emissions. And, uh, so 1 thing that is kind of changed over the.

140
Suresh Krishnan 00:39:44.409 --> 00:40:05.554
Here is like, you know, we kind of had, like, you know, I would say 3 things
that we, um, optimize for, um, like, you know, back in the day. Right? Like,
you know, we kind of tried to maximize the throughput, minimize the latency and
increase the availability of the system itself. Right? And so that's kind of
changed, like, over the past. Like, I would say, like, decade or so. Right?
Like, energy efficiency is another angle.

141
Suresh Krishnan 00:40:05.734 --> 00:40:26.674
I am, um, not not to, like, take anything away from this. But I think point is
like, this is an AP complete problem is, like, really, really relevant here.
So, what we're trying to do is like, kind of make, like, smart choices, uh,
with energy efficiency in mind. So, like, you know, we are kind of trying to
bound, uh, the, um, the usage of the other dimensions. Like, you know, in kind
of.

142
Suresh Krishnan 00:40:26.734 --> 00:40:47.854
Trying to find, uh, energy efficient, I would say frontier for lack of a better
term. And this also includes stuff like, uh, circular economy stuff like, you
know, where does this come from? There's like, um, Alex talked about, like, you
know, metrics. Right? But, like, stuff happens much before that. So, is it,
like, something that we can do with modularity? Is there something that we can,
um, uh, do with, like.

143
Suresh Krishnan 00:40:47.885 --> 00:41:09.005
Packaging, um, what kind of power supplies are sitting there, right? So, a lot
of the things are like, even Pre metric right? Like, so this is like, more
static things that we can measure through the supply chain, but it's also
something we kind of have to consider in the overall lifecycle. And similarly,
like, you know, we have some programs, at least like Cisco, we have some
programs like, for like, you know, recycling the hardware those things. So all
those things need to get.

144
Suresh Krishnan 00:41:09.034 --> 00:41:30.154
Um, when we do the, uh, sustainability measurements, so kind of like, you know,
3 phases of, like, you know, getting through this right? Like, so we start off
with visibility. I think, like, I think most of us, I would say, probably
everybody agrees that, you know, we kind of need to get visibility into the
system then move on to, like, you know, how we get insights from.

145
Suresh Krishnan 00:41:30.184 --> 00:41:51.304
And how we actually recommend things to people who are, like, not doing this,
like, as a day job, pretty much, right. To, like, improve the system. And
finally, how do we get the systems to kind of improve themselves. So, that's
kind of the high level. Um, um, I would say, like, the blocks of things, so it
doesn't mean that really, um, these things need to happen in cities, right?
Like.

146
Suresh Krishnan 00:41:51.334 --> 00:41:59.944
Kind of start, like, you know, phase 2 and phase 1 is happening, but it's kind
of like, I would say, the harder problems to solve are, like, you know, coming
further down. We're kind of pushing the can down the road.

147
Suresh Krishnan 00:42:03.605 --> 00:42:22.325
So, uh, as like, an Alexa, right? Like, so, uh, whether it has to be repeated
or like or whatever, right? You cannot improve or you don't measure. So, I
think the, uh, we have a long history of work in the field. Uh, so, like, eh,
like, Ikea has done quite a bit of work, like, you know, like, you know, gang
like a whole bunch of stuff like that.

148
Suresh Krishnan 00:42:22.384 --> 00:42:43.444
An idea of has done quite a bit of stuff and and doing stuff and has done,
like, a lot of documents, like, you know, providing guidance in this thing. So,
we've been pretty successful, uh, in in kind of standardizing, like, the things
that need to get measured on how we measure them. And, um, so we do this for
management, like, network management for performance management and for
troubleshooting.

149
Suresh Krishnan 00:42:43.504 --> 00:43:04.294
Right like an, but I think we also need to start doing this for environmental
impact and, of course, it's difficult to do. But the problem is, like, the, the
longer we, uh, delay doing this, uh, we're gonna, like, leave ourselves open to
a lot of stuff happening outside the idea. Right? Which is kind of, um, like,
lets you have.

150
Suresh Krishnan 00:43:05.045 --> 00:43:25.775
Stuff that's potentially redundant. So, like, different vendors are gonna do,
uh, different things. It's gonna be proprietary to them and sometimes, like,
people are gonna do, like, contradictory metrics as all. Right? Like, you know,
you really don't have a surplus build reconcile. So this is a problem in by
itself, but for somebody who's using these things, if you have, like, very
different things from different vendors, and you have a multi vendor network,
it it.

151
Suresh Krishnan 00:43:25.804 --> 00:43:46.774
It's very difficult to kind of have, like, an overall view of the system. So we
really need to act quickly to do something that we can agree on. And kind of
set like, industry level standards on, on, uh, what is going to get measured
and how, and kind of terminology is like, really part of it, right like, you
know, because people have different ways of measuring stuff. So, we kind of
have to have precise ways.

152
Suresh Krishnan 00:43:47.015 --> 00:43:48.635
Uh, uh, on what things are, what.

153
Suresh Krishnan 00:43:51.034 --> 00:44:10.894
So, the, the next step is like, kind of, like, have something for the industry
to use, right? Like, I'm like, this is just like a strong manned proposal. Is
that, like, we kind of have some kind of open source implementation, right?
Like, for people to actually have the standardized metrics that we've built and
collected and put them together in a way that people can actually see their,
uh, environmental impacts.

154
Suresh Krishnan 00:44:10.924 --> 00:44:32.044
Whether it's like, energy efficiency, like our, like, you know, somehow
translating this into carbon emissions or, like, whatever angle you want to
see, then to kind of visualize this thing. So that's kind of the 1st step. And,
um, so, of course, like, you know, this is not gonna like this, of course,
going to be some stuff that's common between, um, like, different network
vendors and so on, uh, and users but, like, there's all.

155
Suresh Krishnan 00:44:32.074 --> 00:44:52.414
So, we need a way to kind of customize this right? Like, so people can actually
add some kind of value on top of it because if it's just going to be, uh, the
lowest common denominator, it's probably not going to be enough for, like, a
lot of the users. And, uh, I think, like, even bump this up, um, I think, I
don't know if it's like yesterday or, like, on Monday. Um, like, this is like,
kind of a multi domain problem at some point. And.

156
Suresh Krishnan 00:44:53.224 --> 00:45:14.344
So, if you have, like, similar ways of looking at stuff, it's at least there's
like a hole that you can actually kind of reconcile this across domain. But
without that, we probably don't even have the same language. You can speak
across domain. So, and of course, it's a very difficult problem, but at least
we have a start in that direction. And the, uh, the next step would be to kind
of provide some kind of advice. Like, you know, is there any operational.

157
Suresh Krishnan 00:45:14.374 --> 00:45:35.494
Changes you can do, can you, like, turn off specific routers specific times? Is
there, like some, um, um, transceivers that can get turned off right? And is
there some equipment that can be replaced? Like, you know, when it's getting
close to it's like, design lifetime. So those kinds of things can all be like,
recommendations coming from such kind of software, uh, towards the people. So,
people can actually.

158
Suresh Krishnan 00:45:35.524 --> 00:45:39.994
Plan for this and and do, um, productive changes.

159
Suresh Krishnan 00:45:42.574 --> 00:46:03.544
And, uh, like at the last step, right? Like, we kind of do this at a longer
time scale. So, if it's gonna be months or years, like a human looking at it
and providing solutions, or looking at solutions and ordering stuff, it's all
gonna work. But at some point, um, human doing, this is not gonna cut it.
Right? So, we can, if you want to do something in a smaller time scale, and we
kind of have to start building.

160
Suresh Krishnan 00:46:03.904 --> 00:46:24.844
Some amount of cell phone listen to the network and, uh, I know has some work
ongoing, but it's not really in the space. But I think we can actually start
looking at. Uh, is there something we can actually do and probably make, like,
small changes and, and, and have, like, a feedback loop right to see how, um,
the changes affect the system and kind of keep repeating this in.

161
Suresh Krishnan 00:46:24.874 --> 00:46:45.994
Small increments, and and 1 key thing we see is like, this needs to be done in
a declarative fashion. I don't think like, people are gonna start doing this
and say, like, hey, like, make my, I don't know, energy, energy efficiency
stuff like 93% or whatever. It's not really the, um, the goal for somebody
that, like, people are going to have to specify something and.

162
Suresh Krishnan 00:46:46.024 --> 00:47:07.144
High level and missing all the collected metrics, we kind of have some kind of
machine learning algorithm that can go and look at, uh, opportunities to
improve these things. Right. And, um, also, like, you know, looking at, like,
something called scope for let's go for is like, really our emissions. I think
it was we talked about it yesterday. Like, you know, we are meeting here online
um.

163
Suresh Krishnan 00:47:07.174 --> 00:47:28.294
That's like, let's go for so I think I'm having some kind of automated system
is going to help us, um, look for opportunities in this space to see, like, you
know, what kind of emissions that can be avoided in the future. So, I'm just
going to closing, um, so we need to help our consumers of the technologies. I
think a lot of them are on this call.

164
Suresh Krishnan 00:47:28.324 --> 00:47:49.414
So, like, when I say consumers, like, I'm talking about, like, the, and and the
industry to kind of understand their emissions impact, like, you know, looking
at scope 3, uh, for the vendor side, and looking at a vendor, agnostic standard
is like, very, very important because it like, we see a lot of stuff that's
coming out in the market. It's really green washing, right? Like, you know,
it's just.

165
Suresh Krishnan 00:47:49.474 --> 00:48:10.594
Um, um, coming up with stuff to say, oh, like, we are doing, like, amazing
stuff, but not really, um, substantive. So, we kind of need to do something
that's vendor agnostic and and and and that's something that's like,
substantial to reduce and the environmental impact. Uh, another thing we can
do, I think, like, uh, probably like, uh, our own Russell covered somehow.

166
Suresh Krishnan 00:48:10.714 --> 00:48:31.714
Uh, in their thing, like, kind of looking at their paper, so, like, we kind of
need to build robustness and into the protocols so instead of doing unnecessary
redundancy. So a lot of the times we have protocols, which are, like, really or
engineer, they are like, you know, having, like, you know, 4 links on standby,
doing nothing. Uh, just in case things go wrong. I think, like, you know, we
kind of need to avoid stuff like that and build.

167
Suresh Krishnan 00:48:32.014 --> 00:48:52.894
Robustness and accountability to the protocols, and, and also look at, like,
how we need in the more energy efficient way. So, we don't need to really be
the SMS all the time, but also look at, like, you know, what is the, like, I
would say, the least thing we can do to meet the SMS and finally, like, you
know, kind of avoid micro optimizations and consider.

168
Suresh Krishnan 00:48:52.924 --> 00:49:14.044
Life cycle, so, like 1 of the things we kind of like realize is like, let's say
a core router of today could become like, a edge router for tomorrow. Right?
Like, if if it's possible to have some of the functionality that's required for
the edge router, that's not always there. So, uh, what we kind of do and we are
engineers like, at least most of us are engineers, we try to optimize
everything, like, very, very tightly.

169
Suresh Krishnan 00:49:14.074 --> 00:49:35.194
To the use case, and, like, you know, we are proud of it, but I think at some
point, we need to look at the flexibility. Uh, so that, like, you know, things
can actually last longer and that provides like, you know, much more benefits
in, in some cases than optimizing everything, like, very, very tightly for what
can be done. And I know there's cases, like, where this doesn't really work
like, you know, for example, is doing a lot of stuff in.

170
Suresh Krishnan 00:49:35.199 --> 00:49:47.734
And, like something that last like a year on a double battery, like, those
kinds of things don't work, but at least, like, think about it when we design
protocols. So that's pretty much it from our side. Thank you.

171
Eve Schooler 00:49:50.194 --> 00:49:54.454
Great Thank you. That was that was terrific. Overview. Um.

172
Eve Schooler 00:49:56.374 --> 00:50:02.314
I think in the interest of time we will, unless somebody has their hand up, and
I'm not seeing it.

173
Eve Schooler 00:50:04.174 --> 00:50:09.244
We should go to the next presentation and we will continue our discussion. So
it's the end.

174
Eve Schooler 00:50:13.054 --> 00:50:25.864
And now we have a sort of a continuation of general thoughts and solutions and
benefits and I think, I'm not sure if Russell you're going to be presenting.
Yes, terrific. Thanks.

175
Russ White 00:50:26.254 --> 00:50:31.024
Yes, I am. Sorry I have to unmute things and blah, blah, blah, so I don't.

176
Russ White 00:50:31.624 --> 00:50:33.544
Slide is that.

177
Jari Arkko 00:50:33.544 --> 00:50:35.224
Want me to say, or or will you.

178
Russ White 00:50:35.884 --> 00:50:38.194
Um, I should already be sharing now.

179
Jari Arkko 00:50:38.314 --> 00:50:38.524
Oh.

180
Jari Arkko 00:50:38.854 --> 00:50:40.024
Right.

181
Eve Schooler 00:50:40.024 --> 00:50:42.484
And if you want to go into full screen mode, that'd be great.

182
Russ White 00:50:42.544 --> 00:50:47.134
Yeah, that's what I'm going to do. Um, hopefully it continues to share it
correctly.

183
Eve Schooler 00:50:47.914 --> 00:50:48.814
Looks great.

184
Russ White 00:50:49.084 --> 00:50:52.384
All right, so this is based on a draft.

185
Russ White 00:50:52.924 --> 00:51:13.864
And manual, and I did a lot of work way, way back when about energy awareness,
and we approach things from a lot of different ways and 1 of which was to just
reduce the amount of energy that is required by routing protocols. But we kind
of walked away from that a little bit, because we didn't, we weren't certain
how much gain we would have there.

186
Russ White 00:51:13.924 --> 00:51:22.594
So, maybe keeping that in the back of your head as another possible
optimization in the future of it not something I'm looking at right now.

187
Russ White 00:51:24.124 --> 00:51:44.884
So, what we did say is we said there are essentially 3 modes that we could
think of that would be helpful. The 1st would be to reduce the links. For
instance, I have to link to it here. Perhaps I could get rid of 1 of those 2. I
have 2 parallel paths here. Perhaps I can get rid of 1 of those 2 and the 2nd
is removing redundant.

188
Russ White 00:51:44.944 --> 00:52:05.854
Equipment, so, for instance, if I could get rid of these 2 routers, um, or
power them down for some period of time, or something like that, that would
also reduce cost or reduce energy usage. Another is been talked about in the
chat is that you can actually reduce the speed of these links. If this is a 100
gig, then you can particularly drop it.

189
Russ White 00:52:06.094 --> 00:52:26.884
Um, you know, if you're using and you're using, say, 4 channels of over an
optical link or something like that, or a wireless link, you might be able to
reduce to 25 K or something like that and reduce the power usage. And all of
these can be done in a time variant way. And I think that's an important point.
But now, let's look at some of.

190
Russ White 00:52:27.304 --> 00:52:48.364
Routing protocols things now I'm not going to talk again. A lot about, um,
equipment because equipment is problematic in that. The more you bring
something down and pull it back up. The more often. It is to, um, the more
often it's going to fail. And so you just have to think about the trade offs.

191
Russ White 00:52:48.545 --> 00:53:09.365
The equipment failure versus health, and you're bringing it up and down, just
like a light bulb in reality. The more often you turn it on and off the quicker
the light bulb goes out. So, there are things that we need to look at there and
try to understand. I would argue that we don't know the answers to these
questions right now, because we haven't done a lot of measurement in this area.

192
Russ White 00:53:09.544 --> 00:53:30.664
To understand, like, if I shut a router off 15 times in a day, versus never,
what is the uptime gonna be? But thinking about strictly from a control plane
perspective, just thinking about some of the impacts that we have, for
instance, let's say if this left is my bandwidth and this right is my energy.

193
Russ White 00:53:30.669 --> 00:53:50.854
Message then I can say, I'm sorry. Yeah, I can say, okay, well, you know what,
I think I did this 1 backwards by the way I think this is 14, but anyway, I can
say, you know, what, I can save a lot of energy by cutting this link out. But
when I cut that link out, I'm driving traffic up through this upper path, this
increases what we call stretch.

194
Russ White 00:53:51.904 --> 00:54:12.904
Which is simply the number of hops in the in the network itself. And the thing
is, is that every hop that you clock off optics and into electronics and off
electronics onto optics, when you do these serialize, these serialized steps,
you are adding delay to the network. And you are potentially adding.

195
Russ White 00:54:13.324 --> 00:54:34.054
To the network, because here 1st of all you have just the simple I'm switching
from this path to this path, which is going to cause the routing protocols
convergence, which causes jitter what the application sees as jitter as the
traffic shifts from 1 path to the other path the 2nd thing is, as I push more
traffic onto this path.

196
Russ White 00:54:34.355 --> 00:54:55.265
These cues, if I have very carefully tuned my quality of service, and I'm using
traffic engineering or traffic steering to make sure that the network is
optimal. So, for instance, let's say that I push all my video traffic this way
and all my voice traffic this way. And then I kill this path for energy
savings. I'm now mixing.

197
Russ White 00:54:55.269 --> 00:55:16.414
In voice in the same Q structure, which is much more difficult to do, and not
have lots of things like that. So you decrease the aggregate bandwidth you're
increasing stretch. You're potentially increasing jitter your can be increasing
delay and so these can all have a negative impact on applications.

198
Russ White 00:55:16.864 --> 00:55:37.564
So, the whole point here is not that we should do any of this stuff. The point
is we need to think about it and figure out how to do this stuff rationally and
where it makes sense and where it might not make sense. It may be that in some
cases, shutting down, a particular set of links might save a synergy but, you
know, again, we may not know.

199
Russ White 00:55:38.044 --> 00:55:58.714
Um, whether that's going to work or not so problems that we definitely need to
solve, are out in in service determination. So I need to decide when I should
take a link or piece of equipment out of out of commission for energy savings.
I need to know what that looks like. When I bring it back up. Um.

200
Russ White 00:55:58.744 --> 00:56:19.864
Need to know how I'm going to determine to bring it back up. And this is true
also, for even things with short term sleeps like Microsoft and stuff like
that, which we've talked about in the past to solve some of these problems is
to do microscopes to say, okay, I really don't think I have traffic for you for
the next 2nd, so, let's shut down this link.

201
Russ White 00:56:19.870 --> 00:56:41.015
The next 2nd, and you come back up and check with me in a 2nd, these kind of
micro sleep ideas have been around for a long time whether or not, you know,
how you determined to do that. Another thing is we often don't think about this
is that routing protocols rely on being able to pass traffic through the link
to remember that the link is.

202
Russ White 00:56:41.044 --> 00:57:02.104
There and to know that the link is there and to know what's reasonable paths
that link. So we need to think about, from a routing perspective controlling
perspective. How do I remember that link? Is there how do you remember what's
reachable via that link? How do I handle things that change in reliability
while.

203
Russ White 00:57:02.194 --> 00:57:23.314
Is asleep or down, or the device is down or sleep and what do I do with those
things now I'll say that this part of things will probably be covered in the
TVR working group. That's coming up right now. In fact, I have a meeting this
afternoon to talk about next steps in the TVR. So that is something that we
need to think about another thing is that there's what kind of.

204
Russ White 00:57:23.344 --> 00:57:44.464
In that area, the next is convergence impact. So when I converge 1st of all
since BGP is the big hit on the block nowadays. Um, 1st, of all I have hunt, I
have the potential of all sorts of just not converging whether or not people
believe this. The Internet core never converges.

205
Russ White 00:57:45.244 --> 00:58:05.614
Never ever converges. So, you have hunt, you have not converging, you have all
sorts of weird things. That can happen. If you're looking at something, like,
which is a link state protocol, um, then you have micro loops and these things
have an impact on drop packets and things like that. And jitter and.

206
Russ White 00:58:05.645 --> 00:58:26.735
In the network, and so you need to think through, like, how do we make sure
that we're not dropping packets and impacting application performance or do we
not care? In some cases there are some applications they don't care about drop
packets and that's cool. That's great. But we need to think about those things,
and when you try to understand how to make the control plane, aware of all that
stuff, and do the right thing.

207
Russ White 00:58:27.064 --> 00:58:47.464
And finally impact on fast convergence. So, you know, a lot of parallel links
and redundancy is just there to converge more quickly in the case of failure.
And so, how do we, if we put something to sleep or we take it off line to save
energy, how do we anticipate failure or how do we deal with it?

208
Russ White 00:58:47.944 --> 00:59:09.064
What do we do about the fast convergence situations? So these are all things
that just need to be thought about again not saying we shouldn't do any of this
just trying to point out, or try to figure out some of the places where work
needs to be done and how we can do or where we might what we might want to do
to try to solve some of these.

209
Russ White 00:59:09.724 --> 00:59:17.134
Um, and some of the work that's been done in the past. So hopefully that is
useful from the perspective. Um.

210
Russ White 00:59:18.995 --> 00:59:39.785
Stuff, so I see totally said in data centers, you always have an out of that
network. Well, that's true. And some data centers and it's not true in other
data centers. Some data centers have gone just for port count problems to an
inbound network. So, it's not consistent. Uh, let's see someone else.

211
Russ White 00:59:40.804 --> 01:00:00.874
Um, yes, exactly. Same based optimization. And, as I said earlier in the chat 1
thing to remember is that optimizing for 2 metrics, like bandwidth and energy
usage is technically MP complete. You can't do it, but you've got to merge the
metrics somehow. You can't actually run shortest path 1st or even BGP.

212
Russ White 01:00:01.240 --> 01:00:21.905
Of the reason, BGP is by stable is because we try to optimize them multiple
metrics. And when you do that, you end up in a non atomic state where order of
operation makes a difference. And things are gone are hard. Yes. So any
questions or thoughts beyond what I've just tossed out here.

213
Russ White 01:00:22.654 --> 01:00:23.374
Appreciate it.

214
Eve Schooler 01:00:24.754 --> 01:00:37.534
Right and there's this very rich conversation going on in the text so much so
that I finally stopped looking at it because I really wanted to listen to your
talk. So if there are people who feel that their question has not been
answered. Please jump in.

215
Eve Schooler 01:00:47.074 --> 01:00:47.524
Okay.

216
Eve Schooler 01:00:49.180 --> 01:01:10.325
It was fascinating Russ, especially given your, you know, the level of detail
to which you understand the landscape within the, and what's actually going on
with routing. So that was really instructive. Although I can't say that I
understood all of the acronyms, but I'm going to drill into your paper in hoops.

217
Eve Schooler 01:01:10.384 --> 01:01:17.434
Finding some of that, um, okay, let us move on to the next presentation.

218
Eve Schooler 01:01:20.404 --> 01:01:32.824
And the next presentation should be on data formats. So, um, I'm not sure if
Brendan or Carsten 1 of you. There you go. Thank you Brendan.

219
Brendan Moran 01:01:33.064 --> 01:01:41.314
Yeah, I'd be happy to, but it looks like I have a minor glitch with, um, uh,
needing to have, uh, Webex have.

220
Brendan Moran 01:01:41.349 --> 01:01:45.784
Permissions to actually share so I might have to do a quick rejoin here.

221
Eve Schooler 01:01:47.105 --> 01:01:53.735
Okay, Kirsten are you are you able to present? Well, we'll wait for.

222
Carsten Bormann 01:01:56.314 --> 01:02:00.784
I'm not sure whether I should propose that we do the mighty casting 1st,
because.

223
Eve Schooler 01:02:01.414 --> 01:02:01.834
Okay.

224
Carsten Bormann 01:02:02.164 --> 01:02:05.974
The remaining 2 hours about medicals, but maybe you should.

225
Eve Schooler 01:02:05.974 --> 01:02:06.244
A.

226
Eve Schooler 01:02:09.004 --> 01:02:10.504
Okay, we can do that.

227
Eve Schooler 01:02:13.325 --> 01:02:14.405
Okay, I see.

228
Louis Navarre 01:02:14.885 --> 01:02:16.655
Yes, so do you see me.

229
Eve Schooler 01:02:16.745 --> 01:02:17.765
Yes, we do. I.

230
Louis Navarre 01:02:19.654 --> 01:02:21.604
Try to share my screen.

231
Louis Navarre 01:02:23.674 --> 01:02:25.024
Okay, so do.

232
Eve Schooler 01:02:25.024 --> 01:02:30.574
We see the screen we see the, it's not a presentation mode it just as yet, but
we do see, there you go.

233
Louis Navarre 01:02:30.994 --> 01:02:44.494
Okay, thank you. Um, so, uh, just 1st, so I'm a secondary pages students in
Belgium at, uh, so maybe my presentation would be like, a bit too much.

234
Louis Navarre 01:02:45.185 --> 01:03:05.885
Research oriented, but I hope that we will have some interesting conversation
afterwards. So, the, the paper in the position paper, we just wanted to
reconsider multicast because, um, we had problems with. Uh, and now we think,
maybe, uh, thanks to the energy impact. We have with music as it may be
interesting to reconsider at least for.

235
Louis Navarre 01:03:06.514 --> 01:03:27.094
Uh, applications in some networks, so just, I'm pretty sure you almost nobody's
multicast, but to be sure that we are on the same page, uh, quick reminder, uh,
with multicast, you avoid sending multiple times the same data in the network.
So um, sorry. Okay. So, for example, uh, here, imagine that this.

236
Louis Navarre 01:03:27.124 --> 01:03:48.034
To send the same data to routers, 12 and 4 with unique guests you will send
separately the data to each receiver. So you have multiple times the same data
flowing in the network on some links. For example, the 1st 1 and the 2nd 1. but
with multicast, you only send the packet once in the network and then the
routers, um, will duplicate this data.

237
Louis Navarre 01:03:48.364 --> 01:03:58.084
Um, to reach all the receivers of the network. So there are currently some
applications that use multicast, uh, for example, uh, and.

238
Louis Navarre 01:03:58.145 --> 01:04:19.265
Exchange, but we think it may be interesting to reconsider multicast for other
applications, for example, here, the, the, the conference we we just have now,
it may be interesting to reconsider the guests if we could deploy it, uh, in
the wider network, for example. So, in the position of paper, what we did, um,
was that we want.

239
Louis Navarre 01:04:19.294 --> 01:04:40.414
To practically show how multitask is more efficient than Unicast. So we made a
simulation of the journey at work, which is a composite of 22 routers in 306
links. And we, we just sent some dummy traffic from the source to an increasing
number of of receivers. And for that, we.

240
Louis Navarre 01:04:40.444 --> 01:05:01.534
We compared unique casting multicast and the most successful mechanism we used
was the beat index explicit replication protocol. So bear in short, because we
have an implementation of it, which is open source. Um, and for simplification,
we just ignored the communication setup. So, we just imagine that, uh.

241
Louis Navarre 01:05:01.594 --> 01:05:22.624
Receiver, uh, already made some music has joined in the multicast case and, uh,
already set up the, the traffic, uh, in, um, for the unit test case. So, the
1st thing, we of course, we know is, uh, is that music has reduced the bytes
footprints because, as we avoid sending.

242
Louis Navarre 01:05:22.744 --> 01:05:43.834
Multiple times the same packets, um, in the network, uh, when you start
increasing really measured a number of receivers uh, sorry for noise. Um, we
avoid sending multiple times in the same packets on some links. So, here, we
see that when we increase, uh, the number of receivers, uh, above 7, for
example, uh, we start having so we are just.

243
Louis Navarre 01:05:46.295 --> 01:05:46.775
I'm sorry.

244
Louis Navarre 01:05:48.814 --> 01:06:09.244
We will just send fewer bites on the network, um, compared to Unicast, which is
more linearly. Because when you increase, when you add a new receiver, you
will, um, send individually this packet to the new receiver as we saw before.
Uh, the only thing we analyzed, uh, was the number of CPUs.

245
Louis Navarre 01:06:09.514 --> 01:06:30.394
Uh, on the source, because with multicast, you only send the packet once. Um,
compared to sorry we moved. Yes, you send the packet only was once compared to
Unicast when where, um, you must send an additional packets. Every time you
have a new receiver. Uh, so here with multicast, uh, we have, uh, no increase
when we change the number receiver. Of course.

246
Louis Navarre 01:06:30.814 --> 01:06:48.814
Um, and this is, um, this will be more important, uh, when you consider, for
example, protected payloads because within the costumers encrypt separately,
the payload each time you want to send to a new receiver, but with multicast,
you could only encrypted once and then send it to the network.

247
Louis Navarre 01:06:50.464 --> 01:07:11.284
So, the, the, the question, uh, that we, we have now, is that most works well,
in theory. Um, but why isn't it more deployed to today's? And basically, when I
was doing my research, the, the question was the, because of this paper because
what it shows basically, is that with multi guests, we have issues.

248
Louis Navarre 01:07:11.314 --> 01:07:32.404
Everywhere and it's real difficult to deploy it. So, in the positional paper,
uh, we reviewed 3 of these issues, um, and try to find some possible solutions.
Uh, of course, this is an open discussion. So, um, you might not agree. And I
would be happy to discuss to discuss it with you. So.

249
Louis Navarre 01:07:32.705 --> 01:07:53.585
For example, the 1st issue was that I be multi guests, which was the, the 1st
major deployment of multicast, uh, required States, uh, on the routers for each
multicast group, uh, in the network. So some papers, for example, the doctor
multicast paper show that when you start increasing too much, the number of
groups, you might see packet loss.

250
Louis Navarre 01:07:53.614 --> 01:08:14.704
Because because routers cannot handle all that states, um, caused by the
multicast groups. So, 1st, work, which has been standardize, uh, in 2017 by the
IDF was to provide a kind of stateless or multicast for the mechanism called
beer. So I talked a bit earlier about beer.

251
Louis Navarre 01:08:15.095 --> 01:08:35.884
Um, and it's not widely deployed, but theoretically, it's really interesting,
because you, you, you don't have the state on the routers and you can only you,
the state is now embedded inside the packet so you can scale to an increasing
number of multicast groups. The 2nd issue. Um, and I think it's not discussed
very much.

252
Louis Navarre 01:08:36.095 --> 01:08:56.705
In the community, but it's that 20 years ago when you wanted to deploy a new
protocol, it had to be in the colonel. Um, because because of the performance
gap, we had between user space and current space. Um, we, we had to deploy them
in the colonel, but it was really a burden to, um, to implement new protocols
in the colonel. And that's why we.

253
Louis Navarre 01:08:57.423 --> 01:09:18.124
We stay and we stay with tcp for such a long time, but now, in 2022 this
performance gap decreased. Um, and so now it might be interesting to reconsider
deploying new protocols and new multicast protocols on top of, um, uh, Nike
multicast forwarding or a beer for wedding, for example, because.

254
Louis Navarre 01:09:18.784 --> 01:09:39.334
A simple example is the quick protocol which is implemented in user space, but
it's widely deployed. Uh, of course, because of Google, but it's wildly it's
been widely deployed and it only works in user space. So, no, we can build
these new protocols and not have the burden to deploy them in the colonel. So
they are also more easy to, um, to extend.

255
Louis Navarre 01:09:41.284 --> 01:10:00.484
The final issue we briefly discussed in the paper, and I'm not an expert in
that right now, so, um, it's open to discussion and I know it's a tricky 1,
but, uh, it's almost impossible currently to deploy multi guests, um, in the
wider network because of the internal policies, um.

256
Louis Navarre 01:10:01.265 --> 01:10:21.155
What we thought, uh, in the paper was that maybe we can think about multicast
overlay networks, uh, for example, using as a multicast release. Um, because
now decisions are almost everywhere in the world. So we can build a new
multicast overlay network on top of it. Uh, more easily compared to, before.

257
Louis Navarre 01:10:22.835 --> 01:10:42.785
So, there were, there are the issues that were that we briefly talked about in
the paper. So, for example, the data encryption, uh, dynamic groups. So imagine
that you want to have a protected, um, traffic between the source, and the
receivers um, what happens when someone leaves the group because you only, you
have a shared key.

258
Louis Navarre 01:10:42.814 --> 01:11:03.934
The source and the receivers, and if someone wants to leave this group, you
have to find a way to efficiently, um, definitely forward a new key to the
remit to the receiver that remain in the group without sending this key to the,
to the living a receiver. So, there are some, um, some possibilities. There
were some solutions.

259
Louis Navarre 01:11:03.939 --> 01:11:24.784
That were proposed, um, but it's still, I think, an opening research problem
also when you want to make some music traffic, for example, for software
updates, which is an interesting ID but you want to be sure that every receiver
currently received the data. Um, and there isn't any packet loss.

260
Louis Navarre 01:11:25.114 --> 01:11:46.234
But imagine that you are in a kind of a lousy network, or you have some bunch
of receivers in the last top, for example, uh, of the rest of, uh, router in
the music history. Uh, you must have mechanism to ensure that. The data was
currently received, and for them to tell to the sender that the data was lost.
So we have what we call the.

261
Louis Navarre 01:11:46.625 --> 01:12:07.265
Or not inclusion in real world multi guest, um, because we need the system to
say that we received all the data and it can be a problem, uh, on the source,
um, to receive too much of these acknowledgments, the 3rd issue. And maybe it's
1 of the trickiest also, is that.

262
Louis Navarre 01:12:07.895 --> 01:12:28.505
You want to have in some situations, a source authentication mechanism to
ensure that the correct sender sends the data to the receivers and that's, you
know, you don't have someone in the group having access to the share key, which
can be also used to encrypt data sending fake data to the network and flooding.

263
Louis Navarre 01:12:28.539 --> 01:12:49.684
Example, the receivers with display data, so to conclude, I would say that, of
course multi guessing is complex and we see that we have a lot of issues that
are not that do not exist with Unicast but I think it's worth the effort
because I discussed briefly in the paper and I think it's.

264
Louis Navarre 01:12:49.714 --> 01:13:10.804
The common consensus we have destroyed of between simplicity of deployment and
maintenance maintenance with Unicast versus the efficiency of multicast
forwarding. And for the past decades, we only wanted to make, um, simplicity.
And so that's why we removed almost everywhere. Multicast. Uh.

265
Louis Navarre 01:13:10.924 --> 01:13:13.204
Deploy unique solutions with.

266
Louis Navarre 01:13:13.775 --> 01:13:34.745
But, no, in this more energy, efficient, um, desire networks, it's time, maybe
to reconsider it and we can start having efficient networks. And if you don't
think it's an issue. But I, I mean, all of us think it's maybe an issue. Um,
just recall that during the currently various crisis.

267
Louis Navarre 01:13:35.074 --> 01:13:55.954
Um, the, the French government, but apparently also in the rest of Europe's,
but the French government asks Netflix to reduce the video quality, uh, of
their, uh, series and film, just to release the pressure on the network. So, I
don't say that we must do multicast for Netflix, but just to say that, um,
congestion in today's.

268
Louis Navarre 01:13:55.984 --> 01:14:16.324
Works can also happen when you have a lot of people using the networks and even
we know that we know that is, um, a more energy efficient, um, mechanism. So,
in energy, if you want to reduce the energy, uh, footprints, uh, I think it may
be very important to reconsider it. So, thank you.

269
Eve Schooler 01:14:22.834 --> 01:14:43.834
Thank you so much and thank you for getting us up to date on what has
transpired in the multicast landscape since it is something that has been very
much discuss for at least a couple of decades or more within the discussed
advanced progressed. So it's.

270
Eve Schooler 01:14:43.924 --> 01:15:04.834
To see that your thesis work is in this area and I wondered, you know, at the
very beginning of this session I don't know Pascal are you still hear you had
made a question about on protocol designs? Um, add to the list of protocols.

271
Eve Schooler 01:15:05.225 --> 01:15:20.885
Evaluate, you know, so, in the very 1st presentation there was discussion about
well, what should we be looking at? I don't know if you want to stay in your
own if you want to expand on your common here add to the list the use of
broadcasting, reactive protocols.

272
Pascal Thubert 01:15:23.825 --> 01:15:44.525
Yes, thank you. Um, yeah, there was there was the presentation by told us on
the 1st day of this workshop. Well, uh, 1 of the items was the work that the
ATF has been doing, uh, pretty much the last decade energy savings in protocols
and probably the place where they.

273
Pascal Thubert 01:15:44.554 --> 01:16:05.644
Happen the most is the community because a lot of these protocols are designed
to parade on battery and effectively we have already designed routing
protocols, which incorporates some routing stretch to save energy and state in
the devices. And, for instance.

274
Pascal Thubert 01:16:05.680 --> 01:16:26.795
Interestingly enough when the design points for the repo protocol was that the
control could never exceed the data and that's that's an interesting
constraints if you look at it, but it was there and we had to cope with this
and and the, the design of the routing protocol was impacted by this, um, and
then, uh, I spent the time in my.

275
Pascal Thubert 01:16:26.829 --> 01:16:36.844
That we, we took a lot of care about in the 80 groups was the use of
broadcaster radios, because it's been said a lot that, um.

276
Pascal Thubert 01:16:38.794 --> 01:16:44.974
Energy consumption does not depend match on traffic. It depends on the or
capability.

277
Pascal Thubert 01:16:45.275 --> 01:17:05.795
Well, that's that's mostly true on wires on wireless. Um, it's a lot less true
and effectively, we see different stages. And we mentioned that to the
macrocosm actually, um, we, we see that there is a very low power state of the
device where it can only be a weekend. And there is a processor only state of
the device.

278
Pascal Thubert 01:17:06.334 --> 01:17:27.454
And when the radio is on, there is a big pick of energy consumption. I'm
talking about more 80 devices here. And then when the device is is transmitting
or or receiving data then there is another, uh, um, big pickup of energy
consumption. So you really see in which stage of energy consumption you are,
and we, we figure.

279
Pascal Thubert 01:17:27.514 --> 01:17:38.734
In particular to save energy, we have to avoid, uh, as much as we could the use
of broadcast. Um, and that's why we designed the, uh.

280
Pascal Thubert 01:17:38.825 --> 01:17:59.825
Uh, sorry enough Andy to, to avoid those those things. So that's what I had in
mind basically saying, hey, when we look at protocol protocol designs
effectively you can send them with energy in mind or not. And it, it's we, we
also did what was said, by the way, this idea of having a composite metric, we
rebuild works with.

281
Pascal Thubert 01:17:59.890 --> 01:18:20.945
What we call objective function, which is a composite metric, and effectively
we wanted to incorporate power. I mean, it's just an option that you can do in
this country. So, I'm fully in line with everything that was said by the way
and yes, we have some experience at the ATF and we would gladly share that and
possibly expand, you know, the user for designs.

282
Pascal Thubert 01:18:21.304 --> 01:18:23.104
Outside of the community.

283
Eve Schooler 01:18:24.364 --> 01:18:27.034
Right. Okay. Um.

284
Eve Schooler 01:18:28.324 --> 01:18:43.414
There were, I was hoping that the kind of the discussion about broadcast and
multicast, um, were sort of complimentary and, um, you know, share some spirit
of how do we get to efficiency so, that was why return to your question.

285
Pascal Thubert 01:18:43.654 --> 01:18:49.234
Okay, so it's like it's slightly related. It's just that basically if you want
to keep.

286
Pascal Thubert 01:18:49.265 --> 01:19:10.355
Houses with no power. You cannot have them expect data at any point of time.
There must be a lot to sleep which means that while they sleep. They cannot
expect data. So you have to design with that in mind. Um, so that's kind of
complimentary from multicast because if you stop still doing multicast, that
means that you have to have some, some idea of.

287
Pascal Thubert 01:19:10.415 --> 01:19:16.145
The schedule the way you schedule your multicare so the device can remain
asleep. So, yes, there is an intersection.

288
Eve Schooler 01:19:17.195 --> 01:19:27.935
Okay, thank you. Um, I saw that there was another question here about that may,
or may not have been answered.

289
Eve Schooler 01:19:31.265 --> 01:19:51.275
See, uh, it's a great observation that might help with the inter domain issues
we previously had, but isn't there also a different impact? If we have a node
in a DSL ISP? For instance, we have limited savings potential. Um, maybe that
got answered.

290
Jari Arkko 01:19:54.994 --> 01:20:01.264
Yeah, there was some discussion about, uh, business incentives for the to do
this and.

291
Eve Schooler 01:20:01.714 --> 01:20:11.344
Right and so I think the follow on question was where I was headed with dom's
question was why would reduce their revenue from.

292
Russ White 01:20:18.304 --> 01:20:25.594
It would just depend on what the business model looks like and stuff. Like, do
you.

293
Russ White 01:20:27.939 --> 01:20:36.814
In the CD and build a business model about it's going to around it to make
money doing multicast. It's going to depend on market forces more than it is
the.

294
Russ White 01:20:38.284 --> 01:20:58.954
Design largely, I mean, if somebody, if somebody, if somebody were to come to
optimize, for instance, and say we want to give you X amount of multicast
traffic, and we want you to shoot it for us in a multicast way and we're going
to pay you X amount of money and that seemed like a good deal. We would figure
out a way to do it. That's my.

295
Russ White 01:20:58.984 --> 01:21:09.754
That's my I mean, but checks make things happen. I don't know that anybody's
done such a thing yet. I think that's that's kind of a thing.

296
Brendan Moran 01:21:10.924 --> 01:21:20.044
It strikes me that there's another lever here and what it looks like to me is
that this is an opportunity for ISPs.

297
Brendan Moran 01:21:20.134 --> 01:21:41.254
To improve their peering agreements, right? If you've got an ISP that's
distributing roughly the same content at roughly the same time to a whole lot
of users. Then they've got an opportunity to pair with the and improve their
peering agreements as a result of the reduced traffic. That they have upstream,
so I'm not sure if it's it's a question of the cde.

298
Brendan Moran 01:21:41.260 --> 01:21:51.305
Themselves having the right incentives. I think that there is sort of a hybrid
of an ISP and a CDN where, if you put those 2 things together, suddenly you do
have those incentives.

299
Eve Schooler 01:21:54.994 --> 01:22:15.094
And, um, I think, kind of back to Jerry, I think while I was calling out your
question, I was trying to find it in this list of wonderful conversation, back
and forth was, you know, what's the business reason? Um, and 1 of the business
reasons could be what we just heard about, um, uh, which is, you know, from.

300
Eve Schooler 01:22:15.125 --> 01:22:35.915
Is there's energy efficiency to be had and the more that that becomes a
differentiator maybe this is, you know, at least this is what occurred to me
was maybe the use that and market that and that then allows them to adopt
whatever technologies, whether it's multicast or something else that.

301
Eve Schooler 01:22:36.754 --> 01:22:48.424
Allows them to claim that, and not just claim, but quantum allows them to
quantify how much they're saving by using these other techniques. So that might
be kind of an interesting thing that I anticipate developing.

302
Jari Arkko 01:22:56.885 --> 01:22:58.265
Martin has his hand up.

303
Martin Flack 01:23:00.755 --> 01:23:04.475
Someone who's worked for hockomock whatever decade I can say that.

304
Martin Flack 01:23:05.859 --> 01:23:10.324
I've never heard a philosophical objection to multicast inside the company and.

305
Martin Flack 01:23:12.244 --> 01:23:14.134
The arrangement of the way things work.

306
Martin Flack 01:23:15.934 --> 01:23:35.734
A lot of the business problems, and the problems on the client and and as I
typed into the chat, a lot of our CDN contracts are based on things like
gigabytes delivered to client. So, if if it could be accomplished with some
blend of multicast in Unicast or something like that, I think that would.

307
Martin Flack 01:23:36.965 --> 01:23:38.255
Be fine.

308
Martin Flack 01:23:39.724 --> 01:23:59.854
You know, a lot of the way that streaming kind of played out, makes it on
demand and unpredictable. If it was more like traditional television, where,
you know, HBO or Netflix said, hey, the show starts at 90 PM in this time zone.
You would be easier to kind of.

309
Martin Flack 01:24:01.025 --> 01:24:16.475
Take 1 take one's mind technically to try to use things like multicast. There's
also a lot of and rights things that kick in. Um, and the, the parts about
encryption and the presentation were interesting to me.

310
Eve Schooler 01:24:23.915 --> 01:24:40.025
Great Thank you for that. Um, any other questions here I had forgotten that we
had swap the orders and it was sort of feeling we had opened things up to the
floor. So let's return to the previous talk.

311
Eve Schooler 01:24:40.329 --> 01:24:44.674
And now that you have rejoined, let's let's see if we can get the slides.

312
Brendan Moran 01:24:51.365 --> 01:24:52.625
Oh, I think we've got it.

313
Eve Schooler 01:24:53.435 --> 01:24:54.605
Terrific. Go ahead.

314
Brendan Moran 01:24:55.864 --> 01:25:16.864
So, um, Suresh and and 1 of the other speakers gave me an excellent lead in
here. Um, there was some discussion about the, uh, you know, Suresh mentioned
that Carson has been working on, uh, IoT devices that last for a year on a
battery. And, uh, and I believe.

315
Brendan Moran 01:25:16.990 --> 01:25:37.955
Pascal also mentioned working constraint networks. I think that's a great lead
in because ultimately, what we're talking about here is a new constraint. We're
talking about an energy constraint on our network, and that's just another kind
of constrained network. So, the question that we have is essentially how much
can we steal from.

316
Brendan Moran 01:25:38.255 --> 01:25:48.935
Uh, constrained network technologies and apply to a constrained energy
networks. So, um, with with that in mind, we, uh, we started with encoding.

317
Brendan Moran 01:25:52.505 --> 01:26:02.795
So, the 1st question is, does it matter is this is this worth doing at all? Um,
if the difference that we get out of encoding things differently is small, then
maybe there's no point.

318
Brendan Moran 01:26:05.165 --> 01:26:25.835
Well, it really, it depends what kind of data we're encoding that turns out to
be the most important part of this. So texting chords encodes into text formats
as expected, but everything else encodes poorly. Um, binary data gets you a 33%
inflation. Integers are usually around 50.

319
Brendan Moran 01:26:26.104 --> 01:26:47.224
Floating point, it can range from not much to huge. Um, there's, you know,
structures are are also bad. And I think I just saw something in the chat about
security and encodings. Yes. I'm personally, I really dislike Jose from a
security perspective encoding binary, um, objects into.

320
Brendan Moran 01:26:47.229 --> 01:27:08.374
Just seems risky to me in a secure format. Um, but that's just me. Um, so
really there, it turns out there is an impact, but we need to quantify exactly
how big it is. So, what we did to try and work out exactly what we're dealing.

321
Brendan Moran 01:27:08.405 --> 01:27:29.525
With is to take a series of examples now is a sensor sensor measurement list
RFC. And the idea here is that we want to get some data that's representative
of non text things that are being transferred and encoded in either Jason or C.

322
Brendan Moran 01:27:30.664 --> 01:27:33.994
Uh, can you still see my slides or did they just disappear?

323
Henk Birkholz he/him 01:27:35.074 --> 01:27:35.914
They just disappeared.

324
Brendan Moran 01:27:36.334 --> 01:27:38.674
Okay, 1 moment, let's get those back.

325
Brendan Moran 01:27:43.114 --> 01:28:01.264
Right. We wanted something that was encoded in both Jason and, um, the idea
here being that we can actually show the difference between a common text
encoding and a common binary encoding. So was a great option. Because it
actually has both of those already, and we can encode either way.

326
Brendan Moran 01:28:02.134 --> 01:28:23.104
With with relative ease this, let us do this, uh, this chart, which gives you
an idea of roughly how much, uh, data is used by each of these examples. Now,
the examples themselves aren't that interesting for for this audience really?
The more important question here is what kind of size reductions can we see and
they.

327
Brendan Moran 01:28:23.109 --> 01:28:44.224
Wait a bit, but they're often a fair bit better than than a 3rd. So we can save
a 3rd of data. If we encode it properly. Now, I mean, how does this play into
into overall Internet traffic? Well, if the majority of the internet's traffic
is isn't taken up by video, this isn't gonna.

328
Brendan Moran 01:28:44.285 --> 01:29:05.405
Move the needle um, because really that comes down to video compression more
than anything else. And what we're talking about here is, well, it's
compression. Um, we're just, you know, an encoding difference can be a
compression. So then the next question is, how does this impact energy? So if
there's no real difference, but.

329
Brendan Moran 01:29:05.435 --> 01:29:26.525
Clean energy for texting coding and energy for binary encoding then there's not
much point in continuing this. So let's have a look and see if we can quantify
it a little bit. Now, this came up something related to this came up earlier on
the list, talking about always on capacity versus.

330
Brendan Moran 01:29:26.584 --> 01:29:47.704
Data dependent capacity, and a lot of the discussion that's gone on so far has
been centered around wired networks. But the question I would ask is how many
people are using exclusively wired networks in their homes, individual energy
use. Oh, from network traffic is probably largely WI. Fi, except in a business.

331
Brendan Moran 01:29:47.709 --> 01:30:08.854
Context so that to me, suggests that we should be looking at wireless
technologies as well, certainly in the data center. And in back hall, we need
to consider the, uh, the other side of things, the wired side. But the point
here is that the last step is almost always.

332
Brendan Moran 01:30:08.884 --> 01:30:30.004
Wireless, and that's where this matters now I'm not modeling WI. Fi here I'm
modeling with Laura and the reason for choosing Laura, and in this talk is
because Laura has some really convenient time on air calculations and it makes
it very easy to estimate the energy use. So Laura is a pretty good example.
It's also a widely deployed network, which gives us some.

333
Brendan Moran 01:30:30.010 --> 01:30:51.155
Good guesses on how things will work. Um, so the results of of this model are
that we get, you know, often, 30% are better energy savings by by doing this.
And 1 of the interesting aspects of using a low power. When is that the send
and receive energy is actually quite a large portion of the devices energy
budget.

334
Brendan Moran 01:30:51.785 --> 01:31:12.305
Uh, that turns out to be on the order of modules as you can see in the graph
quite regularly and those that's a substantial portion of the data. The
device's battery lifetime. We talked about this a little bit in the in the
paper, but you can see that the consumption of the devices actually.

335
Brendan Moran 01:31:12.334 --> 01:31:32.524
Turns out to be measured in roughly thousands of messages. So this, this turns
out to be an important thing to to quantify. We can look at the, the devices
lifetime in, in months for, you know, hourly messages and things like that. So,
it strikes me that this is an important consideration.

336
Brendan Moran 01:31:33.484 --> 01:31:46.414
There are some interesting effects that we found like, the, the overhead of
setting up a packet actually substantially reduces the impact on short
messages. Larger messages are less affected. Um.

337
Brendan Moran 01:31:47.559 --> 01:32:08.704
And this is mostly because of the messages and Laura are quantized to 127
bytes. Um, so, uh, there's some substantial impacts that we get from the, uh,
the energy reduction. It means you can have smaller batteries that means the
devices can have longer.

338
Brendan Moran 01:32:08.734 --> 01:32:29.854
And that's a question of both cost and E, waste. You can use smaller energy
harvesting systems and the devices themselves can be lower cost. So this has a
social justice and a, an environmental justice aspect to it as well by reducing
the we.

339
Brendan Moran 01:32:29.884 --> 01:32:36.094
As the could potentially make devices cheaper by making their encodings smaller.

340
Brendan Moran 01:32:39.154 --> 01:32:41.464
So, we have a couple of choices in the.

341
Brendan Moran 01:32:42.724 --> 01:32:48.334
Um, Jason, and it seemed very common for hierarchical data formats as of today.

342
Brendan Moran 01:32:51.155 --> 01:33:10.745
So, um, we get a lot of myths on text formats when we discuss them. I've seen
these these are quotes I have seen from people in in the discussions. So, this
is is not, um, and and this is, you know, this year I have had these
discussions. So this is definitely an ongoing.

343
Brendan Moran 01:33:10.774 --> 01:33:31.654
Debate people think that it's easier to debug Jason than it is to debug
seaboard and in my experience, this is not directly. True. There are many tools
to help you debug see more on top of that. We get a lot of discussions about. I
don't need to install a tool to look at Jason. Well, you know, you can.

344
Brendan Moran 01:33:32.044 --> 01:33:53.044
I know in a web browser so, that also is not directly a, uh, as as realistic of
a problem as it seems at. 1st. Um, but there's some unpleasant truths here.
These are decisions that we make as engineers and they're actually tooling pro
problems, not encoding problems. The vast.

345
Brendan Moran 01:33:53.074 --> 01:34:14.164
The majority of the data that we send isn't for us, as people debugging the
protocol, it's actually for a machine to interpret. So when we make decisions
as as members of the to pick a format, that's easy for us to debug. We are
actually incurring a long lasting cost for the entire world to bear.

346
Brendan Moran 01:34:14.674 --> 01:34:34.534
That we just to make our lives a little bit easier during debugging we need to
plan for the primary use case of our data formats, rather than planning for
what makes our lives easier in debugging. And that means we need to focus on
machine interpretation and constrained energy in our networks.

347
Brendan Moran 01:34:37.625 --> 01:34:56.465
So, there are a number of benefits to binary encodings. I'm sure I don't need
to convince everyone, but I'll just run through it anyway. Um, they're simple
to parse, which means we have lower embodied energy in our devices, do lower
code overhead and lower memory and we have lower active energy. There's less
compute overhead in.

348
Brendan Moran 01:34:56.499 --> 01:35:17.644
Order to actually interpret the data there's less per character work, for
example, escaping into limiting and we have less redundant conversion work,
converting something to base 64 to transfer it over a network in order to
convert it back to binary. Just makes very little sense. The lot of.

349
Brendan Moran 01:35:17.649 --> 01:35:38.164
Small conversion as well and then, because our data format is smaller, we spend
less energy and transmit and receive assuming it's a wireless network. Um,
there's lower interpretation complexity as well if the complexity for decoding
the format is lower. That means that the security posture of your system is
also simpler.

350
Brendan Moran 01:35:38.824 --> 01:35:51.664
And we end up with more deterministic encodings, which is good from a security
perspective as well. Um, largely due to white space and escaping choices. But
also due to a few other interesting properties that you'll find in Jason
decoders.

351
Brendan Moran 01:35:54.334 --> 01:35:57.544
So, we have some recommendations that we want to bring to the.

352
Brendan Moran 01:36:00.574 --> 01:36:21.094
Um, 1st off, I think that we need to consider content and intended use for data
representation formats. So, configuration formats, for example, text formats
makes sense. If you have primarily text content, then text formats are
appropriate, but if you have primarily non text content.

353
Brendan Moran 01:36:21.455 --> 01:36:42.245
We should be preferring for binary formats. This isn't a game changer for
impact. This is a small contribution, but it's also part of an ongoing trend
where more and more formats are indeed moving to binary encoding and there are
examples towards this, for example, http.

354
Brendan Moran 01:36:42.274 --> 01:36:45.424
Is, uh, is now supporting binary encodings as well?

355
Brendan Moran 01:36:46.804 --> 01:36:59.434
So, um, that's most of what I've got to say. Um, I, I see there's a lot going
on in the chat if there's anyone would like to I, I obviously haven't followed
it. So, if anyone would like to, to bring questions, I'd be happy to talk more
about this.

356
Eve Schooler 01:37:08.524 --> 01:37:27.364
You very much for your for your presentation. Very enlightening. There was 1 of
the questions that got raised and again, you know, it's a little bit off topic,
but it's, I mean, you're sort of speaking to methodology, not just the
specifics of Jason versus Jason versus.

357
Eve Schooler 01:37:27.905 --> 01:37:39.305
But, um, you know, uh, Alex asks the question how about the energy impact of
rust versus non rest of the need to continuously transfer all that state trade
off with the need to maintain state at the server? Of course.

358
Eve Schooler 01:37:39.815 --> 01:37:48.485
Um, and so I wonder if, um, I know that you and Kirsten also are involved in
some of that effort. So if you have some thoughts.

359
Eve Schooler 01:37:48.519 --> 01:37:49.864
There.

360
Brendan Moran 01:37:49.894 --> 01:37:51.544
well carson more so than i so

361
Brendan Moran 01:37:51.904 --> 01:37:52.054
but

362
Eve Schooler 01:37:52.054 --> 01:37:52.264
Yeah.

363
Brendan Moran 01:37:52.264 --> 01:37:53.254
To jump in on that 1.

364
Eve Schooler 01:37:53.584 --> 01:37:54.214
Yes.

365
Carsten Bormann 01:37:58.894 --> 01:38:16.714
So, if you want me to talk about rest, um, that's maybe a different discussion.
But it's also an interesting 1 because the rest, of course, is something that,
that came from the big web, which, which never has been particularly interested
in conserving.

366
Carsten Bormann 01:38:16.744 --> 01:38:37.624
Energy it has been more interested in actually providing scalability and it's 1
of the major scalability tools. We have there. Now. The interesting thing about
rest is that. It's really something that that describes the transfer layer and
you always can push out things into the application layer. If the transfer.

367
Carsten Bormann 01:38:38.105 --> 01:38:50.945
Doing the right thing for you, so, in many, real world West exchanges, we
actually establish application state to avoid having to send the same data
again. And again, and again.

368
Carsten Bormann 01:38:52.174 --> 01:39:13.114
So, it would be interesting to see if we have pockets where that actually
doesn't work very well or could be exploited to get better better efficiency in
the web. This has been has been not very popular because it really makes load
balancing a very hard.

369
Carsten Bormann 01:39:13.120 --> 01:39:16.295
Of course, not all of our communication needs to be load balanced.

370
Eve Schooler 01:39:21.305 --> 01:39:23.945
Was the same thanks. That was the answer to the rest questions.

371
Brendan Moran 01:39:25.235 --> 01:39:39.605
Uh, tutorial at this point, um, about, uh, putting things the other way around
that we need to build the diagnostic framework out a lot more. Um, my
experience in working with has been that the diagnostic framework is actually
quite a lot.

372
Brendan Moran 01:39:39.964 --> 01:40:01.024
Built out already just not being aware of the availability of those, uh, of
those diagnostic tools may be the issue. And so maybe there's an awareness
problem that we have, but I would still argue that within the we have an
obligation to consider the impact of the protocols and formats.

373
Brendan Moran 01:40:01.084 --> 01:40:20.494
We design and that, I mean, that is what this whole thing is about. I'm not
suggesting sunsetting protocols. What I am suggesting is that, as we build out
new protocols, we need to stop looking at the network as an infinite resource
that we can inflate unnecessarily to make our lives easier.

374
Eve Schooler 01:40:21.544 --> 01:40:22.174
And this.

375
Eve Schooler 01:40:22.234 --> 01:40:43.084
Also speaks to maybe what best now has been raising, which is we already have
security considerations sections in our drafts. What about sustainability is
this kind of analysis? Something that should be required? Not just in the
latter stages of draft development, but from the get go.

376
Brendan Moran 01:40:44.164 --> 01:41:04.384
I think that's a great idea. I think discussing why encoding choices are made
in protocol documents and in format specifications is a great plan because if
that reaches a stage of the, or at the, rather when the, the review is done.

377
Brendan Moran 01:41:04.535 --> 01:41:15.695
On an RFC, and it says, well, we chose a text format because it was easier to
look at in notepad than the has an opportunity to go back and say, well, that's
not really how we do things anymore.

378
Eve Schooler 01:41:16.505 --> 01:41:25.655
And actually you said something that really struck a nerve with me, which is
when we write down, you know, how we solve solutions. If we explain the.

379
Eve Schooler 01:41:25.684 --> 01:41:44.974
Why we made the decisions we made a lot of that, unless it's captured in an
email archive, that doesn't necessarily make it into a spec. So, maybe some of
this would be forced to be put into a spec, forced as in encouraged by having
at least some section of the draft that.

380
Eve Schooler 01:41:47.314 --> 01:41:53.914
Encourages the authors to talk about efficiencies with a lens towards
sustainability.

381
Carsten Bormann 01:41:56.765 --> 01:41:59.825
So, I think 1, sorry, Jerry, I see you as your head.

382
Carsten Bormann 01:42:00.909 --> 01:42:21.574
Quickly answer to that. I think we need to stop just taking certain default
choices for granted. So, why are people using Jason for protocol? Why? Well,
because it's popular and has been used for protocol.

383
Carsten Bormann 01:42:22.174 --> 01:42:43.204
And, um, I think that that's fine and in the history of the ATF, we, we always
have had those attractive protocols that attract energy. So, when when I was
still working in the context of of course, everything had to be done over CIP.
Because CIP was the attractive protocol.

384
Carsten Bormann 01:42:43.234 --> 01:42:59.854
Of the day, and at least in digital representation, Jason definitely is an
attractive protocol. And there are good reasons for that. And that was 1 of the
reasons why we copied most of Jason for zebra to make sure we can generate the
same attraction. But.

385
Carsten Bormann 01:43:01.654 --> 01:43:22.684
Why are you flying to this conference and not taking the train? Well, everybody
is flying to the conference. So why why should I not do that? And I think we
need to take the small step. Just just thinking about considerations like that.
This is not about just about Jason, so using.

386
Carsten Bormann 01:43:22.714 --> 01:43:26.224
Instead of 1 has exactly the same advantages.

387
Eve Schooler 01:43:29.644 --> 01:43:31.924
Sorry would you like to check.

388
Jari Arkko 01:43:33.995 --> 01:43:55.115
Brought up in the chat, but, um, basically, I was just wondering, I mean, this
is obviously, uh, very sensible and W, W, we definitely do this. And and your
argument as well will take. And but I, I was curious if we had, uh, data on
where, in the Internet, with what parts of tech, or what applications we might
have biggest issues with regards to the.

389
Jari Arkko 01:43:55.144 --> 01:44:16.264
Formats do, we actually know that if we do know, that could be quantify how
much we would say, not as a percentage of in this protocol, but sort of more
more on a global basis. I understand that for a particular deployment. For
instance, the battery lifetime impact would be massive.

390
Jari Arkko 01:44:16.504 --> 01:44:36.754
And and very, very much needed, and that's the reason to do it, but on a global
scale, maybe the web protocols. Uh, and but on the other hand, they're kind of
moving a little bit towards binary. Um, so what what are we talking about? How
much could we say is this going to make a dent.

391
Brendan Moran 01:44:37.144 --> 01:44:37.414
So.

392
Brendan Moran 01:44:37.624 --> 01:44:58.564
I, I mean, this is gonna be highly protocol dependent, but you can take Jose
versus Jose as 1 example, because both of them are getting a fair bit of
deployment. Um, and that I, I mean, most of the the issue I have with Jose is
that it has basically 4 encoding.

393
Brendan Moran 01:44:58.569 --> 01:45:19.444
So, from that directly, you can see that there's a 4th savings without even
going into the rest of the, the encoding questions. You get a 4th savings
directly because Jose uses 364 encoding and seaboard uses a plain binary
representation. So.

394
Brendan Moran 01:45:19.865 --> 01:45:40.355
From that, in in authentication, uh, or encryption formats that are based on
Jose, switching to seaboard, saves you a 3rd, and that's probably a minimum
because there are a few inflated. There are a few other inflated bits and
pieces. Um, I think that's probably the, uh, the relevant part. Yeah.

395
Jari Arkko 01:45:41.014 --> 01:45:50.134
I, I guess what I was looking for is, like, how, how often are these things
used and, like, I am, I using them every 2nd or it's every, every 1 of my voice
packets on this call.

396
Brendan Moran 01:45:50.314 --> 01:45:50.644
You.

397
Jari Arkko 01:45:50.644 --> 01:45:51.544
That or.

398
Brendan Moran 01:45:52.024 --> 01:46:02.014
Yeah, so this is the the point I was trying to make earlier, when I said that
the vast majority of the traffic on the Internet, as I understand it today is
done via.

399
Brendan Moran 01:46:03.574 --> 01:46:23.164
Done via video traffic, right that's that's where the majority of it goes and
video traffic's already highly optimized for, you know, a lot of reasons. Um,
but if you want another data point, there's a lot of email that goes around and
email is mine encoded and mine is base 64 whenever it encounters something
that's not asking.

400
Brendan Moran 01:46:23.169 --> 01:46:44.314
So that being the case, you still get that 4th inflation, it's actually the
same 1. so that being the case, if we looked at email, then switching to a
hypothetical based email representation of mine or sorry seaboard, based
representation of mine.

401
Brendan Moran 01:46:44.344 --> 01:46:46.774
You would save a 3rd.

402
Jari Arkko 01:46:48.424 --> 01:46:50.284
Okay, that's a good example. Thank you.

403
Rob WIlton 01:46:53.584 --> 01:47:11.794
So, I was gonna ask a question, though, is for you, printed off for 1 of the
differences between say using Jason and seaboard is really about how you encode
the identifiers of a, what, a particular field means you have a choice of
whether to use a string which is always human, readable or numerical identifier.

404
Rob WIlton 01:47:12.519 --> 01:47:33.664
Can be converted to string in some manner by some lookup table somewhere. How
far are you proposing we push this? Are you proposing? We should use the string
identifiers introducing American identifiers or or is that not something you
you looked at in terms of? Because I think that makes a difference to how it is
to debug it. Decode it. Can I see the names? Do I have to do some conversion?
How how is it is to use this.

405
Brendan Moran 01:47:34.564 --> 01:47:54.814
Yeah, so I thought about this a lot and, um, I think there is actually 1
missing tool. Um, and what that tool would be, uh, is a web based decoder for
these things where you can stick the, which defines your structure into the
decoder along with data. That you expect.

406
Brendan Moran 01:47:54.844 --> 01:48:15.964
To match it, and I don't think that's a big step, because all of those tools,
as far as I understand it are available today just not joined up together and
available on the web. So this isn't a big stretch. Um, it's definitely doable.
And the direction I would push it since I come from the constraint node world
is all numeric identifiers because if you need to.

407
Brendan Moran 01:48:15.995 --> 01:48:28.655
Validate that structure, then you're going to need it's data representation, or
it's, um, it's data modeling language representation anyway so you might as
well save the.

408
Rob WIlton 01:48:29.135 --> 01:48:37.025
So so then my question would be is, for those cases, then you've got to get the
schema runway to decode it. It would it be better.

409
Rob WIlton 01:48:37.119 --> 01:48:46.594
1 of the even tighter binary coding, like, where it has to have the scheme to
decode the data and gets even tighter. I mean, so there's a trade off here
between.

410
Brendan Moran 01:48:46.864 --> 01:48:47.134
Yeah.

411
Rob WIlton 01:48:47.554 --> 01:48:57.214
You could press and I like I like, because it feels to me, like, it's a good
compromise between you can still decode it without requiring the schema. And
yet it's still quiet.

412
Brendan Moran 01:48:59.404 --> 01:49:19.414
Yeah, yeah, it's an interesting question and I don't know exactly how far to
push that and that's something that I would encourage each RFC author to
consider carefully which which direction they want to go with that I can see an
argument on extremely constrained nodes that it's useful to do use that schema
approach. Um, but.

413
Brendan Moran 01:49:19.444 --> 01:49:40.354
The same time, there's an element where maybe that's not the right thing in
each application maybe having a generic hierarchical structure, like seaboard
is more appropriate. And, I mean, I've been working on, on RFCs that definitely
do take the seaboard approach rather than the extremely tight 1. um, and.

414
Brendan Moran 01:49:40.774 --> 01:50:01.714
Partly, that's just for a code reuse aspect of things when you have devices,
especially constrained devices that use something to encode the data they send,
or decode the data they receive then being able to share that code turns out to
be really important. Um, and I'm not sure how reusable.

415
Brendan Moran 01:50:01.745 --> 01:50:11.525
That is once you get into schema base, parsers, I'm not sure. Honestly it may
be. It's a better choice and maybe that's something that needs more
investigation.

416
Eve Schooler 01:50:12.785 --> 01:50:22.865
I wanted to in the time remaining, I wanted to reiterate that we should open up
the floor to all of the speakers and all the presentations that were made.

417
Eve Schooler 01:50:23.374 --> 01:50:44.014
But there were a couple of comments in the chat that I want to lead that off
with and maybe before moving off of the conversation about, um, Jason, to kind
of point out business comment about social engineering. Um, so this is sort of
broader once again. Like, is there something that.

418
Eve Schooler 01:50:44.044 --> 01:51:05.134
Community can do similar to flying shame that Kirsten pointed out. Can we come
up with some kind of and I'm reading this can we come up with some kind of
social pressure for people? Engineers being pressured against using the wasting
wasteful encoding, wasteful protocols, wasteful equipment and towards the more
sustainable options. So, I wonder are there.

419
Eve Schooler 01:51:05.194 --> 01:51:12.124
Folks out there, who have an opinion about what is the social engineering that
we can do to move these levers.

420
Carsten Bormann 01:51:17.554 --> 01:51:36.034
Well, I'm not sure I, I have an answer to that question, but I think it's
related to, to 1 thing that came up in the chat which really is W. W. we are
not trying to make a rule here that you always must use Seebo where you use
Jason before.

421
Carsten Bormann 01:51:36.394 --> 01:51:57.334
But, uh, really the, the 1st step is to stop ignoring data representation
format is something that you have things to think about in your protocol
design. So the default choice of Jason may not always be the best choice. And
if we get there, then we already have 1 step. The next step might actually be
to get a.

422
Carsten Bormann 01:51:57.339 --> 01:52:07.894
Bit more more information out so people are not asking something like what's in
the chat. Should we use Siebel or? This is like.

423
Carsten Bormann 01:52:10.115 --> 01:52:30.935
Should use HTML or http and the 3rd thing, we can make improvements in
protocols without being entirely certain that the results will be significant.
This is again, like, flying to a conference, whether you are flying to a
conference or not is not.

424
Carsten Bormann 01:52:32.074 --> 01:52:38.194
To to change the climate, uh, but if you do it enough that it starts making a
difference.

425
Eve Schooler 01:52:38.644 --> 01:52:38.824
Yeah.

426
Carsten Bormann 01:52:39.094 --> 01:52:39.724
So, I think we.

427
Eve Schooler 01:52:39.724 --> 01:52:42.964
Really important to make considerations.

428
Carsten Bormann 01:52:42.964 --> 01:52:47.104
Yeah, we, we do have to make the small steps.

429
Toerless Eckert 01:52:47.854 --> 01:52:52.324
By the way I also tried to provide an answer on the chat already so I'm, I'm
already seeing.

430
Toerless Eckert 01:52:52.354 --> 01:53:13.414
In industries that have constraints unconstrained to devices in their use
cases, that they quickly recognize that when they start with a constraint
protocols, they can reuse them in the unconstrained case, but obviously not
vice versa and that helps to, you know, eliminate and a lot of further work the
reuse of the unconstrained protocols and duplicating the effort in the.

431
Toerless Eckert 01:53:13.534 --> 01:53:33.694
Strange world, so, in these cases, you don't need to do a lot of social
engineering only when that case doesn't exist. You may want to look it up like,
you know. Oh, right now you have unconstrained use cases. Don't you think
you'll have a constraint use case and that, uh, would basically be then be the
starting point is used from day 1 the constraint protocols.

432
Brendan Moran 01:53:36.125 --> 01:53:55.775
I think that's a great observation. And I, I think that that's something that
we should really be considering from within the, and I, I, I would, um, very
much encourage people to, to take that to any working groups. They participate
in just bringing up the question of, you know, should we.

433
Brendan Moran 01:53:55.780 --> 01:54:08.435
Adopt constrained node networking techniques in our protocols since they are
available. We know how to do them. And they mean that our protocols are more
widely applicable.

434
Eve Schooler 01:54:11.464 --> 01:54:32.284
Kirsten did you have another question you've sold your hand raised? Okay. Um, I
also wanted to return even though, uh, Russ has sadly had to leave the meeting.
Chris Adams had raised a very interesting question again. It's more general
than ross's talk. So.

435
Eve Schooler 01:54:32.439 --> 01:54:52.804
I would like to put it out there to the broader community Chris had asked, do
any protocols include the well I kind of rearrange the wording, but it it's
basically do any protocols include the ability to communicate how much longer
they are able to sustain a given amount of throughput or latency and, um.

436
Eve Schooler 01:54:53.704 --> 01:54:56.794
So, I wonder if folks might like to comment on that.

437
Eve Schooler 01:54:57.844 --> 01:55:13.384
Because I thought it was a question that again, if we're going to have some
more interesting optimization behaviors that, that the duration of certain
metrics is quite interesting.

438
Eve Schooler 01:55:15.334 --> 01:55:28.294
And this is something that, of course, orchestrators and data centers, which
are controlled environments are able to do because of their, than being a
mission and knowing all the nodes that are participating in their interactions.

439
Eve Schooler 01:55:33.215 --> 01:55:35.495
We weren't aware of protocols that are doing that.

440
Suresh Krishnan 01:55:37.354 --> 01:55:58.024
I I don't think it's something that can happen in real time. Right? Like, it's,
um, I, I, some of the constraints on protocols can consider the in the metrics,
but I don't think it's like a specific thing that's done. Um, but, uh, I think
Pascal is on the call, right? He can talk about like, role or something where
this is kind of taken into account, but it's not like something that's
specifically.

441
Suresh Krishnan 01:55:58.504 --> 01:55:59.524
How are you on there?

442
Pascal Thubert 01:56:00.694 --> 01:56:04.324
Yes, uh, I, I'm still here. Yeah, I mean.

443
Pascal Thubert 01:56:05.855 --> 01:56:26.255
There are many design points in. Some of them are effectively reused in raft
for instance. So this has already happened. And as you said, the reasons are
probably not for power, though. There is a big impact on performance and power.
And because it, we used some concepts from report now. Um, I was more thinking
about.

444
Pascal Thubert 01:56:26.794 --> 01:56:47.584
8,600 dollar discovery that there is a huge consumption of wireless resources,
which are related to the reactive procedures in traditional by discovery. And
that's 1 big big use case where we can look at. What, uh, Cisco partners don't
find the making.

445
Pascal Thubert 01:56:47.799 --> 01:57:08.644
Active and dividing broadcast and the use of broadcast and wireless is
incredible. I mean, that's that's a lot more than people think. We've, we've
made a measure of how many broadcast packets were sold, because offended during
a keynote by our CEO at the Cisco live and it was 300 per. 2nd.

446
Pascal Thubert 01:57:09.994 --> 01:57:29.914
Well, it was a big room, right? It is. And and most of that is effectively
canceled because we have proprietary code in our, uh, controls. And but the,
the protocol itself is incredibly chatty uh, and that's broadcast. And, like I
said, and, like, no, 1 is said, wireless is not wired for wireless.

447
Pascal Thubert 01:57:30.155 --> 01:57:51.245
The the, uh, expense, everybody's paid cash, it's paid in double pay it's paid
once because you're using spectrum and energy to send every extra bite and it's
easier to to the number of bytes it's paid. It's 3 paid because the NDA, the
merchant.

448
Pascal Thubert 01:57:51.785 --> 01:58:12.185
Of 1, losing this frame, because every bite can be where you stop, you know,
losing the frame and 2nd, that's when other devices might have to wait and, um,
so basically the load on your network and the queues form, et cetera and this
is additional energy. So, basically reducing the amount of broadcast.

449
Pascal Thubert 01:58:12.634 --> 01:58:30.304
Is a critical thing to do and is a big contributor so this is a perfect use
case for us to demonstrate how, um, low power concepts can effectively benefit
in in as well in any world. I mean, as well.

450
Toerless Eckert 01:58:33.695 --> 01:58:53.285
But maybe 1, other answer is the way I, I, I understand the question would be
that in routing protocols. We have a way to carry schedule based information,
something that applies to certain time ranges or time points in the future. And
I don't think we have done that, but we had, um, above at last item, eh, tried
to.

451
Toerless Eckert 01:58:53.289 --> 01:58:59.824
Investigating that the time very end routing. So maybe we are going to to look
into that problem.

452
Eve Schooler 01:59:05.525 --> 01:59:17.135
Um, John, would you like to, uh, make your comment that you just typed into the
chat? I think it's a really great question. Well, uh, perspective. Yeah Thank
you.

453
Jan Lindblad 01:59:17.165 --> 01:59:23.615
Thank you. Yeah, so, I mean, 1 of the things that are consuming a lot of power
in the IC industry is our monitoring.

454
Jan Lindblad 01:59:24.309 --> 01:59:45.274
We are monitoring networks and devices in large scale, and we need to. But
right now I think that much of that monitoring is happening in the broader
crude base, even back to doing polls and other things that are well, totally
inefficient. Actually, and we are doing this every few minutes with a lot of
devices and this is consumer power.

455
Jan Lindblad 01:59:45.574 --> 02:00:06.574
That equals many nuclear power plants that are devoted to this all year round.
So if we could do something to to improve that, I think we could actually do
make a dent. And also what's being popular recently is to pour some of that
data into data lakes. And apply some sort of algorithm to that and well, that
may be fun.

456
Jan Lindblad 02:00:06.634 --> 02:00:08.704
I'm not so sure it's power efficient.

457
Eve Schooler 02:00:10.204 --> 02:00:27.754
Right and and actually, um, to elaborate on that, I think that we're who we're
asking to define metrics and to do more measurement to get more insights. And
yet our measurement monitoring infrastructure needs to sort of be self
reflective and be efficient itself. So I'll be.

458
Eve Schooler 02:00:27.785 --> 02:00:30.305
That Alex looks like you have your handout.

459
Alex Clemm 02:00:30.515 --> 02:00:48.905
Yes, yes, yes, I just wanted to respond to, uh, I do agree that, uh, the way
it's done is often inefficient, however, that being said there are
alternatives, right? I mean, there is a lot of stuff, um, from from, from
streaming and subscribing to, to, to, to things to.

460
Alex Clemm 02:00:49.265 --> 02:01:10.055
Having basically certain events based the type of mechanism and so forth. So
part of this is again, not the availability of, uh, the technology isn't there.
That is not the question. But the question is, how do you use it and how do
applications make their choices uh, WH, which which to use so again part.

461
Alex Clemm 02:01:10.324 --> 02:01:11.164
Awareness problem.

462
Jan Lindblad 02:01:12.724 --> 02:01:20.224
Absolutely, and we have this, uh, if we start to measure this really where the
power is going, maybe this will become more apparent than more. People will
make a better choice.

463
Eve Schooler 02:01:24.065 --> 02:01:25.385
Chris, I believe you were next.

464
Chris Adams 02:01:30.245 --> 02:01:49.385
I just got a little bit on though my my question about some of that because 1
of the things that has come up, it seems is that networks are massively over
version of the time. And, uh, we're designing for the peaks, rather than, uh,
the average use cases. And, like, there are other other sectors that do have to
manage for peaks. And also the.

465
Chris Adams 02:01:49.624 --> 02:02:10.474
And also, uh, have averages, which are much, much, much lower and they've got
different ways to kind of basically pay to make sure that there is capacity
available and stuff like that. Like, we can look in the energy sector to see
how you have, like, peak plants, which are only on a few times a year, or,
like, batteries and things like this. That was why I was asking about. Is it
possible to have something where you.

466
Chris Adams 02:02:10.924 --> 02:02:31.534
Are able to say how long something is on, cause I I kind of was thinking that
we have ideas, like, say, happy eyeballs and things for finding out to multiple
low latency roots to kind of get to something if you know, that there's maybe a
low latency route that will last for a little bit time that can buy a little
bit of time for you to kind of default lots and lots of.

467
Chris Adams 02:02:32.014 --> 02:02:52.984
To being off, rather than being on by default. So, rather than having to think
about how you scale something down, you can flip it around to say. Well, we've
got a bit of kind of grace period to scale things up as as we know this
thundering herd is coming through. Maybe there's a kind of like, flip in the
way we think about this to make someone that possible because that is a
possible way that we might think.

468
Chris Adams 02:02:52.989 --> 02:02:54.694
About this I suppose that was that was.

469
Eve Schooler 02:02:55.354 --> 02:03:13.654
Yeah, and I think Charles is response also is very apropos, which is to have a
look at some of the time variant discussion, time, period rounding discussions
for exactly this reason if you actually understand and know a priori or can
predict with high reliability.

470
Eve Schooler 02:03:14.405 --> 02:03:22.805
The behaviors of links, then how would our routing infrastructure change? I
believe that Suresh was next.

471
Suresh Krishnan 02:03:23.315 --> 02:03:35.285
Uh, thanks, Eva. So, I think 1 of the things I'm kind of like, learning from
this workshop is, like, there's a lot of people with a lot of knowledge in,
like, specific pockets. Right? Like, you know, where they know of, like,
energy, efficient alternatives and so on. But I don't.

472
Suresh Krishnan 02:03:35.314 --> 02:03:56.404
I think we've done a good job, like, collecting these things. So, um, so my
high level point was that, um, sometimes people make these choices for a given
reason. Like, for example, like, what Dan said, like, somebody might have a
legitimate reason for, like, pulling this 24 7 at, like, 7th intervals or not
right? But I think, um, it's, I think we should do something.

473
Suresh Krishnan 02:03:56.524 --> 02:04:17.584
Stuff like, bring up these kinds of compromises, like, you know, what you get
and what you don't get, like a binary encoding versus, like, text encoding and
it's like, you know, a bunch of things that came up. Right? Like, you know,
multi castles is not multicast. I don't think it's like a clear solution. 1 of
them is better than the other. Right? Like, for the energy efficient different.
That's true. Like, you know, people have other problems to solve. Right? This
is not the primary problem to solve.

474
Suresh Krishnan 02:04:17.614 --> 02:04:38.704
The time, so I think, uh, it's an interest to start putting these things
together into some kind of document where we can actually talk about. Hey,
consider this, have you thought about this right and, and so on right? Like,
for lack of a better term sustainability considerations, or something like
that, like to kind of start writing something up, but not necessarily like, you
know, pushing people to put it into a document. Right which is like, probably
something we.

475
Suresh Krishnan 02:04:38.764 --> 02:04:45.454
That later, but at least for people to know, hey, that there are these choices
and for them to make a choice, not by default.

476
Eve Schooler 02:04:48.844 --> 02:04:57.454
That's a great suggestion. And maybe it's the best new methods or
considerations. Alex.

477
Alex Clemm 02:04:58.864 --> 02:05:09.304
I just wanted to add 1 more thing busy on the list of trade offs, I guess, to
consider, uh, Kelly, because prediction was mentioned. So, so clearly, if you,
if you have prediction, if you have.

478
Alex Clemm 02:05:09.905 --> 02:05:30.905
But, uh, predict what is coming of all, you can optimize certain choices but of
course, in order to do the prediction, uh, that in itself is typically, or in
many cases will be based on, on, on updating more data and the interpreting the
data. And so clearly, we have the, the other trade.

479
Alex Clemm 02:05:30.965 --> 02:05:43.685
Then, basically, how much is the additional expense of obtaining all the data
consuming this through your learning matching whatever, algorithms, versus the
benefit that you derive from that from having better predictions to make better
decisions.

480
Eve Schooler 02:05:45.845 --> 02:05:46.505
So, true.

481
Eve Schooler 02:05:51.454 --> 02:06:08.854
Well, we have 5 minutes left and I'm wondering maybe for some of you who
haven't spoken up, would you Here's a moment, maybe to ask your question that
you've been dying to ask or anyone else, who has a final remark.

482
Eve Schooler 02:06:13.924 --> 02:06:30.034
I really would like to thank everybody for the broad range of comments and, uh,
and questions and presentations thoughtfulness. It really has been, um, it's
almost overwhelming. The amount of information flowing from all up all.

483
Eve Schooler 02:06:30.130 --> 02:06:36.605
Corners of the so to speak all the layers, all the constituents, it's really
been quite helpful.

484
Eve Schooler 02:06:41.764 --> 02:06:51.154
All right, uh, or, um, Colin, any final closing remarks.

485
Jari Arkko 02:06:55.025 --> 02:07:15.245
Yeah, no, I think Colleen wants to say something I was. I'm trying, I'm trying
to figure out WH, what did we actually go through and what what are the
conclusions and, um, I wrote down, uh, in my notes that, um, yeah, step 1
awareness that this is just matter step 2 is visibility that we actually can.

486
Jari Arkko 02:07:15.425 --> 02:07:36.185
Can a certain have metrics and so forth step three's improvements, um, could be
in many different places, implementations and, um, and technology or even
energy sources. And, uh, it was interesting that a lot of this actually doesn't
have to be a compromise. It can be a win win for everybody that you can get
more battery lifetime and.

487
Jari Arkko 02:07:36.514 --> 02:07:57.544
Their network, and, uh, less energy use, but you also have to worry about some
cases where you do have tradeoffs and Russ talks about some of those. And that
was very interesting. And we had, um, lots of different directions were things
that we could do. Um, automation that can optimize.

488
Jari Arkko 02:07:57.634 --> 02:08:18.694
Small time scales, uh, slowing down systems in various dynamic ways, um, using
better formats or interaction patterns that are actually designed for energy
consumption also in mind. Um, yeah, a lot lots of good stuff. I, I'm very
pleased with.

489
Jari Arkko 02:08:19.894 --> 02:08:28.624
This session, so many people from different angles that we're able to, uh,
provide information for everybody else. Thank you.

490
Eve Schooler 02:08:32.194 --> 02:08:41.344
We have 1 last session on Monday, and it is happening. It begins at the same
time. Is it also a 2 hour session?

491
Jari Arkko 02:08:43.714 --> 02:08:46.684
Uh, it is, uh, a 90 minute session.

492
Eve Schooler 02:08:47.044 --> 02:08:51.124
Okay. Um, so please show up we need your.

493
Eve Schooler 02:08:51.130 --> 02:08:51.820
Inputs.

494
Eve Schooler 02:08:54.454 --> 02:09:08.644
And debate and discussion, of course, as always, and we will post again, the,
the comments in the chat, which are equally enticing and need further
examination. In some cases. There's some great pointers that have been included.

495
Eve Schooler 02:09:12.304 --> 02:09:18.934
Okay, great. Well, with that, we'll give you a minute back and thank you for
showing up.

496
Pernilla Bergmark Ericsson 02:09:23.014 --> 02:09:24.874
Thank you so much have a great weekend, all.

497
Eve Schooler 02:09:25.804 --> 02:09:30.064
Ah, yes, some of you are at the beginning of your weekend, others of us at the
beginning of our day.

498
Pernilla Bergmark Ericsson 02:09:30.544 --> 02:09:33.394
Yeah, but it will arrive so sooner or.

499
Eve Schooler 02:09:35.524 --> 02:09:37.054
Thank you very much. Everybody.

500
Alex Clemm 02:09:38.044 --> 02:09:38.524
By.

501
Ali Rezaki 02:09:39.064 --> 02:09:40.354
Thank you goodbye.