An overview of the agenda was provided by Ian Chakeres. WG co-chair Joe Macker was absent from this meeting but was monitoring remotely.
After the opening agenda review and bashing, the WG's progress was reviewed by Ian (see slides). The status of present documents and the charter items was reviewed. Regarding the reactive protocol charter item, DYMO has seen good progress and is on its third revision.
There has also been significant progress in the proactive routing area based upon work being done and started as OLSR version 2.
An early Simplified Multicast Forwarding (SMF) ID was also posted and is intended to get work and discussion started. The -00 draft is available.
DSR is progressing to EXP RFC status
WG goals were summarized by Ian Chakeres:
There should be more mailing list discussion regarding documents. We want to collect implementation experience. We want to roll this experience into revised IDs. RFC-Diff helps show changes to the drafts and is also recommended.
Next a DYMO Update and Plans were discussed by Ian Chakeres
Changes from DYMO 01->02
Changing order of Document, routing before handling generic packets. This version resolved some naming ambiguities. There are changes to the way seq numbers are incremented. There are also changes to route timeouts and delete timeouts that are more flexible.
Avoids uni-directional links, RREP-ACK. This revision also defines behavior for seq num 0 comparisons. 12-bit length field, correct way to handle byte order was discussed.
There was discussion of when a RERR should be issued, when a link is broken or when a packet is for a route the is not there.. how should it propagate? Creates a small flood, for every topology change. RERR floods through neighbors with route.
Thomas- no aiming to flood to all nodes?
Ian- correct, only a subset of the nodes, only those with that route.
Better handling of data structures and packet handling, lots of similarities between pro-active and re-active, looking into reuse of a similar format. Implementation has found a number of tradeoffs of how things are handled. Path accumulation, currently is a SHOULD but might not be good for all types of networks.
There was a discussion of Simple Internet Gateway issues and a multicast address assignment for DYMO.
There are plans to look more into Neighbor connectivity monitoring. Possibly look into creating a draft or looking at other draft’s methods.
Charlie Perkins: LowPan is interested in neighbor monitoring.
Ian – There could be some crossover with 6LowPan
Low energy, small packet size. Changes to DYMO to make it better fit this environment
DYMO Implementations were next discussed.
NIST Dymo Implementation - Klein-Berndt
Currently available, implements the latest draft.
Runs in Linux Kernel
Supports internet gatewaying and subnets
Available at: https://sourceforge.net/projects/nist-dymo/
Dymo Implementation in OPNET - Kuladinithi
Opnet 11, 01 draft, 50 nodes
It has been tested against DSR, AODV
9 nodes, two sessions
AODV expanding ring search, leads to higher initial discovery latency
Total load BPS link-layer, DSR has higher because of source routing
50 nodes, start time equally distributed
AODV latency still highest
DSR route cache last longer than AODV and DYMO allowing it to have less RREQ.
AODV has highest Routing Traffic, DYMO has higher routing byte because of path accumulation. Path accumulation, improves performance by reducing RREQ, but only if the route is needed before route expires
Q: Any analysis of scalability?
Kulad - Not yet
Ian – DYMO written with a lot of flexibility allowing for trade offs to be made and we are interested in examining those tradeoffs analytically.
Pedro Ruiz next presented an implementation DYMOUM
Same code for NS2 and Linux 2.4 and 2.6 supported
Currently this code is stable but has only been run on static scenarios. Next we want to try on mobile scenarios
NS2 2.27 and 2.28
ToDo: currently using link layer feedback, not hellos, looking at adding this.
Simulation results, running under NS2, 50 nodes, not everything has been verified yet…
AODV, DYMO and DYM-PA
Path Accumulation reduces the number of RREQ
CP – does the lesser amount of RREQ have to do with intermediate nodes issuing RREP?
Ruiz – It may have to do with that…
Ian – it could also have to do with expanding ring search.
Ruiz – it is possible to enable expanding ring search in our implementation.
With Path Accumulation there are lot more RERRs because there are more nodes with more routes. When a link breaks, more nodes will propagate because more nodes have that route in the Route Table. One of the trade-offs with PA
Not a large performance difference from AODV
CP – two factors, 3 sec may not be long enough for route cache timeout. All that effort to then purge. 20m/s is pretty fast, may be good to have an adaptive route timeout.
Thomas Clausen – PA option was not present in AODV? PA in DYMO does not give a substantial benefit?
Ruiz- in the simulation you are not getting a benefit, but not enough scenarios, might get more benefit in other scenarios…
Ian – As CP mentions, this may be useful under certain conditions. It is important to identify these conditions.
TC – A different set of scenarios would likely benefit from it? Would some past experience help clarify where it would be beneficial?
CP – Yes, there was a paper from UCSB, that showed PA gave a 10% increase or so… the way DSR runs Source Route is a PA. It was added to help smooth a convergence between AODV and DSR.
Next an OLSR v2 Discussion took place to update efforts in the proactive routing area.
TC: This is largely the work of a design team that has been working on this and I am going to give a quick overview of the general design spirit/goals. We are aiming this to be in the MANET proactive protocol design space as an evolution of OLSR (v1). See slides for details.
Summary: fixing minor nits, improve expandability, we have inherited some algorithms and message handling
Changes from OLSRv1:
Uniform treatment of HNA and TC
Uniform treatment of IPv4 and IPv6
Internal extensibility of messages
After some significant recent design meetings and editing we have produced a draft document that will be made available. We also generated a rationale document to accompany the specification.
Targeting document submittal 8th of Aug when deadline lifted. Also an end of sept/ early oct, draft incorporating changes. Pre-Vancouver
Next Brian Adamson provided an overview of SMF Plans/Discussion
(see slides for details)
Duplicate Packet Detection approaches and issues were discussed.
Seq num approach probably the most robust. IPSec already has a seq number in packet
Hash based schemes also possible but false alarm issue and complexity require consideration.
Methods for determining and using efficient relay sets were discussed. An implementation of SMF has been tested in the linux and within ns2. Comparable performance was observed with both ECDS and MPR flooding, ECDS is a bit easier to implement. Not conclusive though, more analysis is needed with more dynamic scenarios, different MAC layers, one-to-one and one-to-many traffic scenarios.
Jasques: pretty old algorithm, problem with mobility?
Justin Dean – robustness with mobility, if you have a MAC layer way of getting information about link status, you can react faster and select better links. We are looking at different relay set algorithms in terms of both performance and implementation issues.
Brian: Possibly interested in maintaining modularity for customization
Jasques: we have recently released a report on this that looks at the advertisements, I will post it to the list
TC: when you want to do relaying, MAC can make a big difference if it can help when you are selecting relays. We should probably not be putting requirements on the MAC layer, and not make assumptions about it.
Brian: I agree, I am hoping we can make a sufficiently modular that would allow it to take advantage if it is available.
Chris Delar: you were comparing number of forwards needed to flood a network
Justin: Yes we were
Brian: There is no correctness restriction that you have to follow a tree with the ecds, you can forward a packet if you hear a packet early
Chris – number of packet forwards
Sue Harris – On IPv6 header option, Hop-by hop vs destination header
Brain – Haven’t looked into this enough, with destination, it needs to be kept
Brain – Looking to have option stick to packet for the lifetime of the packet, for sequencing we would like for it to stay in case it leaves network and comes back. Lets packet safely exit and enter and be discarded
Sue: When you talk about baseline neighborhood discovery, can you describe what you want?
Brian: The reason it is brief is the each neighbor selection is different for each algorithm.
Sue: So you are trying to look at commonality of neighbor discussion?
Some discussion of gateway issues and unresolved tradeoffs.
CP – Discussion on not depending on MAC layer, possible to do some very good things at layer 3, with only adding a few extra bits.
SMF Implementation Issues
Nodes not running can still recv multicast packets
William – always had problems with dense mode to sparse.
Brain – deferred to gateway, what should be forwarded from dense.
Alex – have you done any analysis on the amount of data you need to maintain vs, amount of bandwidth. How to calculate the window?
Brain – Somewhat dependant on the MAC layer, which have queues that result in 1 sec delays, total of 10 or 15 sec delays…. Need to looking into dynamically setting. Mostly observation study …
Alex – Would be interesting to look at this, scalability issues with this.
Justin – not store entire seq number, just a window and 1 bit for each seq number, this is why each number needs to be in order.
Brain could be timeout and depth limited, there are strategies that could be used.
CP –ID may not just be an IP, ID can show willingness to be leader, can also include degree of connectedness into ID.
Packet format based upon MPRF, can build connect dominating set without using MPRs
2nd OLSR workshop Discussion
An OLSR workshop and Interop took place in Paris prior to the IETF.
TC – the slides presented during the inter-op will be made public pending the authors agreeing to it.
Autoconf BOF update was provided.
OSPF MANET update was provided.
Open discussion, related work & announcement
CP – It has been brought up a number of times that hop count is not a good metric, should we look at finding a better metric?
TK - I think this is a good thing and current protocols should allow for using any metric you choose to use. Not sure we can find one metric for all wireless media.
QOS – Hakim Badis