Internet Engineering Task Force IRTF, 27 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF108 NWCRG 20200727 1300

Description

NWCRG session at IETF108
2020/07/27 1300

A

uh To be sure that you can listen and hear to me.

A

Okay, perfect. Thank you very much.

A

Okay, so I think it's time to start this is a small session in a way 15 minutes. So we need to be on time uh welcome to this uh coding for efficient network communications research group online this time.

A

So the goal of this group is to foster research in network and application layer coding in order to improve network performance. So we are focusing on the average recording and whatever revolves around this technology.

A

This is an official irtf session, which means that the not well will apply. We are supposed to follow all those rules. uh Nothing should be this is this should not be a surprise to you. This is the same, no change.

A

uh If you contribute to this uh session, then you are supposed to follow the irtf processes and policies which are exactly the same as the ietf one. So we are supposed to disclose whatever ipr you may be reasonably aware of, uh we are also supposed to behave in a reasonable and uh appropriate manner. So that's the goal of this slide.

A

So this is not a development standards uh working group. We are a research group. The rules are a little bit different once again. If you are not familiar, then you are invited to have a look at those documents.

A

And then there are some administrative aspects.

A

Though the pointers remain more or less the same, I would just like to say something specific to this session. This is an online session, so the session is fully recorded both for the audio and the video. There will be, of course, no blue sheets.

A

The blue sheet will be automatically filled based on the mythical and data tracker logs, so you are authenticated, so it's not a big deal to do that and if you want to take part in the discussion, if you want to ask questions or do comments, so please please uh raise your hand so we'll see on the top left corner a few icons and in particular this end, which enables you to ask for to be in the queue. So please do that. I will give you give the floor to to you in the other arrival.

A

um So this is the agenda for today's session.

A

I will be very brief for this uh introduction. Then I will move to the hackathon feedback very briefly also, and then we'll continue with an update, a presentation from nicola an update of the uh coding and congestion control in uh transport. So this document and then we'll devote the end of this session for the next steps.

A

We have important questions to discuss, so I would like to to share with you all of this.

A

uh That's the situation for the work uh having been done recently so for the first document, the network calling for satellite systems internet draft, we passed the isg review and we are now in isg review. So we are pretty close to the end and we are very happy of this. uh It will be. It should be the second ifc published from this research group on progress, the coding and conjunction control in transport documents.

A

I think the document is progressing well, so we'll have a presentation for this item and then there are a couple, a few four documents: four five documents that need to be well that are somewhat in standby standby mode, for which we need some action. So this is the case for the nc for cc and ndn requirements and changes uh documents. In fact, we need to start a research triple school in association with ic energy.

A

This is a bit different for the backed conting scheme, which needs to be. We should ask with a true button option. First, on this, I will come back on this at the end of this session.

A

We have two documents for calling for quick and once again, this is something we'll discuss at the end of this session, and the same is true for tetris protocol. So we are progressing well on some of those documents and we have some actions to be done needed for the remaining ones.

A

That's all we are planning to to held a meeting in the next ietf, which will be perhaps online or physical, we'll see. So that's all for this first agenda bashing. Is there any comments.

A

A

Is there any feedback from room? No, it's! Okay! Okay! So let's, let's continue with the next item, which is the feedback from hackathon. I will share.

A

I need sorry, I need to practice a little bit. I first need to stop. Then I will share something else.

B

Hello, everyone do you hear me.

A

B

uh Yes, so there was a problem, I'm sorry everyone, I'm late. There was a problem with my registration and uh by the way gather.com with the secretariat. It works. They resolved my problem in three minutes. So this is the good thing.

A

Okay, thank you so now I'm here yeah there's some echo, so maybe uh you could solve it otherwise, just to let you know, I've been through the introduction chair slides. So I'm now going to talk about the accustomed feedback.

A

Okay, here it is so we held our hackathon last week during a full week. We were sorry I need yes, so uh the goal uh we are the same, uh just to remind you the goal. This is a man to design a reference open source free codec. We are focusing on the the simple ilc fsc scheme. First, as a first step and of course the final goal would be to facilitate fcex tests and adoption in itf in general, for instance, we have a second goal, which is to challenge the generic api internet draft as well.

A

uh Small teams, this time, cedric myself and mary, jose all of us part-time. I apologize, but I had a little time to devote. Unfortunately, it's not that easy, that's personal feedback. I would have it's not so easy to to work to devote.

A

More time when you are online, it's not the same as being physically in the same room and working all together on the on the project we do. There are many distractions and at the end I had unfortunately a little time devoted to this uh hackathon and for different reasons. uh Cilic also couldn't uh participate, as he would have lied to, and my journal was also part-time. So we made progress but little progress, so the the source code now is uh here.

A

uh Most of it is here the c demo application has is done, which doesn't mean it's working fine, because we still have debugging to do in the core. Swift click, but at least the source code is here, and the python wrapper for tests and demos has been done also, so I would say that we are more now focusing on debugging than this. Yes, so that's a good sign at least, but there are still work to be done.

A

So the next steps for us is to continue this week, if possible.

A

We'll have some time at the end of the week, hopefully to to devote in this and then to have a an additional hackathon. Next ietf, uh with the cl, with the goal to clean up to do more tests and to improve documentation.

A

Also, we have this internet draft that has expired now, but that could be revived very easily. So currently, the goal of this internet draft is to discuss and present the api, the common api only, but I would like to enlarge the goal with also some information on how to use it. That could be useful, regardless of whether this entire draft is published as information or not that's a side question, but at least to have this documentation, along with the.

A

Swift codec could be should be very useful. So that's the situation, I don't know if there is any comment. If anybody wants to say something, I see nobody in the queue.

A

A

Okay, so let's continue with next item so I will nicola. I will do the I represent the slides.

A

You will tell.

B

Me we change, I suppose, there's somebody taking minutes.

A

Good point I forgot to ask you.

B

um And um well I I've taken a few notes, but uh we have the recording, so we can always take notes.

C

From the recording but.

B

And uh uh it's one of these days, so my uh my jabber doesn't work. So um I'm not seeing what's going on on jabber. But that's I guess. That's fine.

A

Nicola, can you hear me? Yes, we can, uh if you can uh speak a bit loudly.

D

D

Okay, um I will try to speak louder, perfect.

C

D

Hello, everyone. um This is a quick update on the draft on the interactions between coding and condition control because of what happened in a recent few months.

D

We couldn't have done as much progress as we had initially wanted to, but still we tried to make some updates on the documents based on the feedbacks we have received from the list.

D

I think I've tried to put lots of text on the slides in case I have audio or connection issues, so I guess the discussion can start.

D

uh I will just wrap up what we have in the document at the moment and we have some on the point open point for discussion at the end. The next slide, please, basically the objective. The current objective of the document is to discuss how fake coding and constraint control can coexist and also, basically, we have seen too many research papers when people compare the fake mechanism with others and from consider congestion losses. Some doesn't so.

D

We were thinking that there may be a need for the research community to have always the concern control considerations in mind when comparing fake coding solutions.

D

So next slide: please, we have added what what we have tried to make new in this version of the document is to always mention uh the client aspect and not only the server aspect, so we I have here all the new figures. My point here is not to go through all the figures, but um basically try to comment.

E

D

Basically, what we start the document with is to be clear that there are two different channels. We have the conjunction control channel and the fake channel. Both of them are theoretically decorated, but they can use in different implementations the same signaling signals to, or they can at least interact between each other.

D

So medically the condition control channel is just we send source packets to a receiver, and um we may have, on the reverse, pass some information signaling that helps us have information on the current state of the network. So we can have what packets have been received, what have been lost, some specific markings and on the fpc channel we can send repaired packets with their packets and also we can have information on what packets have been repaired and how to add that the fec coding mechanism so next slide. Please.

D

We have divided the document in different cases. Whether fec is about transport. Fpc is within the transport or below the transport in case where fec is above the transport, what we mentioned in the draft and is that there are many potential issues when we have a rear, enabled transport, because the transport may detect losses where fec actually recover the problem.

D

So in this case we mentioned in his document that unreliable transports are more relevant. The good thing with this case is that, when adding um repaired, packets does not contribute to adding condition in the network. So that's good, but then the repaired packets are taken from what could have been taken to send actual data. So there can be an impact on the good put for latch transfers.

D

Next slide, please, when fake is within the transport, uh the cool thing is, is that we can do lots of uh concert and optimization um there's not as much gain as what um basically fpc may not do much better than what a classical transmission mechanism can do, and there is an impact on the actual boundaries.

D

So in this case um they it's very important to carefully design the continuation.

D

So one from some examples of what could be interesting in this case is to send repair packets when there's more, no more data to transmit, for example. So when the communication is over, we just send a bunch of repair packet depending on what the constituent controller does and also this let us do some.

D

Smart scheduling defending uh what may be needed to unlock the received buffer at the other hand, of the network when we have um received buffer sizes issues next slide, please fec can be also put put it below the transport.

D

So that is the case, for example, when you are doing tunnels mechanism so here that we can have lots of uh benefits when we have losses on the past, so we have presented previously in different ietf meetings that we can have more than one parts and losses in such common use cases, and this can impact a lot, is actual data transfer and for the end user experience.

D

There are cases where we have a mix of um when we have transmission losses that can be actually covered uh recovered by uh fcc mechanism. The problem here is when we have contracts and losses, and we are repairing them and we are hiding a congestion through the transport.

D

um So in that's why, in this case the same, it's the same, that the one before um very divining recording ratio is very important.

D

So what we have proposed in the documents, some of the approach that could be done to design how to carefully design this coding ratio it could be based on, for example, led bats protocol or basically, this kind of protocol to automatically adapt the amount of code ratio that we repair packets, that we send next slide please.

D

So we have tried to be more clear on um the classification or on when basically be clear on how fec and construction control can interact depending on how they are positioned.

D

And then the problem that we are facing at the moment in this document is our depending on the use case. Depending on the protocol you are using.

D

There are a lot of things that could be relevant or not to be done.

D

That being said, we have done some experiments, but I didn't have time to format the results, but basically we have done some results with experiments with tetris at the fec scheme below transport with a cubic transport, and we expect to produce a result soon with a quick as transport mechanism, and we have done some lots of experiments on different satellite use cases.

D

Mobile mobile systems losses that we have when we have optical links or congestion losses, so we expect to present some results. We are working on that because this kind of thing is important in our use. Cases and distribution would take place to carefully design the coding ratios not to shoot more data packets in quantity networks, um but then um I think we are now facing a problem on what, uh if, if what we have in the document here uh useful first, uh we are just discussing some things. Should we move towards more recommendation draft?

D

Should we extend more from specific points? I think that to move forward on this document, um we may need some feedback from the group on this aspect.

D

So if you have any comments or recommendation views, please share. Let's share them with us. Thank you.

A

Okay, thank you nicola.

A

Is there any questions from the group.

A

Otherwise, I have a question in the conclusion you say draft is currently a discussion draft. If we stay with this goal to discuss the requirements, the problems, the potential families of solutions, without any going further, as a recommendation draft so being close to what we've done so far.

A

How far would you I would, if I would say, from a consolidated version, consolidated document.

A

What's what's the remaining work, what amount of work remains to be done for this if we remain with this optic with this, uh the fact that this remains a discussion draft, what will you say.

D

I think, I'm afraid to open a pandora box on all the potential solutions that could be envisioned. um So I guess it depends on the time we could dedicate to. It could be huge, and that's also my point. Basically, we could do add more content, but is it if every time the the amount of the things we could put in it depends depends directly on the time we would dedicate to it? So I think it's important for us uh to be sure that this is needed, or if the discussion is taken elsewhere and.

A

Okay, so the idea is really to define the scope. What we want to have in this document or not depending on what time left we have that's the the main priority.

A

Okay, that's a that's a good point that needs to be uh yes that needs to be uh considered by the group, so us so that we have a realistic uh position and this uh document. Yes, I understand we could have something really large discussing a lot, a lot of things yeah, which is not necessarily the goal yeah. Yes, so please, please uh do contribute. Do ask do do do comment and uh how much you want to be in this document. This would be very useful.

A

Now there is a comment in the chat from dave. Maybe those of you who would like to to take the floor to discuss to say.

A

That now otherwise, I will read the comment from dave. One thing it might be good to cover is how to couple increasing transmission rate with increasing decreasing coding rates. It might be interesting to use increasing code rates as a probe to more satisf safely. Increased transmission rate, as this being looked at and dave spencer, is agreed.

A

Oh okay, I missed something. I did something wrong. I should have authorized.

A

E

So there should be in the queue there's a.

A

Highlight in yellow.

E

And you can press the green ticket.

A

Yes, yes, I was looking at the chat and uh okay. I overlooked the queue: okay yeah. Yes, so sorry, sorry for that uh yeah! So please uh and like you have the floor.

C

Yeah um thanks uh so my my question was across like it's a it's a two-part question. Maybe uh one is when we are saying it uh usually. Fec uh in other systems is part of the physical layer and it involves some kind of synchronization across the two ends because you're looking at latency per se, when you do any kind of block or any kind of a window based mechanism.

C

So is there any kind of synchronization mechanism uh being thought about either as part of the underlying transport or within the fec signaling? And the second part is again on the same lines.

C

Usually, the the packet networks have uh have an underlying differential delays, either based on their routes for the same channel or for the same uh session, or it could be also differential delays over time so because of the changing uh congestion or other aspects of the network. So are these aspects being looked at as part of the.

D

Fec, um thank you for for the question.

D

For uh I think, my my the something that may be missing in the document is for the moment we present the two channels as being um different for being the more generic as possible.

D

um We did not dive into the details on what happened in if they are not actually separated channels and how the signaling would be done, because I think it is depend depends a lot on the the mechanisms that are actually used, but I think I think the point, and if we go further with this document, the synchronization and aspects must be pointed out as something that must be.

D

Defined or at least discussed.

D

Thank you. I don't know if that answers the questions, but I think it was more comment on how uh we consider the synchronization and the different differential delays that could happen between different things. I think something that depends on the protocol that I use, so I just can just take the point on that. We may need to mention that in the document.

A

Okay, spencer's comments or question spencer: you have the floor. No, okay, no.

F

uh This is spencer, and I just wanted to thank you for doing this work. um It is really it is really important um for the question about the discussion draft and the recommendation draft. um I do so. My my first question is you're thinking. The recommendation draft is uh for other people working in this research group or people designing uh protocols in the ietf.

D

um Thank you for the question. uh Well, I think that's something that we should for the moment. We are making a general statement draft and I'm not sure we have enough content to make actual recommendations for protocol designers.

D

We can make some general comment on if you do fec, please consider construction control may use losses as a constituency. No, but I think that's something that is quite generic. I'm not really sure to what extent we can actually make useful recommendations. I think it depends on how deep we go into the details depending on. If we choose specific protocols and then we may be able to do more recommendations such as how you could use vcn signals or not, what do we recommend?

D

But if you use this yen it makes assumptions on the transport, so I think to go further with recommendations. We may need to go further into the protocol that will be used.

F

Sure so, thank you and thank you for the answer. So what I was thinking was that you were talking about the discussion draft moving towards the recommendation draft. At some point.

F

My suggestion would be to do that as two different drafts, because I think the information that you're putting together in the discussion draft is important and I think recommendation draft. uh The protocol designer should be really crisp and short.

F

So I said this: this is really important because um the people in the itf have already you know, raised the issue. uh What happens if you manage to just to disguise all the uh congestion signals by repairing all the losses? So um I I think you know, I think, you're. I think you're doing the right thing. My my suggestion is that when you get ready to do recommendations that you do it as a separate draft, thank you.

C

Thank you very much.

A

Okay and here's a comment or question to you.

A

A

Okay, so in that case I see.

A

Okay, if michelle said something on the chat, I think we could try to recommend to ignore the losses or recover packets when using a loss-based conjugation control when the path is not completely controlled. That is to say, we know that we are on the satellite link and that losses are not due to congestion yeah.

A

Do you want to comment nicola or.

A

Okay, if there is nothing else, I will move to the last uh item of the day. Thank you nicola.

A

Okay, so let me share.

B

Okay, so this is me, I guess.

A

B

Okay, so uh next slide.

E

B

Okay, so I think um this is a little bit of the review of um what we were supposed to do and I think we've done pretty well um the um there's stuff on the tunneling that we haven't done, but the nc and icn we did the congestion control. We've talked about it, the vr we kind of abandoned it at one point, because it was.

B

Too much uh we, we did a lot of work on the um the I wouldn't say the common api, but at least even the stuff that we did on the um the hackathon was related to that the satellite we've done um and the the network coding and quick uh we're we're getting. uh We have two drafts there and we're getting uh very close to something.

B

This was delayed actually by the fact that quick was also delayed, and we have a solution for that now, but we were a little bit waiting for them and what we have also that is partly done is we wanted to have one draft for for existing solutions. We still have the tetris team uh that has promised to uh to complete their um their draft. uh The network coding, the network coding from mit, the random linear network coding. uh The drafts have been mostly abandoned.

B

I do not have any status on any of that, but we have at least one and obviously we have uh based on swift code, which is already adopted as a fec frame rfc. So I think, in terms of milestones we're doing pretty well.

B

um We've done, uh I think you know, we've had pretty successful meetings uh with the group. uh There was at one point a a thought of linking what we do with what they want to do in loops, which is a a buff forming there's going to be a buff forming meeting on friday. However, in the meantime, they've decided to look only at congestion, related losses and not losses related to uh non-congestion, but it's still uh something that they could do in their uh hub by hop in a way a view of the world.

B

But yeah we've been doing pretty well in terms of milestones next step next slide.

B

uh So that's actually the the the summary again of what I just said. So we have the rfc that's published. We have bats, I forgot bats. uh Bats is active and uh there's actually a lot of work uh on that rlc has been published. Like I said, tetris is active. We have two active quick. We have the almost done for the satellite and we have the common coding, swift and I think what's missing. Maybe you have it on the next slide. But what's missing here is um there's there's this newcomer thing? uh It's not!

B

It's not a draft, but it's actually stuff that we have there like. I said we decided to let a bit of it. Let it go of the draft. We have the congestion control that is very uh much was presented today and is being uh in progress and, and we want to make progress on it and the draft fancy in icn is really active and, and we you know, we expect the last call very soon.

B

We decided to go away from the tunneling because it was not really related to us, but it could have been done in loops and maybe it will end up being done in loops, but so, like I said, we're pretty much um we're doing a good job. I think in terms of of the milestones next next slide.

B

So, um but in spite of everything I said so, let's now be realistic, where's the network coding research going essentially right now. What we see is that coding is just a subset of what is being done for efficient communication.

B

What is being done for efficient storage uh in order to you know, and caching also and everything, uh there's a lot of potential research and congestion control.

B

Although from what I see in terms of real implementation of network coding and systems, a lot of time again, they're done over tunneling, and then you know you, you resolve the issues of of congestion and other way, but that actually is still an open uh topic. But, as you can see, there's a lot of um from the draft. Actually there's a lot of requirements, there's a lot of recognition of the interaction between coding and congestion control. But you know right now there it's good examples, but there's not really solutions.

B

um I think uh what we think is happening is that the the field is is getting pretty mature. This has been going on for quite a while now and obviously, when it started. There was still this question that if there was a a role for network coding, there was a lot of research, a lot of it, driven by the mit group on essentially applying network coding to a huge um subset or even a super set of network applications and services, and there was the work.

B

Obviously the important work done in both indriya and uh and toulouse, and so there was, it was a very active role. uh Active field uh we've seen it a little bit uh going down.

B

uh I think another thing that we've been burdened at this group since the beginning of the group has been the huge ipr uh environment that has been a problem uh because there's a lot of patents in this field, there's actually a growing number of patents, and obviously this is a huge um impediment for people to go beyond the research. Obviously, when you just do research, it costs nothing, but when you start wanting to do technology transfer and there's a huge patent environment, everybody is a little bit careful. So that has also been an issue.

B

So with that what we uh vasa- and I we've talked a lot about this- um there's been other issues in again- ipr disclosure around the work that we're doing that we're late and a little bit um hard to take. uh So what we suggest is to adopt the remaining ideas that are mature and I think all of our ideas right now are very immature, so adopt them as rg item publish them as what they should be, which is informational or fc, and and what I wanted to say there about quick.

B

Is you know if we have an informational rfc on coding for quick? We would hope that the quick group would use that as a basis for a solution that could be part of quick, and it has always been part of the of them of the road map for quick, so that if we have this, this rf informational, it could be a basis for um either another drafting, quick or at least to influence the solution, and we will close the group in about a year from now.

B

uh So you know for having done the job we were supposed to do. uh So this is a suggestion. This is not uh obviously um um this final decision again we we uh we have these particular. I spoke a lot about um about the fec for quick, so uh we can't really wait for for quick.

B

You know for our ideas, so what I think uh I can put my my my uh other hat here is that I think we will focus on the major aspects that we don't expect to change in quick uh and then publish this id as again like I said, as is here quick guys, it sits here. It's an it's a it's a framework for your solution and, of course, uh us authors are ready to participate in making this happen uh in quick, uh the fec at loops. I spoke to karsten a lot about it.

B

Like I said at first, they were very open and uh putting um putting some coating inside loops for the moment they they put it a little bit on the side. I have the impression that I know why, but I will not put words in people's mouth, but it's it's on the side for now. Maybe it will come back, but in any case they would have if they ever decide to uh bring it back.

B

They would have the whole raft of rfcs that we would have on on the requirements for the congestion, for example, this this uh interaction that they will have to to deal with between uh congestion and and non-congestion losses. They would have uh the solution for tetris they would have. They already have obviously the fec frame solution, so I think that would actually be a good way to start with loops. So I I don't think that would be uh problematic again. This is a suggestion.

B

uh This is not. Is there another slide vessel.

B

This is the okay. uh So again, this is a suggestion. uh We've discussed this uh with um some people before uh throwing this. We didn't want to be, but I think again that we've, uh I think, we've done a lot of what we wanted to do. uh I think for people who've participated in this since the beginning.

B

I think we've had a. We have now a much better understanding of what network coding can do in a network. uh What are the potential solutions? What are the potential uh tripping, wires and and yeah? I think it's time to decide that. Maybe we want to move to something else um and we welcome comments, uh obviously we're going to put that on the list eventually, uh so that um other everybody can chime in um and um the authors of current drafts uh suppose there's a few on I've.

B

Seen a few on the on the the list uh on that the meet echo uh be prepared uh to to work on your drafts to make them ready to uh transition to informational rfcs, um and I was pleased to see that nicolas said he had a little bit of time.

B

uh We'll uh we've already again contacted the tetris team, so they're aware, I know the bats team uh are are very eager of of moving forward and I think the two, the two others are also very much ahead into uh approval. So I think we're great there and um yeah. um Is there any comments? um Is there any? um um Yes? No, whatever people, okay, uh spencer,.

B

E

F

F

I've been talking to the proponents like in the last 48 hours and trying to make sure that they were really consistent on their uh their position on uh where uh fec was in their proposal. So um take a look at their take a look at their slides that were just uploaded uh last night. I guess um and see see what you think, but uh I hope that there uh is some discussion about around that about uh about uh fec with loops at the buff on friday. Thank you.

B

uh Okay, thank you. uh Maybe uh I I intend to participate in the loops uh meeting on friday and um I may raise a question again uh with them. uh Colin, you were on the you were on the line.

E

Yeah hi, um so I think both the the loops and the quick uh documents are pretty close to the idf work. So I think we should have a conversation about whether they get published as informational things here or just uh moved into the itf and pushed into the relevant working groups. There.

E

um The rest of the work, um if your services, the chairs and the office, uh are happy to to finish the work up uh and believe that the group has then achieved its goals, then that that seems like a very reasonable approach and I would support support the plan.

B

Yeah um as far as the um yeah, the congestion control, I think, is not strictly for loop, so I think it. I also spoke to yana by the way, to push it into uh the congestion control. I think that could be a standalone. The quick, I agree is closer to an ietf uh document and we could but I've I've been very careful. I've talked to lars about it, and I've been very careful of not to overwhelm them with um yet another document.

B

So I think our idea was that to use it as an informational on an approach for quick and and then see how it works from there. But you know we have time to discuss.

E

Okay, we've got plenty of time to figure it figure. This.

B

E

B

um I see there's messages.

A

Officially, we have one minute left so.

B

Okay, yeah, I saw there, there was no uh okay. Well, I think then we're fine. uh I, like short and sweet uh again, I'm sorry to have been late. um I guess it's the problem of being remote. I will have now. I have a few days to resolve my my childhood problems.

B

uh Thank you, everyone. um I guess uh we will. uh I don't know if we're going to have a an interim before now in november, uh we'll see how the documents evolve, maybe to make sure that they evolve. We could have a very short interim, sometimes if not we're going to obviously meet in november, so that we can have all these documents um being um um you know advancing to where we would like them to be and um yeah. um Thank you everyone. Thank you very soon.

B

Thank you nicola for the presentation, thank you for uh the people who ask questions and thank you for all the participants, and hopefully uh everybody is safe and and healthy. Thank you.

A

Thank you. Everybody thanks.

A

A