Manet Minutes IETF 119 Brisbane Austrailia March 19 2024 17:30 AEST
Introduction Donald Eastlake, Don Fedyk and Ronald In ‘t Velt the co-chairs,
- Note well.
- Fairness Policy.
- Meeting Logistics.
- David Wiggins Memoriam.

Ronald In ‘t Velt:
David Wiggins, was always a participant, mostly, a participant coming to IETF Meetings far as I can remember, but somebody who was a co-author of the draft that we will shortly speak about. Also, David, who was an implementer of DLEP in an open-source implementation done by, MIT, Lincoln Labs, has passed away, in November. Last year. After a long period of illness. We were sad to hear this. I can imagine that his co-authors are affected by this. We join them in mourning the loss of David and he shall be missed. Then, about those drafts he co-authored after a long, long period (I won't go in all the reasons for that) are finally at the stage that we are about to hand them over to our area director and the wider IESG.

We have some individual drafts that have been adoption called twice. There were not many opinions for adoption but there was no opinion against adopting them. I think they can be useful. We received guidance from our AD that we should not take on any new work before the previous set of documents were out of the working group. We are at that stage now so, maybe, Jim, you can make a comment on that but, do I correctly understand that as soon as we have handed over the previous drafts that we can, consider these adopted as working group documents?

Jim Guichard: I haven't read the documents, yet, but they're DLEP related. So as far as I'm concerned, I wouldn't consider this as new work. Per se, it's more if it's related to those documents that are going come to me very shortly, then I'm okay for you to go ahead and adopt these and continue the work on that because it's basically the within the same area. My comment, before, was I don't want to see any new work taken on in terms of new charter items. Until such time as we see the movement of what we've already got. And, you know, the reasons behind that. In summary, I'm happy for you to go ahead and adopt these now and continue to work on those and send me the other ones, and then once we're at that stage, then we can, if there's enough stuff for a recharter with the working group, then we can certainly do that. I just didn't want to do a recharter until I saw progress on what we already had.

Ronald: Understandable. But these three documents are fully covered by the current charter because they’re DLEP extensions, and that's a charter item.

Abduslam:I have read the documents, the 3 documents, And I have, commented on them, before and, I asked accepted, the adoption for some time, but I would like to know if there's somebody against this doc. They should have commented, but there was not any against, these documents.

Jim: Adoption as working group documents is the beginning of something, not the end of something. There's really no issue with adopting the document. They will have to go through the whole process and go through work group last call and so forth. So hopefully that work that you're talking about in terms of fleshing out detail will happen, obviously, as part of that process. So I don't see reason to delay.

Donald Eastlake: And then finally, on, on document status, we now have a new version of the, AODV, Version 2. Draft, that Charlie Perkins is going to present shortly.

Jim: I've seen that there is a new version of the drafts, STURP that was presented in San Francisco, However, I think, was it you Donald that send out, a request for presentations on the mailing list?

Donald: Yes, and we did not receive, a reaction from the authors of that draft. So, whether they feel that they need to do another update or whatever, they didn't seem to want to speak.

Abdulsalam: Regarding, this drafts I've read the draft, but, it needs more update and adjustment. There were comments from Henning, and comments that needs to be answered. There's already open for, to update, the concerns of the working group, comments from Henning and Others on the 0 version of the draft. However, I have not seen any comments on this version 1. That was published somewhere in January, if I remember correctly.

Charlie Perkins: I'm here to talk about AODV [Ad hoc On-Demand Distance Vector] routing.

Charlie: I'm going to talk a little bit about how AODV v2 got to be what it is. And then explain why it's not the same as AODV, the published, experimental routing protocol. And this, talk about the things that have most recently changed. And a few issues to be resolved.

AODV version 2 has been around a pretty good while. What happened was, we had 4 routing protocols, 2 reactive protocols and 2 proactive protocols. And I think they all got published as experimental documents. And then the idea was to combine the 2 reactive ones and combine the 2 proactive ones and then, go forward. That's sort of what happened except in the case of the 2 Proactive protocols, I think, the other one that was not OLSR [Optimized Link State Routing] basically just disappeared. And the DSR folks and AODV folks worked together, and AODV had name recognition, but it was somehow felt that since there were 2 different protocols being combined, we should pick a new name, and so, Ian Chakers renamed the effort to be "Dymo". I guess it stands for dynamic mobility. The DSR parts Dave Johnson did not continue participation very much. And for some of the dynamic source routing stuff one thing that we found out was that if you put in source routes in the packets, the additional size of the messaging can have a very deleterious effect on the performance. There wasn't anybody championing this part, although it could be put back in. After a while, people were wondering, well, why is it called Dymo? Why don't we just call it AODV version 2. And, then, for reasons that I can't clearly remember, there was sort of an acrimonious meeting and ADOV version 2 was removed from the MANET charter. It sort of continued to be a live document and, the co-authors agreed to have it be AD sponsored and Alvaro was sponsoring it for a while. I was essentially laid off and COVID happened, and nobody was working on it. But in the meantime, there was this other document or other protocol called AODV RPL that was getting developed, and it's now done, basically, I think it's in for publication. It's been requested to be published. That was an interesting exercise, and educational in some ways. And then well, just recently, I was contacted to see if, there was interest in, it came up on the mailing list, about resuming some work on a AODV version 2, then I got the document and went through the normal amount of pain for something that's been sitting dormant for a couple of years, finally I had some interesting, discussions about things that broke some of the IETF tools, Here we are with, version 4 of AODV version 2.

To understand AODV version 2, compare it to, AODV RFC 3561 that was published as an experimental protocol. It’s similar but not completely similar, I would say the way that route discovery proceeds is basically the same. There was a way in AODV for having intermediate routers if they had a route to the destination, they could supply that and send a route reply. It was felt that that was a little more complicated and to expedite the document, could be added later so that was taken out. And there was another feature called Expanding Rings route discovery where you if wanted it to not flood the whole network, and you thought the destination was nearby, you could just, make a small radius of dissemination of the route request message. That has some value in certain situations. But that was another feature that it was decided to take out. Probably one of the biggest changes to AODV was to make it conform to RFC 5444 which, defines some type, length, value extensions to a basic message header with the message type. I didn't go back and review this, but really, it's a pretty straightforward, and just a matter of conforming to the message formats that are laid out in RFC 5444.

And then there's another document that, defines the port numbers and multicast address and IP protocol number for MANET routing protocols, and so we adopted that, and we put that in, to be conformant. I'd like to just say something about this, which is that since all the protocols are using the same port number, you have to be careful about that, but this was part of the effort that essentially, I requested, more than 10 years ago now, allowing some sort of combination between proactive and reactive protocol operation which I think is still a really good idea. But it would need work, to put it mildly. Anyway, so that's a possibility. Then there's, a draft that came along after the initial work was done on AODV version 2. There was additional emphasis on security and then RFC 7182 was published to provide some type length value extensions to allow you to put in the integrity check vector [and] a time stamp, And I think there's some other features too, but I don't remember. Anyway, since that was designed, and since we wanted to have some end-to-end security, that was a change to the AODV version 2. Then there were various suggestions on how to improve a lot of the necessary features of the protocol and we just followed the suggestions but one of the more important things that was done was to allow alternative metrics, but not currently being used, that were not hop count. Everybody knows that hop count is a lousy metric. And, there's a lot of things to say about that. For instance, if you're running a simulation and you're using hop count, you can really get some wrong answer and errors. There's not a problem to use alternate metrics for an AODV version 2, but this is something that needs work in the other direction, which is to make a list of the metrics and allow the metric type to be put in. And I have to make sure that's correct. One thing that did was to make a lot of definitions about multiple interfaces and some of that work was adopted into AODV. And also, using compatible nomenclature for the data tables and so on. That allow you to Keep a clean separation between the data and the necessary for managing the multiple interfaces. It is now possible to have one IP address assigned to multiple interfaces, and that took a bit of work. And, as I mentioned, the end-to-end integrity checks were enabled. For an ad hoc network, at least the way we were imagining it, it’s possible to imagine that the network would have multiple points of connection to a larger local area network or internet itself. To do that, we had to be really careful about the meaning of the sequence numbers. I didn't mention it, but, AODV uses, the destination sequence number algorithms that were put into the DSDV 30 years ago. That destination sequence number allows for a pretty solid way to avoid routing loops. All that does is filter down, but when you get down to multi-homing, you have to be sure that you're counting the sequence numbers from the same space. It's possible that with different, connections to internet that you have to be careful about it. Basically, it matters which of the connecting routers are providing the sequence number. We took out hello messages and another sort of valuable feature called local repair.

All these things that were taken out: hello messages, local repair or, expanding ring search etc. The idea would be that after the base document was published, these could be put in as supplementary documents that added features. For example, metrics. However, it was thought they were the really hard part of the base protocol. It was not viewed to be appropriate for an extension document. Another change was to have a network where there's a lot of messaging you have to try to be a little bit more careful about which messages actually make it through. So, for instance, if you have a choice of forwarding somebody's route request, and you don't know if that ever is going to establish a route. Versus forwarding a route reply to acknowledgement back to the route reply. And that's also useful for avoiding loops. To blacklist, certain neighbors where it's only one way connectivity. The important thing is to try to allow routes to be established and maintained in preference to just flooding random route requests. That actually does help. And I didn't say it, but I guess it's well known that flooding in an ad hoc network is very costly. And so anytime, you can avoid doing that. That's a good idea. Which was really the motivation for this expanding ring search idea. A lot of these things were built order to reduce the amount of, flooding and signaling going on in the network.

So, after the long time we already working on AODV version 2. There we're starting to be more people interested in rigorous proofs of correctness, and avoiding routing loops, and so on. Now, it turns out that one thing we didn't think about very much is what happens when some of the nodes reboot, and then they lose their sequence numbers? That is a way to destroy the correctness proof for using the sequence numbers for avoiding routing loops. And it's easy to show that if you have a device that reboots and picks up some random sequence number, then, you're going to very likely have routing loops or at least you can't, guarantee that they won’t happen. That's not a complete list, but it's a good list, and I think it, shows as far as the evolution of what happened. I put recent in quotes because, you know, nothing’s very recent since nothing happens since about 2019, I think. But, anyway, I mentioned already handling rebooting routers and basically the way of doing it was just to be careful and have some sort of parameter, essentially time out for routers after they reboot, they can do certain things like forward route requests, but they can't do anything that requires their neighbors to trust their sequence number. They have to wait longer before doing that.

So that was an important change. There were some additional, courtesy discussions and it was requested for a time that we said that protocols should do things we were asked to explain these details, and what goes wrong if you don't do them? And, so we did a lot of that, and, as time goes on, and I'm sure by now there's new crypto algorithms that, need to be, maybe even specified as a default. If you if you look at just the amount of text, the changes in AODV version 2, I'm quite sure that just terminology changes would be the number one thing because, as I mentioned, we tried to be conformant with, what was done with the OLSRv2. Since we put in metrics, we needed to have a new ICMP destination unreachable code that basically says that destination is not reachable. We did that IANA noted that our requested code [value] was already being used by somebody else. We just have to update that. Then there's this thing called "precursor list" that was put in. I liked it. Then it was taken out And, well that's the breaks. Then it was put back in.

What precursors are is essentially the upstream routers that allow you to use a route. In other words, you might not care about all the routes to all your neighbors, for a particular route transmission. If you have an error, you'd only want to notify particular neighbors that the route is broken, instead of having to broadcast the route errors. That turns out to have some beneficial performance effects. Then, about one of the things about bidirectionality, we allowed a MAC layer too, a lot of MAC layers enforced by directionality. And so, we allowed that too. So, this came up on the mailing list, and I would say there was, a lot of discussion and questions about whether AODV version 2 is implementable.

I don't have an existence proof to show you that it can be implemented. All I have is my own experience and the experience of people I worked with, that leads me to strongly believe that it's implementable. I am familiar with a lot of implementation issues but, you know, since I don't have it. I can't prove it. After publishing Revision 4, I got email back from IANA asking about the registries for metric type and the address type so that I'll just have to figure out what to say about that.

And then, as I mentioned, we needed to I have an updated, code for the destination unreachable. Chris Dearlove, pointed out that this has been published as RFC 7859, so Congratulations on that. One thing about AODV RPL was that it allowed for asymmetric routing. And this is a nontrivial change to the protocol. But it's very cool. If there is interest in the working group to have asymmetric routing, then, we know how to do it. And it could be done. Probably it would take a couple of months to do it, but I'm happy to try it.

Over the years and particularly, I would say Thank you to, Alvaro Retana. He did some great reviews on the document and made a lot of observations that, we were happy to adopt. But I need to go back and make sure that all the comments really have been addressed. I am about 75% confident, but in this case, a 100% is needed. And I guess if this document, is adopted by MANET Working Group. There'll be a lot of review and it's, it's not a short document. It helps to be familiar with RFC 5444 and, RFC 7182 and possibly even stuff I don't even know about since I've been not active on the working group for a while.

You know, I don't know if this how to say it the right way. But You know, I'm willing to I think AODV is a terrific protocol and, as well, just a slight digression. I didn't make a slide about it, but it depends upon the degree of connectivity of your profile of a network. If you have a network that's only a few sources and destinations. Say you had 1000 nodes and for any source, it only ever needed to talk to 5 other ones. or 6 other ones, except for maybe a few server nodes that that had a lot of clients. Well, that's a relatively sparse connectivity graph, if you have another kind of network but we're practically all the sources need to talk to practically all the destinations. Then that's dense. If you try to maintain all the routes in such a network in a reactive fashion. You run into trouble quickly, and it turns into not being scalable. The point is that there are networks that have this feature of being relatively sparse in connectivity graph. And for those who react, your protocol is a good thing. And so, and that's why I think that AODV version 2 would have a place as a published, protocol. That's my end of that digression.

Well, at this time, it is 1:12 in the morning [for me]. I'll be happy to field some questions, but I'd also be very happy for questions that require a bit of thought and, maybe, even looking up things, to have those questions put on the mailing list and have a better discussion there.
Questions ?

Ronald: Thanks, for your presentation, Charlie. We can, allow, I think, a few short questions, but longer discussions need to go to the to the mailing list.

Charlie: I have a question for you, Ronald. You are there for the whole shebang. The whole MANET research [argument] and, the document or reorganization back in the early days. Did I present to the group a reasonable summary of what happened?

Ronald: I have to confess that maybe 10 years ago, I was not always playing as much attention as I should have. So many things happened. And there were so many discussions at the time that I think they cannot be captured in a single, 15 minute presentation. I think you've got the gist of it, pretty much.

Charlie: Okay. Well, you know, it's hard to be objective about all these things, really. And especially when you have a lot of, personal effort at stake, l just wanted to get your opinion. That's all.

Ronald: And I will refresh [on] version for myself and go back to some of the old mailing list discussions and see, if they still apply or not.

Charlie: Well, any comments you have will be greatly appreciated.

Abduslam: Regarding this, I thank Charlie for his presentation. And, I was always following the meetings and maybe now for these 10 years, but I was disappointed for the removal of his draft. He said that's a removal. It doesn't remember how it happened. But I will ask that it is that this removal of one important document, which is for the working group. It may even close-up the working group. So, I ask this on the mailing list. Why was it removed? Or how even I remember that one of the co-authors He's from England, okay, or from UK. He was disappointed and he I had seen his email and, on the list, or maybe he sent it to me. So, this is important that when it's removed, we should know how things remove and come back. If I if my let's say in the future, I sent to IETF, and it's accepted and adopt.

What's the mechanism? It's removed or not removed. This should be discussed maybe. I was interested to discussed with the chair of IETF, but I didn't want to do it until I see one presentation, or the author say something about this, but anyway, is my comment usually. My comment is, I support this document to be added in the charter. And I hope, it will because even the way it was removed, I don't think it was right. Thank you.

Ronald: All I will say about this, for now it was the decision of the then chair Justin Dean, to say this cannot be standards tracked in its current form, it could have continued as experimental, but I think, at that stage, the authors gave up or a bit later, maybe. The other chair at the time. Stan Ratcliff, had his name on the document as an author although he may not have contributed to it very much. So, he recused himself from, making that decision, but Justin Dean, decided that there were too many unresolved issues, at the time. So, we must go back. But, Christopher, do you Want to add something, or I have a question?

[Chris’s audio was breaking up]

Charlie: Don't want to put anybody on the spot, but I see, Rick Taylor might have an idea about it.

Ronald: But I was going to give the floor to Christopher for a question. But we cannot hear his audio. Okay. In the chat. Okay. Yep. So, Rick, do you care to comment or Ronald.
Rick. Go ahead, please. Sorry about Hi, guys. Sorry. I was trying to unmute my mic. You're very faint. Like, audio volume is very low I'll put it in chat.

Priyanka: Hi. I'm Priyanka. Am I audible? Yes. My question was that AODV v2 is, still a protocol. Do we think in the MANET working group, you're going to incorporate, let's say, the new AI ML Optimization technique into this kind of protocols.

Charlie: I hear your voice, but I didn't hear what the optimization technique was.

Priyanka: I don't have the optimization technique at the moment, but I was just wondering if you are if this MANET working group and Charlie, you were interested in incorporating those newer techniques.

Charlie: I have an easy answer for that. Which is yes. But just to expand on it a little bit, for any optimization technique you know, we have to see how it fits. And, if you have a particular thing and you want to incorporate that into the protocol, will that work? Optimize is my favorite word, and I really like whenever we can end up improving the performance, as long as it, doesn't, burden the average performance. Yes I am and but it, well, if a document is adopted as a working group document, then in a way, those decisions are out of our hands, And, then my job is just to follow whatever the working group says.

Priyanka: Thank you,

Ronald: Since we have only 9 minutes Okay, Rick, read your comment in the chat. Rick is saying: I have no real comment on the history. However, I do see AODV 2 as a useful concept. I have concerns whether it is standard track yet, but a protocol type I would like to be worked on. I see crossover into VPN routing use cases as well. Yeah. Perhaps.

Ronald: I would like to leave it at that and take further discussion on this to the mailing list because we've only 8 minutes left and still have an agenda item to go.

Charlie: Well, thank you very much for giving me time and Next time I hope is not after midnight. So, I'll hopefully see you guys in the future.

Ronald: Well, the next idea is in Vancouver, so that should be closer to your time zone.

Charlie: But thanks for getting me. We're staying up for this. Yeah. You're welcome.

Ronald: We are almost done, DLEP as discussed before, with the, base the flow control, drafts, statistics for traffic classification-based statistics were never undertaken, although we did do the traffic classification itself as part of the flow control scheme, multicast was never really done. Some ideas were discussed at IETF 114 Dean, I think it was in Philadelphia. In a combined session with the role and the BABEL, working group the point has been made specifically by Rick Taylor that, there are proprietary multicast solutions below the IP layer out there. But I would counter that with the argument that may want to federate several of these, proprietary solutions they you need some, some sort of overlay. I think it's still I would personally still be interested. That I cannot do it on my own. So, if there's nobody else, it’s probably not going to happen. The Challenges in best practices. For deploying and managing, we don't expect anybody to come forward and tell all their secrets on how they do it. Then there's a sort of an implicit work item not singled out as a, as a work item, but mentioned, nonetheless. Maintenance of all OLSRv2 drafts and maintenance and extensions.

So that should be carried over into a new charter. Donald improved the wording. Thank you
I incorporated a few Suggestions, ideas, from Christopher Dearlove for the DLEP in a recent email. We could do an informational document saying how we could use OLSRv2 to with some lesser-known features, all those OVSRv2 in its current form, to accommodate specific use cases. Christopher mentioned responsive networks, stabilizing networks. I don't think we can go into that now, but it would be something to elaborate on, you know, on the mailing list. Hybrid proactive reactive operation, by extending, all those OLSRv2. How much of an overlap that would give it to AODV V2 I cannot foresee now. Hybrid proactive DTN operation, would be interesting. Better NPR selection or statistics. I don't know to what extent that is a local thing or if there's any, protocol action, involved there. Another point, this is based on, experiences, guidance on all those OLSRv2 to restart. Where one of the nodes restarts and then cannot enter the network anymore. Problem that there's been experience.

Don: So, just a note, there’s been some comments on the list.

Ronald: We're going to run out of time so Yeah. I cannot see, chat or, At the moment, how are we doing for time? 2 minutes.

These are potential new work items. DLEP maintenance and, and extensions, obvious, label maintenance and extensions, obvious, babel, for UltraP 802 11 presented by Donald's at the previous, session. Is for discussion. Put in first thing, energy efficient routing in, MANETs it is probably, distributed work. New approaches to multicast, forget bit string based. I've been thinking about that, I thought I had a brilliant idea, until 2 days later. I found that it was, fatally flawed. Federation. I've already mentioned skip over the management stuff reactive routing protocol just presented by Charlie. I think we should at least look into this, and specifically look at the Issues, slide of Charlie's presentation and see if we see, a good, probability of resolving those issues.

Hybrid. Already mentioned for OLSRv2. An update of RFP 2501 personally, with no chair hat on, I don't see what we would gain from it.

And then the other topics. So that’s the end of this list and the end of the presentation. The one point that I still want to make is If we choose to adopt something, then there should be people volunteering to do the work.

Abduslam: What’s so important for me to know is the time slot. What's the milestone? The timing for when we will reach charters, as we heard from the AD. He doesn't want any item, new item coming. Tell Richard, now we need a plan. At least we know in 1 month, 2 months, we were rich because we have discussed this many times. I don't think we should go forward only after we recharter it. So, when will the chairs think that it's more suitable for them or for us all. So, please, this is very important for us.

Ronald: That all depends on the amount of discussion on the mailing list and, whether we can come to a good set of items for a new charter, I would think.

Don: In my experience, it's the drafts come first. The people that support the drafts, and then the charter is built around supporting that. We don't go out and define a [speculative] charter. We need work participats and that will drive the charter. So, there's plenty of options to move the charter forward.

Charlie: Oh, well, I just wanted to say that I can work on the draft, and I think it's, actually nearly done unless new features are edited.

Ronald Okay. I'm, reading som, comments from Christopher on the chat. Point taken about the IPR, Christopher. Okay. We're probably over time.

Ronald: Reading the comment by Andrew Cooks Yes. There is some interest from some radio vendors. For instance, one radio vendor supported the adoption of the new physical layer oriented DLEP drafts, I should say. I know of at least one other, Radio vender that has a DLEP implementation. Although it's a pre-standard, thing, It's not compatible with RFC 8175. As far as I know.

This was the MANET session this meeting. I think we will have another session in the next IETF. In the meantime, do get active on the mailing list and, comment on, the ideas thrown out here. And then, Hope to see you in, Vancouver. Either in person or remotely. Thank you for your participation.