Skip to main content

Minutes IETF103: manet
minutes-103-manet-00

Meeting Minutes Mobile Ad-hoc Networks (manet) WG
Title Minutes IETF103: manet
State Active
Other versions plain text
Last updated 2018-12-15

minutes-103-manet-00
Justin Dean notes
Stan Ratlif: The LID DLEP extension has been in request for publish state for
80 days Rick Taylor: Log jam of lid extension please unjam document chairs/area
director Alvero Retana : It's just a bunch of documents in the queue ahead of
it and it's nothing about the document itself at this time. Rick Taylor: Okay
we have working code and just would like the documetns moved forward. Stan
Ratlif: There are 4 active working group documents that Lou is going to talk
about.

Lou Berger (Presenting): DLEP Extensions.
Lou Berger: here are the DLEP extensions that are working group documents. 
Working with David Wiggins and Bonan Chang.  We just talked about the latency
extension...I'm sorry we didn't talk about. We issued a last call there wasn't
any comment on list.  Latency is ready to be pub requested. Justin Dean
(chair): Agree this document is ready for pub request it's really simple and
shouldn't be an issue.  Any comment in the room? None Lou Berger presenting
slides:  I'm going to talk about a set of 3 documents that are all related to
credit based flow control.  These documents have a bit of history.  It started
with a document that Stan had written, DLEP flow control; and along the way
there was some decisions to split the doucment apart.  That's why we have a 00
that we think is ready for last call.  We have taken the last open issue in 03
of the previous document.  Documents have been split apart to reflect specific
extension functions.  We think these three documents are ready for last call. 
We also have another draft ethernet-credit that we would like to be adopted
into the working group.  We think it may be ready to rapidly move though the
working group although most authors think that about thier documents. Rick
Taylor: I fully support addoption of the ethernet credit extension into the
working group. Rick Taylor: the reason we were spliting it out was that DLEP
extensions exsited in their own ethernet and dscp were split was so that they
each extension had it's own draft? Lou Berger: I think you're presenting my
slides for me.  Credit control is an important thing on its own as is traffic
classification and we may want to do traffic classification without credit
control and vice versa and we should be able to specify that.  We can refercne
the RFC that just references just credit control.  If the WG would like to have
them together we can do that but we also buy into the rational for splitting
them appart. Rick Taylor: I was the guy who asked to split the doucments simply
because I want to do metrics per flow hence I want to refer to the document
about flows without having to refere to credit windowing. Lou Berger: I think
you're getting to the bottom of my slides.  Here we have ethernet credit
windowing vs IP credit in seperate documents so you can be clear on what you
are specifying.  Thats both from a vender standpoint and user standpoint.  If
you don't do this you can have a radio/modem and a router that says it's
conformant and one does ethernet and one does IP and guess what it doesn't work
together.  These are basicly the same doucment but they sepcify differnt code
points.  The key point that extension drafts do is that they ask IANA for
assignments.

Lou Berger: What's next? We think the first 3 are ready for last call.  The
ethernet-credit is very simple, as Rick said difserv aware but with ethernet
ieee802 headers.  On that last document we would like the working group to
adopt it and last call it although it would have been outragous to put that on
a slide.  For current documents they have been basicly stable with improvements
in cleaning up the document but functionally they are the same. Stan Ratliff: I
think we should put the 3 documents into last call and put adoption of the
ether-credit-extension onto the mailing list.  Because of that I don't think
think we can bundle them all together because of that extra step. Alvero
Retana: I don't really want to add more docuemtns to my queue, as you've
already pointed out in your first slide I'm already late.   It's up to the
chairs descression to issue a last call or not.  In other words that ethernet
draft is pretty similar to the other ones and there is no contention you can
adopt and issue last call. Stan Ratliff: We could have some very slim chance
that someone has some issue that comes out of the left field with some issue we
had not seen coming. Rick Taylor: It' would be good to have a pause between
addoption and last call to allow for ipr declerations. Lou Berger: there are
none from the authors whatsoever. Rick Taylor: Same for me.  Just a small
pause. Lou Berger: I'm a firm beliver in offical IPR decleration periods.  Just
a question does anyone have any objections or comments about any of these
documents? (there were none) Lou Berger: I'd like to point out that my
co-authors have some open source DLEP code published. They have made an update,
I meant to check before I got up here that it got pushed....the hope was that
update would be availble in the repo and that change was to put in sub-data
items. And the putting in subdata items ended up being a little bit more
complimented than anticipated. It's my opinion, not that of the person doing
the coding, that's David, that was because the code was originally written
without this in mind and had to be refactored.  We did talk about a
simplification that would have made his code more easy to impliment but we both
agreed that it wouldn't be the right format for the standard.  It actually is
an unnessary restriction that would limit how we use future extenions and that
was is in the documents is better even though it made his implimentation work a
little bit harder. In the end it's done and people can get the code. Justin
Dean: I have a question to the working group and the IETF in general about
documents do we want to continue proceding with having one extension per
document, or is there a way that the the IETF uses to specify multiple
extensions so that you can say RFCXXX.2 or some subset of that document. Stan
Ratliff: There was a smart man who had explained if you put mulitple extensions
into one document you then let implimenters pick and choose feature you want to
impliment and then claim conformance.  So my vote would be no on that approach
for exactly the reason that Lou comment on on multiple occasions. 1 to 1 so
that if you say I support RFCxxx you support all the functionally in that
document. Justin Dean:  I agree with that but if you say you support RFCX you
support everything in that RFC. Lou Berger: I think that options lead to
interoperability issues. So, I'm from a physisophical standpoint I want to
eliminate or minimize options in a document. Justin Dean: Like I said this is
more a question of how the IETF wants to function.  You know is it a problem
having 100 DLEP drafts/extenions as RFCs? Alvero Retena: Routing Ad. It's up to
the working group to decide what to do.  For me personally because they have to
come into my queue I'd prefer fewer documetns.  This isn't the only working
group that has has this question.  Sure you ask if someone supports RFCX
section 2 but that gets really not nice.  So if the working group wants to
publish any number of extenions in differnet RFCs thats okay by me. Lou Berger:
Alvero a question.  Does it matter if the documents come in a set or trickly
out a little bit at a time. Alvero Retena: the only issue for me is if they
reference each other. Lou Berger: the ones that have -extension being on ref
wait on the other two. The second two depend on the first two. Alvero Retena:
The only thing that really matters to me are those references. Lou Berger: I
think it would be nice to have them as a set but is it required absolutly not.
Alvero Retena: You may want them to be processed together around the same time.
Lou Berger: I think it would make the directorate review easier if they were
together. Alvero Retena: In the past I've often sent some notes letting people
know which draft to read first so things can move a bit smoother.  So if you do
that please provide me some guidance so that I can pass it along. Rick Taylor:
Talking about RFPs the incoming RFPs I've seen about DLEP have actually
specififed extensions and not RFC numbers mostly because most of them are in
drafts.  People seem to be talking about I need this extension or that
extension. Lou Berger: So that argues for colapsing them.

(seems to be agreement that doing documents one per extension is the way to go
for now but will take it to the list)

Christos Politis (Presenting) M-CML presentation
Christos Politis: You may have remembered us as we gave a presetion on similar
work in 2014 called chameleon your meeting in amsterdam and one in the states
as well. Christos Politis: We tried to commercalize it and to be honest we
haven't been very successful so far. We have a very big project funded by the
UK governemnt to work with Malaysia to set up an emergency netowrk to provide
comunication like with the tsunami here years ago.  They will have a 5g network
so we will have an extension to that. Christos Politis: Chameleon was a hybrid
between proactive and reactive protocols very well defined by the IETF so I'm
not going to talk about these protocols.  So we've continued work and created a
update to Chameleon we are currently working on this at a protype level.  The
plan is to operate a network here (Malaysia) with 4 phases of operation.  We
got a lot of comments that last time we presented and took those on board to
create a monitoring phase.  We have two new messages, one is the hop count
request, and hop count reply. We are working with the multipath extention of
OLSRv2, and the reactive side is AODVv2. This montioring phase is done within
the proactive phase.  The reactive phase is triggered when depending on the
current scenario and the algorithm we've designed.  The transion from proactive
to reactive is the (oscillation?) phase which is the same at the prior
Chameleon phase.  We've used the NS3 for simuations based on emergency cases. 
The adaptive mode analysese the network state and chooses the mode of
operation. Stan Ratliff:  From the chairs prepective my question to you is.  As
one of your future directions looking to ask the working group to accept this
document and take on this work?  Or is this more of an informational thing?
Christos Politis: We would like to move it through your working group. I know
that takes time and takes effort obviously. Hopefully we will make this a
working document. Charlie Perkins: there is a monitoring phase is this some
sort of distributed monintoring or how does that work. Where is the monitoring
working is there some device in the network that is doing it or is it
distributed? Christos Politis: Yes.  Slide number 7.  The monitoring phase is
part of the adaptive module that was part of the previous draft.  The only
difference is it monitors the hop count reqeust messages.  The plan here is to
be distributed.  We want to use some sort of AI to train the system.  In order
for us to train the system what we need to do is to have more scenarios.
Chairs: Interesting work but in the interest of time we need to take this to
the list and discuss if this is work that we are intresting in working on.
Christos Politis: Just one last thing there is a bunch of working happening on
the periphery of the network so MANET type work is a hot topic right now.

Ed Birrane DTN presentaiton:
Stan Ratliff: If I could ask you to keep it brief as we are running short on
time. Ed Birrane:  I'm a member of the DTN working group and one thing we have
been working on in the DTN working group is what does netowrk management in a
DTN network?  How do we manage a network when we have interuptions and
disconnections? We cannot assume a full model of information.  The way we
distilled the problem was what is the most constrationed systems we have, space
management systems.  Where didn't have an idea of timely round trip time data
exchange. I worked on new horizons which was out past pluto and what we did in
these systems was to have an autonomy model for fault management and we know
how to do it.  Pretty much all spacecraft do it in the same way there are some
differences but they are by and large the same.  This is not how we manage our
terestrial systems as we have open standards high connectivity and large
investments into these systems.  The question then (in DTN) is there a
motivating overlap between these highly customized autonomous systems and
highly connected fast pull network management systems?  And we came back and
said there is a use for something that lives in that overlap and that is what
we are designing in DTN. We coined the term asynchronous management and open
loop control where the devices have high distruption of comunication either via
physical limitations or by the priority and or cost of mantaining those
connections.  We decomposed the work into 3 layers.  The asynchronous
management, basicly a requriements document.  Second we developed a data model
we called it an application data model, primatives and how you would
communicate with them.  These (the primatives defined in the chart) aren't
particulary new for those used to doing management of networks but the
difference is that it's not simply reporting back open loop control saying when
I can't communicate with you these are the responses I want the device to take.
This is the data and when to report and when not to report and this is more
than just a table with some stasticis to report on. And last is AMP or the
Asynchronous management protocol which defines how to communication the
information. We are starting to standarize on this the AMA is out there and
this is the place to start looking.  We have taken several appliations
associated with DTN and thought about what it would be like to manage those
protocols and applications and we put that in an open soure management using
AMP.  The reason we are bringing this working to this working groups is that
part of our motivaiton is sensor netowrk, space networks, and mobile networks.
So we are looking for people working in those spaces to give us feedback on
what it would be like and is typically currently like to manage those types of
systems. and challanges when trying to manage these highly mobile netowrks.
Rick Taylor: As working group chair of DTN we are taking this around outside of
DTN because we understand that we can't just come up with our own way of doing
netowrk management. Please comment.

Rick Taylor presentaiton: DLEP multicast priority extension idea
Rick Taylor: This is a pre draft presention idea.  There are two reasons for
DLEP.  The radio knows more about the radio link than the router so the router
should go and ask the radio what's happening at the link level.  Second is if
you can pre-fill your link information and your arp caches you can send around
some inintial data without fewer messsages.  Fundamentally multicast procolos
rely on relay points for distrubuting.  A lot of the algorhtims that select
these points use 2 hop tables and messaging and varous algorithsm.  The radio
system underneth has it's own topology based on this own physics. A sat
network, hub and spoke, for example you want the satilite to be the relay point
but an algorithm might just say hey I have the largest ID I'll be the relay
point. The basic idea is to allow the modem to inform the router I'd make a
good relay.  A second part of that would be to allow the router to inform the
radio that I've been selected as a relay.  This is really useful for multicast
this orthogoal to any of the multicast stuff in DLEP already.  How do we do
this?  A new extension!  It would have two parts one would say I'm a router and
the willingness to be a relay or if it's already been selected as a relay.  And
the second would be the other way with the radio informing the router that "hey
I don't know how you're doing your relay selection, but you'd make a really
good relay canidate" or "you'd be a really BAD canidate for a relay because you
have awful connectivity".  After this there could be a second draft saying this
is how you'd use this with PIM for example.  Also OLSRv2 or OSPF MDR election.
Alvero Retena: PIM is currently working on ASM which means that you don't need
relays anymore as the multicast is single source multicast. Rick Taylor: I'm
not a PIM expert but there is still tree building so for a branch in your tree
their effectly relaying. Alvero Retena: So I'm a better canidate to be a
forwarder for exmaple. Rick Taylor: exactly without having to say you are the
designated randevu point.  Good point about those points disapearing. Unknown:
how does this effect the layer 2 having it's own topology? Rick Taylor: That's
exactly what it's designed for. Unknown: No. So when you're layer two you
inform the router you're a good canidate. The election happens at the network
layer. The next hop is taken before the decision is made.  The conditions might
be good when you informed the radio and then when it's time to forward a
message the conditions might have gotten worse for example, as that's what can
happen in wireless networks. Rick Taylor: The singnals comming through are not
sets. they are not demands. they are purly information.  So the radio can say
you'd make a really good relay and the router can say I'm running on 2 AA
batteries and not self select. What the other layer does it entierly up to that
layer, this is just providing more information to make those decisions.  So is
this really 2 extenisons router-radio and radio->router. This goes back to the
one document 2 extensions and or 2 docs. Justin Dean: OLSRv2 has a willingness
value of 0-8 and in SMF their is a router priority field which these could feed
right into. Lou Berger: In the interest of limiting scope of inforamtion
instead of just providing a single number I would like to see more details from
the radio, such as connectedness, and let the router decide how to use that
informaiton instead of a single number that the modem is making up based
information that may or may not be important to the router. Stan Ratliff: That
is what we were trying to do is to provide more information to the router so
that it can better make a decision. Lou Berger: But you have to give the modem
knowledge of the selection algoirthm instead of that just provide the router
information about the state and let the router use that informatin as it best
can. Rick Taylor: If I can paraphase. You're saying don't just have a boolean
flag good/bad but have data items which list information about the radio. Lou
Berger: Yes and I think that this is great stuff and would like to see it done.
Chairs: out of time lets please take it to the list.