Minutes for MANET at IETF-96
minutes-96-manet-2

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 <bebemaster@gmail.com>
                Stan Ratliff <ratliffstan@gmail.com>
Secretary   :   Ulrich Herberg <ulrich@herberg.name>
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): <missed question :(>

* 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