MANET Meeting IETF 118 17-18:00 Nov 7 2023
Chair Intro
Don Fedyk, Donald Eastlake. in the Room and, we have Ronald in’t Velt remote. We are the chairs of the Manet Working Group.
- Agenda
- Note well
- Note Very Very Well.
- Current drafts status (Ronald)
Ronald: I've produced another shepherd write up this time for the Traffic, classification, draft, Please check it is completed all the questions answered, in the right fashion, and I will follow that up tomorrow with the 2 remaining, drafts because all these separate write ups are very similar I will then push, DLEP either credit flow control extension to transport area review because, David Black has not seen that one. David Black in the past, specifically asked us to justify why we have 4 drafts and I think the justification is now given in the Shepherds, writeup, I understand the frustration of Lou Burger [for the delay].

Don Fedyk: Are you still missing some, IPR declarations from some of the authors?
Ronald: Yes. It seems that the, co-authors of Lou burger are not, responding anymore to requests for IPR declarations. Credit flow control, DiffServ credit flow control extension and traffic classification have 3 authors. We are still missing the IPR declaration of Boh-nan Chang for that form. David Wiggins has responded to that, a long time ago. However, for the ether credits flow control extensions, is only Lou and Dave Wiggins's, are authors and David Wiggins did not react to a request for an IPR, statement just before the San Francisco meeting.
Lou Burger: Two things on the co authors, I can try to reach out to Boh-nan, you need anything from him. I haven't talked to him in years. But I can try to see. For David Wiggins, I think is no longer working, or unreachable So it's unlikely we can get him to respond.
Lou Berger: Is there anything else we need to do?
Ronald in’t Velt: I have been looking at the previous write up for RFC 8651. And in particular, the security section for instance, the flow control, is it very similar to an earlier that became RFC8651. It went through a number of enhancements, based on, comments from the IESG. It became a more full fledged security section in the final, drafting the RFC. And I think we can stave off some the same comments, in the new, IESG process by more or less copying from RFC8651. Into, into these drafts.
I'll write it up on the mailing list.
Lou: I, think just copying information that is in a base document. Rather than point it to the base document, is not a way I would go. I would point to the base document unless there is something new being introduced. And if there's something new, we need to treat that appropriately. But if it's just repeating what's there, well, that we're writing an extension to a protocol, we shouldn't have the same considerations. In my opinion,
Ronald I tend to I tend to agree.
Lou: But we could talk over the details once you get it on the list. If you need anything else, just let me know and I'll do my best to reach out to Boh-nan and with respect to David, maybe have a offline conversation with the AD about it and or the editors. Thank you.
Donald, Eastlake: I just wanted to say there is a process whereby, if it's impossible to get IPR declaration from an author, with the AD's approval, it can be put through assuming you've made all reasonable efforts to contact the author, etcetera, and he decides it's the way to go.
Ronald: Is there is a, reference in any form to that process?
Jim Guichard: As Donald said, if you've made every effort, to, to contact one of the authors, then I guess we have a couple of choices. But I can, take that as an action. I'll check with the IESG what, what the best practice is. One option is to move the author from the front page is a contributor. That's one option. If the working group agrees to that the second option is that, you know, I can approve it based on showing that we've made every effort, but leave that one with me, and I'll, I'll take that
Ronald: Thank you.
Abdussalam Baryun: Presentation: Uses cases and MANET Protocols
Thank you The Presentation MANET is use cases and, proposed managed routing protocols. Actually, this, presentation, came out of, discussions, on the mailing list before and, maybe also recently in this year.
The [use] cases, we referenced in the MANET RFC 2501. Which was mainly, a reference by all. I think, our, documents, and usually, It has been from maybe, I think, 1999 or about the so it's been long, time. And I asked before if we can update this RFC document to include some new technologies, but, I think in 2014 or 13, the there was a, objection from the working group. I still think that maybe we can add some new cases or, included or discuss it also, or discuss also scenarios as we see in the use case, new use case.
Uses cases:
- There are new L2 technologies which are, are invented.
- Also, there's the 5G/6G work and, the future of the IOT
- Emergency communications, disaster situations.
These use cases are important for a MANET and, I don't think we covered, these, use cases. This working group also had already between 2003 2007 published experimental MANET routing protocols about proactive and reactive protocols after testing and [did] implementation for these protocols and, evaluating their performance we got to publish, through the working group or other working group, participants, publish the proactive, rooting protocol in 2014.
Through this, RFC 2501 measuring the protocol performance [was done.] Usually this depends on, important parameters or, some performance metrics. We have to check for to make sure the routing protocol is, working well with good performance.
As, our experimental routing protocols we have already got results on:
- changing the network size,
- the checking the connectivity or the number, average number of neighbors.
- Topology change,
- link capacity,
- mobility, usually, they were used we from, there are some different models or mobility models were used not all, but, there was testing for, the performance of, the our experimenting, routing protocols.
- And on the fraction of, and the frequency sleeping. I didn't see much results for that, but that are already, on IETF, published a new working group for, LLNs, and, and that they have already done some work for the particular issue, but it's even though if there's a sleeping notice, can be similar or, can be taken as also no doubt we can say link drop.
Monitoring performance
- Main metric, was the end to end delay.
- Also checking the throughput,
- packet delivery rate,
- overheads, the routing overhead.
- And efficiency.
Why am I looking at these performance [parameters] for measuring the performance? Because, also, I'm, interested to compare our new routing protocols, to implement it and to check its, its performance, referencing RFC 2501. For RFC 2501 is interesting and important, it should be recognized that a routing protocol or we can say a MANET routing protocol, tends to be well suited for a particular network context. So not all, routing protocols work for all, network contexts, but still in our documents, we can see a more general, description as this MANET routing protocol, can work for a general purpose, but when we start to look at different mobility models and different, traffic loads and, connectivity. There are many, advantages and implementations for a different routing protocol. Saying that we only need one routing protocol. I don't think is right statement.
For managed, Routing proposals, we had, AOD views, RFC3561 (AODV) and RFC4728 (DSR) as reactive, routing protocols experimented and evaluated well.
For, maybe 1 or 2 technologies that are under IP layer. AODV version 2, hasn't been, completed yet. I'm proposing if the authors, can, restart that and I'm also interested to propose the DSR version 2 the dynamic source routing.
I didn't get to published a draft 00, but I'm interested to include the managed packet and message format, which is a general packet format, which, our working group have already, published as a standard, RFC 5444. And RFC6120 is the MANET Neighborhood discovery protocol. I may use it as optional and, [for] this proposed protocol. And DLEP RFC 8175. It's important, very important for all routing protocols which will cover, disaster scenarios or disaster use cases and the emergency communication or hybrid, routing.
We discussed a little for hybrid routing, it is mentioned In RFC 2501, it mentions that we have reactive routing, and proactive and hybrid, and which was already the discussed in many papers and also was discussed on the mailing list. This is before I started participating [in MANET] but, the important issue is that, I expect also RFC 5444 packet message format as thought of because of, there was a view of having the future as a hybrid first, we start with proactive or reactive. And then in the future, we try to make it, one packet a hybrid which has routing, with retroactive and proactive. So a hybrid routing protocol was already thought of, I think, in my opinion. Also, fixing a neighborhood that a protocol has a, general, interface for all routing protocols was also, [of] interest, in, the working group. However, we may leave that in [until] we [are] finished, in my opinion, or my proposal is that we start the hybrid routing with or after we complete the reactive standard. There was a proposal from Chris Dearlove, on the list. I think he asked if we can start from proactive. I don't mind if we also look at, the reactive. And that there is also proposal for multi paths as well.

Don: I think this, will blend into the charter discussion, make sure you think these items are covered by the charter and you know, we need drafts to discuss this if it's going to move forward.
Henning Rogge: I would like to skip over issues we had with AODV in terms of metric and documents but would like to focus on something even more important. Running code. When we were talking about standardizing AODV version 2, even the authors of the document could not point me to a single working implementation. The best I got was something for a [Linux] kernel module version 2.4. something. Which was 10 years out of date at that point. So unless this has changed and someone wrote a good reactive AODV or DSM implementation that works there's no point in this document because it has no value. We have no way to evaluate them, we have no implementation.
Juliusz Chroboczek. Well, by the time when OLSRV 2 and RFC standard Babel were developed we had a fair amount of experimental data. That showed that OLSR V1 and pre standard Babel did actually work. There was notably the colossal amount of work that was done by a bunch of people, including handing in the battle mesh community. There were a number of published results in the peer reviewed. Press that indicated that these protocols actually work in practice and are not just a good theoretical idea. DSR and AODV are those extremely sexy protocols They look really good on paper. But I am not aware of as the published literature that indicates that they work not only in simulation, but they actually work in the real world. That doesn’t mean they don't work. [I am not aware] of any such published results. And I would very much welcome being able to work on AODV they would be great fun to work on but until we have experimental results that indicate that they actually do work I think it would be premature to charter them in this working .
Hennig Presentation: More Metrics for DLEP
I started to I have quite a few DLEP drafts I would like to add to the working group, but I focused on ones for the physical layer.
These are, currently, the radio band draft is in the first revision and the channel utilization and radio quality drafts in the third revision.
The radio band is just primarily used for the radio to have a standardized way to tell the route of what frequency resource it used. It's center frequency and the bandwidth.
This can be, for example, use in, further metric experiments calculating some kind of spectral efficiency We can check this with current lists of frequency bands we don't want to use to make sure we don't have a misconfiguration in a external radio. And I knew some coworkers that like to work on cognitive radios so they want to adjust this frequency and stuff like this on the flight during run time. And with DLEP, we could do this with the request[ed] link characteristic. That's why I think the radio band draft would be useful document.
Channel utilization. This is just some counters measured in nanoseconds how the radio perceives the radio channel in terms of the if the channel is free or it's blocked. A specialized subcategory of blocked radio has been, reading data or writing data to the channel. (Sending or receiving )
This gives us a good estimate, what we can do with the channel especially aesthetically allocated TDMR. Radio channels. Because in this case, there might be time periods where we are not allowed to send and nobody else is sending because the time is just allocated for someone else. This draft would allow the radio to report [this] correctly saying, yeah, this much of the channel is free for your local radio to use. I've seen data. Incoming through the radio, and we could use this to be a little bit more sure how much more data we can send.
The radio quality draft tries to address the problem that on slower radios, especially VHS we cannot do probing. Because there are pro media access slow only get at best a couple of packets per second. And that's not enough to measure the quality on a changing channel especially on moving nodes. The radio quality draft has some values inside, that could give us more data [to] check that, the channel is not disrupted by external devices. Again, I have some coworkers who tried things like automatic jamming detection by measuring the incoming noise level over the area of a MANET.
So what's next? The radio quality draft needs some improvement. I got some internal feedback from a few radio vendors. And first, I have to improve the text to make sure that most of these values depend dependent on the modulation coding scheme, the radio is running on. So every time the bit rate the radio reports changes we shouldn't make the, educated guess that the values are not direct comparable Also, it seems that the bit error rate is a much better, radio generic value, to report and to process. The signal to noise radio, two radio vendors announced the turns to me that the signal to noise ratio is very much waveform or radio dependent. So it's much more difficult to interpret the semantics is not completely clear I think it could still be useful for certain elements, but at the but the bit error rate should definitely become a mandatory Value.
Henning: Some more work I had some drafts plan for the radio reporting, MAC layer statistics to the router. I'm not 100% sure how useful They would be. I had them in a old private implementation, but much of this, data can be measured by the router itself by monitoring the local interface. I have some drafts planned, that allow the radio to report a little bit more about capabilities. Things like I can transmit or I can receive multicast. Or not. There are things like LTE clients. Often you can send a multicast to the base station But unless you have, quite flexible base station. The base station cannot send multicast to the clients. If you know this, you can automatically configure a routing protocol to work around these problems or in some cases report an error. Then there's IP support. I have seen layer 2 radios that cannot do IP version 6. It would be nice if the radio had a good way to provide us with this information that we are allowed or not allowed in most cases if we want to report this to transmit certain IP data. Are we allowed to use VLANs or other protocols except for IP? This would be useful information. And last thing, service discovery. A lot of especially military, radios have additional services like voice interfaces. Or maybe there are some HTTP port on the radio for configuration issues. If the radio could report to us that certain local sockets in addition to the DLEP, can be used then we can configure the firewall and the routing on the local router to make this available. In some configuration interfaces or maybe automatically connect to some voice interface of the radio.
This is for future work. I would first like to concentrate on the three related drafts.
Any questions?
Ronald. Yes. First, a bit with, Chair hat off we ran, Working Group adoption call in September I think it ended, the 22nd September officially. I was going to comment myself then I was chair hat off. I will still do that. There were some expressions of support Most notably, there was, most notable was, expression of support from a radio vendor I think that was that was very good. Response was not overwhelming, but, is it ever? In MANET the last few years. I'm inclined. To call, these, drafts, adopted there is some work. I'm going to comment on some aspects of this that's mostly with chair hat off. But I see value the value in the radio quality drafts for the reason that, having just mentioned, in a radio waveform, so it fits very little bandwidth then you will want to use the locally available information, to the maximum extent to, to say something about the quality of the links that sets I think that's general utilization, the draft now says at least and, it defines a number of data items and it says that in which messages these data items are used. The other two drafts to the best of my knowledge do not do this that would be one comment, but I've also sent it to the mailing list. And for the radio quality draft, I wonder whether we need three separate extension points for the extension values, instead of one? So if you want to use bit error rate and the noise ratio, and what was the third one? I forgot already. Then should these be 3 different extensions. And instead of one so that, vendors can indicate which exactly what they support and what they don't support.
Don: Okay. I think, we should take that to the list, Ronald. now we're on the charter don't go away.
Charter Discussion your, slides on the charter discussion from the interim meeting. Think what we should do is rather than go through these in complete detail is just talk about we had an interim meeting where we had we presented these slides then we took to the mailing list, for feedback and we got very sparse feedback. And that's not a good sign if we're going to take on new things. We were given direction that unless there's strong support and support isn't just raising your hand, but it's raising your hand and bringing new work to the working group that we're not going to add it to the charter.
Is there anything, Ronald, you [would] like to point out in these slides that we should take into account for the, the group, because everybody, I think, has had a chance to look at this and go over the material. We haven't had a lot of things. I like to open it up for discussion of points that we missed or.
Ronald: Yeah. Again, I've been out of action for a month, so to speak, So a lot of things did not happen. I would have commented as an individual as a participant that's, I'm really interested in some of the things that, Christopher Dearlove, posted, on the mailing list. How we could use the existing OSLR V2 specification to already reduce the amount of overhead that all of us are [seeing], that OLSR produces. And then the potential for enhancing OLSRv2 with, some, reactive mechanisms I'm probably misrepresenting or not presenting fully what was in these emails. But, these are two aspects that I as an individual would like to work on, so much so that, even if the MANET, working group goes on goes under, I would still try to find a way to work on that. We would have we had hoped for at least a little more attendance at the interim, and, a more bit more response to the discussion that was initiated on the mailing list after that. But it is what it is so Multicast is still on a on my list of favorites I have some ideas, but I have a feeling that, I first need to try some things out to find out if this this ID holds other before I can bring it to the IETF. So that's not some it's not something I immediately can write at the bat.
Abdussalam. Yes. Regarding the charter, I agree, I missed the last meeting, interim. We mostly agreed with the charter, but some, some points maybe not added from the discussions [on the list] but maybe, it needs, another round. I asked, and I think also I asked the chairs if they can write, like, a proposal for the charter, which not without the points here. But, maybe I missed that. I'm not sure if there was emails sent the discussion just for a proposal. And I remember that, we got also a email regarding adopting, one draft for Henning, which he presented today, but still, we didn't get any, confirmation of adoption. Thank you.
Don. That wasn't clear on the list. I mean, I went through the material, but it was it was weak response. I mean, we certainly can, hash out the charter. They're in the agenda there is a draft, of the charter update from the previous meeting that, Ronald had put in there. And I put a link to it in the agenda, I can share that. But you know, there there's some text to work from for that. And it's not heavily marked up, as you can see,
I think it's something that, you know, we can we can basically take on the list and hash that out and make sure that we're not missing anything that was in the discussions.
Juliusz I'm thrilled to hear that that Ronald interest in multicast And, but I would like to have a little bit more information about how much how much interest there would be in a multicast protocol that is robust enough to survive the MANET environment. And I have no idea how to do that. So that's an appeal to the chairs. If you can find a way to find out whether people are interested in that or whether it is as Ronald and me nobody else I'd be interested in them in that with the take right now.
Donald: I will start a poll for multicast interest.
Henning: . I have been, interested in multicast for quite a number of years, but must admit I came to a conclusion that I don't want to do multicast routing anymore. Because it seems every one of my different use cases need a different forwarding and processing semantics. So I have things to consider like, some group voice channel. Distribution of live information like GPS positions, or maybe distribution of data you want to share with your neighbors in a seemingly reliable way. And for none of them IP multicast is a good approximation So coupled with the problem that we don't have a multicar forwarding plane in the Linux corner it will be quite difficult to get something good with multicast.
Don: We shouldn't be limited by the Linux kernel as level set, and I don't think that should be.
Henning:I What do you propose if we don't use it? If Linux cannot do what we are proposing How do we want to test it?
Don Well, Linux can do multicast. It may not do it efficiently, but it can do multicast.
Henning:Yes, but not for MANET.
Donald: Okay. I can attempt to start a poll here. So basically say, yes, if you're interested in working on multicast and no, if you're not, We'll see what the results are.
Don: Even, a draft, an informational draft of, you know, the pros and cons of multicast, Henning ,would be useful, I think, to this group. You've thought about it.
Juliusz. I think there's a very good point that Henning has made I would like to stress is that the multicast technology is going to depend on the use cases. Whether we were using it for discovery, whether you we were using it for efficient data dissemination, And so in addition to that, if people are interested, we need to understand why people are interested.
Donald : So we've I don't know if we need to wait further for this result to secure to be five people in the current audience who are interested in nobody specifically objects ? Okay. Well, it's a one though. There is 5 for Multicast to 1 not for Multicast the rest abstain.
David Lamparter: [Mulitcast] was not part of but Linux absolutely does also have a multicast forwarding plane. However, classical multicast forwarding is probably, impossible with MANET. Rather than [that] I have discussed this before, that it's possible to apply BIER to a MANET, I think. So the solution space is not empty, I believe. And I'm interested in implementing whatever someone might need. However, I don't have a use case myself. I'm not sure how I would have voted on the previous draft. Yes it's a solvable problem, but if no one if there's no consistent demand for this, then Well, Nah. Okay.
Jim. On the charter discussion, I think, know, one of the things as the AD, I was frankly disappointed on was a very small amount of response to it on the mailing list. So in order for me to even consider the recharter. I need to see people get engaged on that mailing list and you know, responding to what's being requested by the chairs in terms of what should we work on, and they've listed a whole bunch of things. And whether you actually personally will be able to do so. I'm going to let this go for a while. I think between now and Brisbane, think we need to have that conversation on the mailing list. I don't think we can make any decisions right now. I encourage everybody to please Get on the mailing list. Respond to the chairs, let's have that conversation And then, hopefully, we can get to a point where you know, there is actually work to be done that we can show in that charter.
Jim: Obviously, and Ronald, you know, there are those 4 documents, and I understand the reasons why those haven't been progressed. You were we already talked about that. But, again, we need to see what we already have, get in progressed. Rather than stagnant. So I guess that's really what I what I say. So in in summary, let's have the conversation again, we can restart the conversation on the mailing list, but if there's no response like this time, then, you know, we need to seriously think about you know, what it what is it that we're here to actually do? So I'm trying to put it as nice nicely as possible, but please get involved get on the mailing list. Let's have the conversation.
Ronald: Yeah. Okay.
Houda Chihi Hello, everyone. My name is Houda I’m from Tunisia. I’m working with [radio networks] and I am very interested [these] activities. I want to know if you have proposed propose Hennig Presentation: ed any solution.
HoudaThe question is if you have you considered or proposed any solution to overcome the problem of mobility.
DonaldI : Yes Well, I mean, You want take that, I mean, there have been, mobile ad hoc network protocol standardized. So those are solutions for some part of the problem space. Of mobility. And you had solutions? but we're considering whether working on alternative solutions that might be better in a certain contexts or improvements in the ones and then have already been standardized.
Donald:If you can ask more specifically, especially on the mailing list, you can probably get a more in lengthy and detailed response.
Houda Okay. Thank you. .
Juliusz. So, I haven't been responding in the mailing list because the chairs have been doing such a good job summarizing the things, and I thought it was pointless to add a me too. And so in order to stimulate activity on the mailing I would like to suggest that the chair say something stupid once in a while So then we'll see what errors we can make to encourage corrections.
Zeqi Lai: I am from Tsinghua University. And I'm a newcomer to this working group [looking for solutions to] problems for the emerging low the upcoming LEO satellite etcetera, network. I [think] the network may have some [similarity] with the MANETs because due to the mobility, high mobility, and unstable and connected. Our group has research on the routing for the satellite network. And if possible, we can contribute our new ideas and works to this group. Possible. If our work fits the charter of this working group.
Don:Thank you. So the question was on satellite networks. Do we have, somebody [IETF Group] that covers, Leo and those types of satellite networks.
Jim There's some work going on, but I need to look at the MANET charter or other. And, again, a mailing list discussion.
Donald: Right... Jim was just suggesting if can come across the microphone and a mailing list discussion on this topic, which I think is excellent. I think when I looked at the charter, the MANET charter look pretty general to me.
Yeah. So you know, I thank you for the suggestions and also posting a message on the mailing list will be helpful.
Donald We have a couple minutes left. Any other comments?
One more comment.
Jim: Ronald, a comment for you on the IPR thing that we talked about earlier I did a little bit little bit of check-in in my spare time just now and, I think, in the Shepard write up, you'll see that there's, some blurb on IPR. And I think as long as you can put in there a justification as to, you know, reasonable efforts have been made to contact the author that have all failed then I think we're covered from an IPR perspective. There isn't a formal process. And that's actually been checked by IGF Legal several times, and there are reasons why there isn't formal process. But if you can put in the shepherd right up, you know, just a blurb about that all you know, all reasonable efforts have been made over a period of time, you've had no response that should be enough for me to approve that when it goes through all 48 hour.
Ronald Thanks, Jim. I will do that. There is some wording already there. Yep. Trying to make the point that 3 of the drafts, We did have an IPR declaration from David Wiggins but not from Baumann. But they're from the same organization and I did leak and lifts. So Yeah. But I'll expand Yeah.
Jim: And I did notice on website there isn't actually any IPR filed. for any of those documents. So if and I didn't know I also noticed that one of the authors I think you just said that works for the same organization. Right? So if you've had an IPR declaration come back from that particular person then I think we're definitely okay.
Roanld Yes. Except for the 4 drafts where, there's only one author of that organization.
Jim Sure. But, The other thing you could try are you are you actually in contact with that other person, or can you contact that other person? Because it could be that you could mention to them about the other 3 documents, and you might be able to get answer from them, which you know, from a company perspective,
Ronald: No. They both seem to be reachable, at this point in time.
Jim Okay. Alright. Just put it in the shepard write up for get it through to me, and I'll deal with it from there,
Ronald: We'll do. Thank you, Jim.
Jim Yes. Thanks a lot. Alright. So we'll look forward to more discussion on the mailing list.
Ronald See you in Brisbane if you're able to travel. Would be nice. Okay. We'll see. Thanks to all participants, and thanks to the presenters.