Mobile Ad hoc Networks (MANET) Minutes NOTE: There are a number of inaccuracies in the minutes. Please refer to the audio in case of doubts: https://www.ietf.org/audio/ietf96/ietf96-charlottenburgi-20160720-1400.mp3 ========================================================= Meeting : IETF 96 Wednesday July 20, 2016 Time : 14:00-15:30 Afternoon Session I Location : Charlottenburg 1 Chairs : Justin Dean Stan Ratliff Secretary : Ulrich Herberg Jabber : xmpp:manet@jabber.ietf.org Audiocast : https://www.ietf.org/audio/ietf96/ietf96-charlottenburgi-20160720-1400.mp3 URLs : http://www.ietf.org/html.charters/manet-charter.html http://tools.ietf.org/wg/manet/ ========================================================= AGENDA Note takers: - Lucas Jenß - Lotte Steenbrink o Administrivia - IPR o Bash the Agenda [5] o WG Status/Overview: Dean/Ratliff [10] https://www.ietf.org/proceedings/96/slides/slides-96-manet-3.pdf - Recharter summary - Recap of Documents/Status - Announcements o Forwarding Information Base lessons learned: Dean [20] https://www.ietf.org/proceedings/96/slides/slides-96-manet-1.pdf * Starts by giving some background info on SMF Juliusz Chroboczek (jck): * Shortcomings of SMF (#3) Rick Taylor (rtr): Looked at using broadcast wireless links, i.e. lower layer to assist [?]? Justin Dean (jdn): We use multicast radio if it has that, [...]. If you have multiple interfaces it may be redundant to send it out on the same link it came in on. [?] algorithms don't allow you to do that [...]. Its not designed with that in mind. FIB designed to do interface based fowarding (?) * slide: nrlsmf functions * slide: current nrlsmf architecture * slide: separation of forwarding/control plan in the design * slide: current smf design jck: Are you describing something that has been implemnted or a plan? jdn: yes, and the code is available [... missed] rtr: directed at the chairs: is working on an API a suitable thing for the WG to be working on? I consider the [?] definiton very useful, and [...]. You're starting to drift off into netconf-y, yang-y or [...]. Not quite sure whether this work should be done in the WG, FIB absolutely, API no jdn: agree and we'll have to define whats allowed and not allowed at a minimum, we'll not say what the messages look like but we should define what can be changed jck: there's a lack of API in that space, so work on APIs is a good thing * slide: future - elastic multicast * slide: elastic multicast control/forwarding interaction * slide: flow vs. generalized forwarding * slide: just forwading? * slide: FIB api should not be unidirectional * slide: manet fib for just multicast? rtr: spent last two days in netconf. I'm really liking the way of fib, genralized datamodel [...]. but I'm very conscious whats happening with [?]. There's a lot of work going on in there, managing ephemeral routing state. Wondering whether you've talked to them? We should be interfacing with them rather than [doing our own solution] alvaro retana (?): susan has been working with netmod (?) quite a bit. There's been stuff lost in translation there with the requirements for [...]. [open mic begins] charlie perkins (cps): 1. lets say there are several multicast groups, is there a separate instance for every group? jdn: yes different forwarding for each group, group membership part is part of the control algorithm, but [... missed]. cps: lets say 500 nodes in the network, 3 of them scattered but yet to be part of multicast group, then the total amount of control traffic could be worse than just flooding [... missed]. jdn: [explains how previous approach worked] stan ratliff (srf): times up, can we take this to the list? cps: even if the rest doesn't work out, it would still be nice to use what you've got for the flooding operations jdn: there is an elastic multicast draft, we decided to step back to build it in the right way [...] o dlep extention: Ratliff [20] https://www.ietf.org/proceedings/96/slides/slides-96-manet-0.pdf * slide: DLEP * slide: DLEP Credit Extension * slide: DLEP extension - metric by traffic class rtr: can I just say that I have a couple of personal drafts for DLEP extension which I will present lou berger (lbr): traffic class sounds interesting, interested in how traffic classes are mapped to queues. and have you thought about credit by traffic class/queue? stan: have I thougt about it no, does it sound interesting: yes lbr: [missed] rtr: the ext mechanism of dlep is part of the negotiation at session init. my question is: does the WG want an extension per document or [missed; i think the q was if they could be lumped into 1 doc] stan: whatever makes sense. lbr: my experience is having an independtly implented thing per document is [good?]. [...]. rtr: wanna avoid having optional optional things. one document with three exts that go hand in hand, jck: I like big documents, all background in a single document. Would like to encourage the group to make big documents, and few of them. stan: as a vendor, it's hard to say "I'm supporting sections x, y and z of RFC..." jck: I'm pulling in the direction thats convenient for the implementor, he's pulling in the direction convenient for the vendor, [...] lbr: Pulling in the direction of the user rtr : the information is in one place, its called DLEP. we're talking about extensions to that document John Dowdell (jdl): speaking from POV of the ppl who have to specify: I think the ppl have limited technical expertise, so they say eitehr we use the doc or not, so independent documents easier, and we can say yes or no to each one stan: any other question? (none) [/open mic] o network coding in mesh networks: Wunderlich [20] presentation on "Meshmerize", reasearch project at TU Dresden * slide #2 introduction * slide #3 concept * slide #4 network coding in a nutshell * slide #5 network coding in a nutshell cont'd * slide #6 network coding in a nutshell cont'd * slide #9 (number jump?) network coding in a nutshell cont'd * slide #9 (again): multihop in meshmerize [note: dropping slide numbers from now, because they don't seem to be correct] * slide: multihop in meshmerize jck: assuming ARQ you'd get wildly different figures! [...] simon wunderlich (swh): with ARQ it would be much better, [...] * slide: leverage the broadcast medium * slide: leverage network coding characteristics * slide: leverage multipath * slide: preliminary results jck: batman is doing ARQ here [referencing the results on the slide] swh: think we configured w/o ARQ jck: do you remember the packet loss rate? swh: can't recall the exact numbers rtr: single UDP stream going from stream do destination? swh: yes * slide: summary [Q&A] ben schwartz (bsz): noticed that a lot of mesh routing system work well with sparse meshes, but collapse completely w/ congestion in ultra-dense environments (e.g. this room) [...]. How does your system fare in dense node envs? swh: we didnt implement that. if source/dest is in the same room, we'd [paraphrased: go to the receiver directly] bsz: how would you know that? swh: [missed] jdl: (ref slide "recoding"). [missed] swh: packing all the data, multiplying with coefficients and putting the coefs from multiple packets in one packet jdl: [missed] swh: thinking applying linear networking code [?] jck: really cool. are you actually hacking at the mac layer, or 802.11 mac? or own mac layer? swh: we are using 802.11 but w/ modified drivers, [...] jck: so the chip running original firmware? swh: yes jdn: really interesting work. I see this what we'll be doing in the future. the piece that I find interesting is how this works with what we're scheduled to do right now (FIB). This is another operation we hadn't thought of yet[... missed] swh: would be good, but did not really follow IETF process so far, jehan tremback (jtk): does this involve distance propagation? swh: was thinking about distance vector propagation jtk: still has vector propagation like other mesh protocols swh: thinking of using proactive protocol [...[ rtr: [... trouble following] swh: best case we can send as many input packets as output packets, just coded. if all of them are received we can decode. rtr: but you lose redudancy by doing that swh: we would decide on redundancy based on [...?] [discussion too quick :(] rtr: with my DELp authors hat on, can you start looking into using DLEP? Guido Iribarren: what about latency, how is latency affected in this small test? swh: [...] different approaches that affect latency differently [...] james ngyuen: have you tested [...]? applied manet characteristics like mobility, disruption, etc? swh: no and no. only four node network tested as well as simulation. ideas to test with drones exist, but not too much thought has gone into that --- o Open Microphone - Discussion, Related Work & Announcements [15] - Interops, Implementations, Other Items jck: there is really remerkable work in homenet, on autonomous management on networks (given talk on monday). we've experimented with homenet tech in mesh networks. it would be a great waste if the management work in manet would be done in isolation to homenet. srf: absolutely agree, we're always looking for volunteers to work on things. Would you volunteer? jck: am already working on that jerome bovet (jbt): there is a lot of research work to use a node's position to anticipate routes. has that been considered? jdn: [missed]. if you have question about existing manet architecture, please write to the list. jbt: we had good results with moving drones where we knew their exact path. jdn: please share on the list. if xou could prepare a presentation for the next ietf, that would be even better rtr: 2 cents: would love to see something called "augmenting manet protocols with position information" [...] rtr: are we gonna meet in seoul? jdn: have to check my schedule. before recharter we had a lot of work bogging us down. if there's enough participation on the list, we're gonna meet in seoul. think once a year would be too little, but depending on activiy rtr: I've got a draft up my sleeve working with Lotte on an RFC5444 extension, is that still part of your tasks? jdn: talk to me after this stan: session officially closed