Mobile Ad hoc Networks (MANET) Minutes Meeting : IETF 88 Thursday November 7, 2013 Time : 1300-1500 Afternoon Session I Location : Plaza A Chairs : Joseph Macker Stan Ratliff Secretary : Ulrich Herberg Jabber : xmpp:manet@jabber.ietf.org http://www.ietf.org/jabber/logs/manet/2013-11-07.html Scribe : John Dowdell Audio : http://www.ietf.org/audio/ietf88/ietf88-plazaa-20131107-1300-pm3.mp3 URLs : http://www.ietf.org/html.charters/manet-charter.html http://tools.ietf.org/wg/manet/ ========================================================= Minutes takers: Ulrich Herberg, Ronald in 't Velt, Charles Perkins o Administrivia o Bash the Agenda [5] Joseph Macker: Any problems/questions with the agenda? [none] o WG Status/Overview: Macker/Ratliff [5] Joseph Macker: Several documents in the RFC editor queue. Most of them related to OLSRv2/OLSRv2-metrics. A few DISCUSSes by Sec ADs. Thomas Clausen: Two DISCUSSes. I will talk about that in detail during the later presentation Joseph Macker: Some items in the IESG. Need revised IDs of the MIBs that are in IESG processing. Bob is not here today. Three active documents, thereof two in WGLC with 3 weeks WGLC. Please comment on these documents during WGLC until 11/22. Two expired documents, REPORT-MIB (for management, way to optimize reports of statists etc.), is a bit on the backburner, less important than the other documents. Possibly also more general than MANET document. Thomas Clausen: I had a chat with Bob (the main author of the REPORT-MIB). He wants to progress with the document, but has time and cycles issues, SMF MIB has higher priority. He has some interaction with some other WG activities, so he needs some more time to see how that pans out. It's not because Bob has lost interest, it's just that there are other priorities and some relationship with work elsewhere. o draft-ietf-manet-dlep Status: Ratliff + DLEP design team WG progress: DT member [34] Stan Ratliff: Draft has expired. Somewhat intentional. In Berlin we created the Design Team and had good discussion, but then the discussion did not produce a lot. Delta from -04 to -05 revision was not sufficient. We had a really good 2.5h discussion this Tuesday with the Design Team. Rick Taylor: (for the design team). We got a lot of work done, but then we did not set further milestones. There were some accusations that the process is not transparent, but this is not true, the mailing list archives are open. Joseph Macker: It should be called Design Team, not Research Group (although mailing list is called "Research Group"). Thomas Clausen: Mailing list description says "Router Group". Rick Taylor: We will fix that. Rick Taylor: Membership of the list is closed to make some progress. Group formed at IETF87. Very ad hoc meeting in Berlin. Although we are a closed group, please request to become member. We produced five informal papers for metrics. We met again Tuesday this week. We want to set up some more manageable goals. We covered the "core metrics", minimal and mandatory to implement. Some discussions about optional metrics. We use TCP as transport medium. Agreed on work items and timescales. Agreed to push back advanced topics. Rick shows list of core metric sets: max. data rate, current data rate, relative link quality, latency. Henning Rogge is knowledgable and will make recommendations for metrics. Other metrics are optional. Per-session metrics advertised at session creation. Joseph Macker: Do you want to mention anything about terminology? Rick Taylor: no, not at the moment Rick Taylor: Requiring TCP to be used. Secondary protocols are permitted (instead of TCP). Heartbeat rules altered because we use reliable transport now. DLEP-05 work items and schedule. Will deliver DLEP-05 before IETF89. DLEP-06 before LC. Only things that go into -06 are things thate are absolutely required. Stan Ratliff: One of the things we decided to push back. Satellite modems tend to be complex and intelligent. Have ability to segregate traffic based on traffic classification and manipulate links accordingly. Led to discussion of DLEP-radio reporting metrics by traffic class. This is interesting, but not in the core protocol, rather a separate draft. Rick Taylor: What's next: "re-charter" the design team, format seems to work with deadline for IETF90. Adrian Farrel: When you say two more drafts, do you mean two more revisions or two new drafts? Rick Taylor: Two new revisions. Adrian Farrel: You produced papers in the design team and reference them on the DT mailing list. Plans to publish them as ID or just transitory? Rick Taylor: Transitory, very informal, self referring, not planned to publish as ID. Would distract us from work. Adrian Farrel: Question whether it's worth archiving the thoughts in a more permanent form (historic RFC or just dump as Internet Draft) Rick Taylor: I don't want to commit to that because we have a lot to do now. Joseph Macker: Capturing the thoughts/design rationale based on implementations would be useful. So that when people come back later with same questions, one can point to the document. Thomas Clausen: You presented some core metrics. I have a hard time understanding the relationship between the initial enormous list of metrics and the now much shorter list of metrics. Since the discussion is not open, I am curious how this happened. Second, there was a lot of discussion about session-based, periodic/non-periodic signaling. Now there was a decision made, it would be very helpful to educate the WG of the design decision rationales. Same for TCP/non-TCP. It is important to inform the WG. I am asking officially Joe to make sure this information is sent to the WG. Joseph Macker: I suggest to ask the DT to send a monthly report to the WG. When I sat in on the meeting, I noticed that many of the DT members have consensus on many items that previously were being actively discussed. That was encouraging. I recommend to send out periodic summary status reports and to possibly use periodic telecons to supplement mailing list conversations since the bandwidth there is sometimes useful. Rick Taylor: If you are interested in the DT, you are welcome to join our meetings. Joseph Macker: We make good progress despite initial confusion of milestones. Keep a schedule. Send out monthly status report. John Dowdell: Use the mailing list to look up what has been discussed. Henning Rogge (via Jabber): It might grow into an extension draft for DLEP with "additional standardized metric TLVs". Stan Ratliff: As in 802.11 standard metric? Henning: The session/no-session had been decided even before Berlin I think... I think the WG agreed not to change it from the session apporach in DLEP-04. Stan Ratliff: I am gonna address how we came down to 4 standard metrics. Initial thinking was that there was a lot bigger than we thought there would be. There was a lot of common data items across different radio types. What it boiled down to is what we are currently proposing. Where all this culminates in is DLEP-05. But we do not want to "steamroll" the WG, that new revision will require WG consensus. Ulrich Herberg: You recommended to use more teleconferences, danger of having no public record for discussions. Summary of the decisions would be good. Joseph Macker: Agree. We do need some record of the DT. Thomas Clausen: There have been DTs on various topics with a lot of discussions in weekly teleconfs. When some document came out, arguments have been rejected because they have been discussed in phone calls without record. When there are contentious issues, make them open. Rick Taylor: Request: can we get time until IETF90? Stan Ratliff: How do we proceed with the DT? Adrian Farrel: Continue to set up charter and milestones, inform WG and ask if WG has objections. Thomas Clausen: Please don't wait until IETF90 to give us updates. Could we have DLEP-05 in a couple of weeks, so that we have enough time to prepare? Stan Ratliff: My intent is to bring out DLEP ASAP. Joseph Macker: Include the schedule in the milestones and send out. Adrian Farrel: None of this precludes anybody else interested in DLEP in doing work on DLEP. Joseph Macker: Contact one of us if you want to be more involved. Rick Taylor: The reason we moved to reliable transport was based on implementation experience Joseph Macker: In the status reports, also include implementation reports. o draft-ietf-manet-aodvv2: Perkins [27] Charles Perkins: Intention is two have the two implementations interoperating. Then some issues raised. Implementation status: RIOT (from Freie Universitaet). Plan for code running by x-mas. RIOT has direct access from user space to kernel space. 5444 code running on RIOT. Another implementation, I started using AODV-UU code and change it to AODVv2. Turns out, kernel operations are difficult to implement. Jiazi Yi (Jabber): As different options have always been great concern of AODVv2 draft, I would be interested to know if/how those options will be implemented in the expected coming implementations - and how they work together in interoperability tests. Charles Perkins: Start with base code first, options later. No timeline yet for options. Depends on what people ask for. Rick Taylor: Lots of options for AODVv2 with far-reaching effects. I am worried when you leave out them for implementation. Charles Perkins: Not leaving them out forever, just saying first things first. Joseph Macker: In some scenarios, proactive neighbor discovery could be useful. Are there some considerations to use that? Charles Perkins: AODV-UU provides HELLOs. No plan for using NHDP, but nothing wrong with it. I'd really like to get in some more performant multicast instead of brute force. Joseph Macker: NHDP may be valuable when having multiple interfaces in a more consistent way. Not critical, just keep it in the back of your mind. Charles Perkins: Yes, we should. Thomas Clausen: (reads out text from of draft-ietf-manet-aodvv2, section 8.2) "8.2. Active Next-hop Router Adjacency Monitoring AODVv2 routers SHOULD monitor connectivity to adjacent routers along active routes. This monitoring can be accomplished by one or several mechanisms, including: o Neighborhood discovery [RFC6130] o Route timeout o Lower layer trigger that a link is broken o TCP timeouts o Promiscuous listening o Other monitoring mechanisms or heuristics" This lends up to what Rick said. When you specify this, you need to test this to asure interoperability. Joe: Some of what I said, is already loosely in the document already (e.g., 6130). If there is a mode that is loosely specified.... Thomas Clausen: There are many options in the draft specified for the same thing. You must know the implications of using one over the other, and there are interop problems. Charles Perkins: If there is a problem, raise it as an issue in the bug tracker, in particular if it's an interop problem of AODVv2. Rick Taylor: Given the breadth of these options, do you want to de-scope down to core options and test them with your implementations, and push others back to later draft. How will you find out whether a certain option is useful? Implement it, play with it? Charles Perkins: First want to implement core protocol. Priorities for setting out the optional features can be done by the WG. Idea is to not loose focus. Rick Taylor: Agreed. So why not move optional features to extra draft. Joseph Macker: Just not the multiple interface features, that should be core feature. We need to discuss the core features. Thomas Clausen: You talked about implementation status. What will happen to the document? Charles Perkins: Resolve all open issues. Thomas Clausen: When I read the document, many things are difficult to understand. One example: routing client is like a host. But worse, as one who implemented and designed 5444, this specification does not use the format correctly. e.g., it uses semantics of position of addresses in an address block in the RREQ. Inhibits generic 5444 parsing and generation code. Inhibits proper aggregation and compression of addresses. Enormous amount of things in the document that would do quite well to think about this before implementing. Pare down to those things that are supposed to be in there, clean up. Joseph Macker: Post these issues on the mailing list. Thomas Clausen: Enormous amount of editorial clean ups required, which should be done by the editors. Stan: I get your point. We can't fix that we don't know are wrong. Thomas Clausen: action points 1) use 5444 correctly 2) use standard terms, and avoid defining new and redundant terms Stan Ratliff: Let's take that to the list. Charles Perkins: Other people who know about 5444, say it's used correctly. As far as whether or not it specifically makes your parser fast, if you want to enforce that, you really need to discuss that on the mailing list. Rick Taylor: Thomas does have a point with the position of addresses inside an address blocks. Thomas Clausen: Putting an address inside an 5444 message without associated TLV does not carry any semantics. Makes extensions very difficult. Inhibiting forward compatibility. Henning Rogge (via Jabber): OONF-API does not support using the position of a TLV/Address as information. Charles Perkins: Some issues have not yet showed on the issue tracker. Intent to share code on github and bitbucket. Joseph Macker: Are there going to be two code bases? Charles Perkins: Yes. My implementation is based on AODV-UU, theirs is written from scatch. next steps: interoperable implementations by x-mas. Next draft revision planned within 3 weeks. Equip AODVv2 with suitable multicast optimization. Joseph Macker: One of our NHDP implementations uses CDS output through API. You could get the CDS information for testing. Might save time. Charles Perkins: I would not test this before Christmas, but try to do ASAP. Charles Perkins: Ns-2/Ns-3 simulations are good idea. Whether my code will remain compatible with AODV-UU has to be seen. Thomas Clausen: You mentioned requirements on implementations to have access to the kernel + requirement for persistent storage. There are some conflicting things in the draft. Applicability statement should state conditions under which this protocol is able to function. Maaz Rehan (jabber): NS-2 and 3 simulation is possible until what expected time? Charles Perkins: I won't start until interoperable implementations are done. Joseph Macker: First order would be to test real code (in a VM). Maaz Rehan (jabber): It Needs writing the NS2 and NS3 patch. Charles Perkins: Please help implementing it. o draft-ietf-manet-nhdp-olsrv2-tlv-extension (in WGLC): Clausen [12] draft-ietf-manet-olsrv2-rmpr-optimization (in WGLC) draft-dearlove-manet-olsrv2-multitopology Thomas Clausen: RFC6622-bis is hold up by two DISCUSSes of the Sec ADs Stephen: minimal truncation length Sean: default parameters for security functions Pending resolving of the two DISCUSSes will get us five RFC. Stan Ratliff: Can we on the list get some short status update about the discussions with the Sec ADs? Thomas Clausen: We will do that. Joseph Macker: Tell us what we can do to help. Thomas Clausen: The DISCUSSes can be found on the datatracker (https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/ballot/) draft-ietf-manet-olsrv2-rmpr-optimization is in LC. We hope to get more comments. draft-ietf-manet-nhdp-olsrv2-tlv-extension only editorial changes. Justin said he might have editorial comments, please send them out. draft-dearlove-manet-olsrv2-multitopology: we decided not to submit as WG document. We felt that a couple of things needed to be fixed before sending out. Wanted to wait until nhdp-olsrv2-tlv-extension goes through. Hope to have -02 out shortly. Will then request WG adoption. Joseph Macker: On the extension documents, are there implementations planned? Thomas Clausen: There are implementations (in deployments) of tlv-extension and rmpr-optimization. Not enough operational experience to push OLSRv2-MT forward on std. track, which is why we are aiming for experimental. Henning Rogge (via Jabber): I had a long discussion with Christopher Dearlove about this document and we agreed it needs more work for some multi-topology scenarios (I am talking about draft-dearlove-manet-olsrv2-multitopology-01) Thomas Clausen: Yes, we have discussed that. This document allows for using a (e.g.) delay metric and another metric in the network at the same time. Henning would like to see a scenario where one topology uses a delay metric, and *another* topology also uses a delay metric, but thee topology should be distinct from the first one. We have not yet decided where to draw the line, which is one of the reasons this document should only be experimental. o draft-yi-manet-reactive-jitter: Yi [14] We experimented with Jitter for reactive protocols. Jitter may lead to suboptimal paths when uniform distribution between [0, MAX_JITTER] is used. Joseph Macker: You implied Jitter is a standard. RFC5148 is informational. On some radios it is not necessary. Thomas Clausen: Correct, all the same, there is some normative language in there. Probability of suboptimal paths are fairly high. Using windows jitter [MAX_JITTER/2, MAX_JITTER] instead of uniform jitter [0, MAX_JITTER], leads to more optimal short paths. Conclusion: when using jitter in a reactive protocol, use window jitter. Teco Boot: Question on figure with short and long path... Thomas Clausen: This is a hop-count metric. Teco Boot: In 2006, we discussed that hop-count in MANETs is bad. I expect that one goal of this is that we select the right metric. Proactive/reactive does not matter. What does Jitter have to do with metrics? Thomas Clausen: First, we were not only using this when using hop count. A router will receive a RREQ, then later another RREQ with a better path. Jitter may cause reversion of order of the received RREQs. Teco Boot: That is my point. Somewhere in the protocol, you select the path given by the first RREQ. So you do not select the optimal route. Thomas Clausen: I don't want to get into protocols. If the packet goes through a path where each path segment has a sufficient quality that fully satisfies me, then I will use the first of those RREQs. I could also wait for 10 minutes and then take the best RREQ. It's a choice. Stan Ratliff: How do you know when you get the first RREQ that you will ever receive another one. Brian Adamson: If I was using reactive protocol on top something that reduces the topology, such as an CDS mechanism, would that mitigate some parts of the problem? Thomas Clausen: I don't know. Joseph Macker: It changes results. What was the MAC layer? 802.11? Thomas Clausen: Proprietary MAC. Also tested with smaller deployments with 802.11. Results were comparable. Charles Perkins: This effect was independent of jitter intervals? Thomas Clausen: Independent of jitter interval, but you will always observer the effect. Charles Perkins: Could even be observed without jitter (because of different processing times). Thomas Clausen: Yes. You can read the analysis in the paper listed on the slides. Charles Perkins: If you introduce enough jitter to cause delay inversion with high probability, then it is a wrongly chosen jitter value. Thomas Clausen: As the network grows large, even with small jitter you will observe this delay inversion, especially when routers are listening and only transmit when media is idle. Even with small jitter the total processing interval becomes rather big, and potentially more RREQs going to the destination via non-optimal paths. o Elastic multicast extension to SMF (RFC 6621): draft-adamson-elasticmcast-00.txt : Adamson [17] SMF is not intended to scale to large networks. Charles Perkins: I am surprised that you say that SMF does not scale to large networks. I thought that was the whole point of SMF. Brian Adamson: It does entail flooding to larger networks than classic flooding, but it is not unbounded. Joseph Macker: There is some limit of scale. At some point you don't want to flood any more (scenario dependent). Brian Adamson: EM is an attempt to increase the scale of flooding. Basic concept of EME: dynamic pruning of broadcast nodes in SMF. Favoring robustness over efficiency (degrades to SMF performance in very dynamic networks). Document available as draft-adamson-elasticmcast-00 Rough draft. Protocol timeouts not explicitly described. Rick Taylor: That's really good! o Open Microphone - Discussion, Related Work & Announcements [0] - Interops, Implementations, Other Items (nothing discussed)