IETF75 Mobile Ad hoc Networks (MANET) Working Group Minutes Date/Time : Wednesday July 29, 2009 / 0900-1130 Chairs : Ian Chakeres ian.chakeres@gmail.com (absent) Joseph Macker joseph.macker@nrl.navy.mil (absent) ProxyChair : Brian Adamson Minutes : Christopher Dearlove (and others) Jabber : manet@jabber.ietf.org Scribe : Thomas Clausen Materials : https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=75 ========================================================= The meeting was opened and volunteers were solicited for note taking and jabber transcription of the discussion. The following agenda was presented and accepted. AGENDA o Administrivia - Mailing list: manet@ietf.org - Scribe(s) - Blue Sheets - State your name at the microphone - IPR o Agenda bashing o WG Status (Macker) o PacketBB, NHDP, OLSRv2 Discussion: Clausen - RFC 5444 - draft-ietf-manet-nhdp-10 - draft-ietf-manet-olsrv2-09 o SMF Discussion (Macker) - draft-ietf-manet-smf-09.txt o MIBs Discussion/Update: Robert Cole/Ulrich Herberg - draft-ietf-manet-dymo-mib-02 : Cole - draft-ietf-manet-smf-mib-00 : Cole - draft-cole-manet-report-mib-00 : Cole - draft-ietf-manet-nhdp-mib-00 : Ulrich - draft-ietf-manet-olsr-mib-00 : Ulrich o PacketBB Security: Ulrich Herberg - draft-herberg-manet-packetbb-sec-02 o Looping Issues Discussion: Lee Speakman - draft-speakman-manet-looping-issue-00 o Hierarchical OLSR (holsr) Update: Yannick Lacharite - draft-lacharite-manet-holsr-02 o Open Microphone - Discussion, Related Work & Announcements - Protocol extensions ================================= PACKET-BB, NHDP, OLSRv2 DISCUSSION Thomas Heide Clausen Thomas presented an updated status of the PacketBB (now published as RFC), NHDP, and OLSRv2 documents. It was noted that the slide did not address the "olsrv2-metrics" draft (draft-dearlove-olsrv2-metrics). It was stated that this _will_ be incorporated into the next revision of the OLSRv2 document. Thomas also announced dates for OLSR/NHDP/PacketBB Interop events. Thomas sugggested and Hiroki Satoh agreed that we move NHDP forward to working group last call (WGLC). There was consensus that this should be done. SMF UPDATE ========== Brian Adamson presented some slides describing some minor updates to the SMF draft. There were not many comments and it was suggested that SMF, as an Experimental proposal, may also be ready for WGLC. Ian Chakeres was identified the shepherding chair for this document. It was commented that SMF has dependencies on NHDP and thus both should go forward in concert. MIB DISCUSSIONS ================ Ulrich Herberg and Bob Cole presented updates on the MANET MIB documents in progress. This included the concept of performance groups for collecting statistics of operation in a consolidated fashion. Thomas Clausen presented the OLSRv2 performance group and there was some discussion. Here is a synopsis from the Jabber record: Question: Henning Rogge: must be a little bit careful about msg seq no, as loss of a msg seq no doesn't tell you anything about your neighbor relationship but org. Ulrich: But this is NHDP, all messages are between neighbors Henning: not quite, message sequence numbers are not message type specific Charlie Perkins has question: is it possible if you are running in simulations or something, to calculate the percentage of time that you have an actual tabulation of the neighborhood? Thomas : Yes it is possible to do this must you make some assumptions. The Q is that if in theory I have reachability, does not mean I do have. Charlie : we can talk about simulation, but you can do better by putting in realistic distributions of link failures Thomas : i haven't seen any models that come close to real world, but we can add caveat that it is an approximation PACKET-BB SECURITY PRESENTATION ============================== Ulrich Herberg - draft-herberg-manet-packetbb-sec-02 The document is not about how to use/verify.calculate signatures, but similar to TimeTLV [RFC5497] in assigning code points and TLV structures to support security mechanisms. Discussion on why not use of PacketBB Type-Extension for encoding crypto-fkt AND hash-fkt. Consideration as a MANET WG document: Thomas Clausen: If the doc has to become WG doc, it needs be confirmed on the list. But more importantly, it's written with a spirit similar to TimeTLV to avoid redundant code-point assignments, and data structure def., so if the SMF/DYMO authors could take a look. LOOPING ISSUES DISCUSSION Lee Speakman - draft-speakman-manet-looping-issue-00 Lee presented hist approach to studying this and presented some simulations results and stimulated a long discussion that is summarized here: Comment from Thomas : What you suggest is that when discover loop, you throw away looping packets? Lee : Not a real solution, it is just to determine the impact Thomas : So what do you propose? Lee : It's a complicated issue and still requires research. Lee : Notes it i hard to know what is going on w/o simulation. Thomas Heide Clausen : (I'd contest that: hard to know what's really going on from looking only at simulations ) Lee : Due to effect of looping significant reduction of symmetric links In a network there are constant data rate UDP applications Thomas : These results or similar were presented a while back. at the time the link notifications were not being used in conformance with the draft. has this been fixed? Lee : AFAIK it in conformance w/ draft Ulrich : Why does it make a difference to ratio? Why more routing loops with link notifications than w/o This shows on simulation results but not convinced Lee : Link layer notification comes from any lost packet and causes the link to be removed. Leeds to more loops in the surrounding Joe Macker: LLN can be stochastic it may cause instability . The LLN technique is also in question. Thomas : suggests good idea to rerun study with trigger messages Lee : have done, but only small improvement Joe Macker: Loops do happen but perhaps not at the severity of this LLN model Lee : if there is loop you don't get control messages Chris Dearlove : loop should not cause loss of control messages. this is 802 problem not a routing protocol issue. Chris : Still don;t understand that variation Q : Can we deduce anything for reactive protocols, or just for link state protocols Lee : Any protocol that has routing loops Lee : specific to link state protocol Joe Macker: I think there is an open question on severity given LLN model assumptions here, would like to understand the LLN used in more detail. Henning : there is distinction between jamming issue of loop. If you don't resolve jamming then LLN not much help. But if you unblock jam, LLN may be even better Lee : Agree, this is why we need something at the network layer Heening : Look at techniques of SMF. Could be reused to detect loops in both mcast and unicast Joe Macker: Definitely must model control as priority, agree with Chris Teco Boot: loops are a fact of life. Jitter, duplicate detection etc. are tricks and options to try. But the main issue is, we have looping issues in our protocols. Main point is - routing loops exist. get over it Lee : not using link layer prioritisation in this model Thomas : lists three things that need to be done. Lee : agrees Lee : the simulation is 802.11 based. Unicast packets are ack'd. failure to rx ack then we have LLN to the routing protocol saying packet dropped. Relative link state is updated and removed. Also tried w/ and w/o triggers Joe Macker: Using lack of ACK as trigger is bad in my opinion. Use other metrics Chirs : repeat please (fail to rx single arp will drop link?) Lee : after several retries Chris : using 802.11 integrated signal to noise ratio w/ hysteris Q : Want to disagrree that we only have to handle routing loops. >> we must face loops in link state protocols because the routing tables get out of synch Lee defends no-ack-trigger and debates value/cost of sensitive trigger Joe Macker: Lack of ACK may mean congestion not link bad Thomas : Brian hit on something important. If your action makes things worse, it is the wrong action! Lee : not loss of a single Ack. It is a sequence Thomas, could still respond to a very transient event. Create unneeded corrective action creates loop = bad Brian explains again some issues on the inter-dependencies of making/filtering actions with respect to actual network dynamics (e.g. due rates of mobility (motion speed, etc). Lee : but do need to deal w/ issue when the node has moved out of range AdrianFarrel: Isn't this a question about how ast you need your routing protocol to *locally* converge? AdrianFarrel: Attempts at rapid local convergence cause disruption if they are dramatically faster than network convergence. That is the way it works. Joe Macker: Yes, many short time varying physics at play, tradeoff between overreacting and converging Joe Macker: There was a long thread on this on the mailing list, they are hitting the points.. Chris Dearlove and Teco Boot discuss link metrics changes and LLN... Joe Macker: Right, the points are being reiterated here. HIERARCHICAL OLSR PRESENTATION Yannik Lacharite - draft-lacharite-manet-holsr-02 Will present mainly the "Cluster Decomissioning" mechanism that is new in the -02. Joe Macker: Is there a working implementation? Answer; There is an OLSRv1 impl, an OLSRv2 implementation is in the works. Chris Dearlove: Not a question of the specific details, not having read draft either. However: in what sense is holsrv2 a compatible extension of OLSRv2? If you have a perfectly working HOLSRv2 network, and a normal OLSRv2 network coming in reach. Does it (i) break, (ii) be ignored or (iii) just work Yannick: it "just works", actually. Herberg: any additional security considerations section to the one from OLSRv2? The sec.cond section is empty Yannick: Expect to build upon the OLSRv2 security considerations, when it gets through the process with standardization. Charlie asks if there will be rechartering to sec, clustering, multicast, ... of MANET "soon" ? Joe Macker: Agreed WG said ok to extensions at last WG meeting. Still need progress in parallel Adrian Farrel: not resp. AD (oxymoron anyways), looking at charter, only 4 milestones unattended to dated April 2007. That is past, even in IETF-terms. They appear to be "write a protocol". You should be looking at extensions, and you should be "bubbling that up", but you should look to finish your existing milestones. Joe Macker: Good points by Adrian MEETING ADJOURNED