IETF 98 - MANET WG 

Current WG status:
OLSRv2 Sec Threats - in AUTH48, waiting for author response.
credit-window-07 draft pending a merge
OLSRv2 multipath - AD evaluation
RFC5444 Usage - AD evaluation, revised I-D needed.
DLEP approved for publication, no functional changes. Change was to add informative ref to approaches to pre-shared keys for TLS, for use in a "dedicated deployment".
DLEP extension drafts in flight
Container Data Items in DLEP - discussion in Seoul and on-list but no draft yet. Get on mailing list if you are interested.

Lou Berger - Flow Related DLEP Extensions Update
4 drafts accepted as WG docs. 3 unchanged since then.
Credit extension had 1 revision, did 2 things. When to send data (i.e., only when credits are granted), and identified open issues in doc based on comments from Stan and Rick, including how to structure a list, hence the Container Data Item idea.
Implementation available, by MIT-LL, DLEP code and wireshark dissector on GitHub (link on slide 2). Questions asked about routing protocols supported - none. Just stack, to integrate into larger implementation. Re-usable, open source license.

Latency and Multihop extensions:
No issues known, asking for comments, implementations, and maybe Last Call. Not complex drafts.
Rick Taylor - At Seoul, asked if range extension could apply to all core DLEP metrics. 
Lou - could you provide a proposal on list?
Rick - sure.
Lou - how do you deal with options of which you send?
Rick - hoping same mechanism can be applied, but yes, negotiation feature needed about which will be used. Not ready for last call, we can make this a better document by addressing more in the same draft.
Lou - keen for implementation, welcomes Pull Request to GitHub MIT-LL.

Control Plane Based Pause Extension:
The draft add extension to say "stop sending" / "ok to send". Open issue on coding. Container idea proposal is a better way to support lists. This is a worthwhile extension. Do we wait for the proposal on containers, or go ahead?
The container Data Item would have normal Type and Length, then the Value would be a set of Type-Length-Values. Length of container implicitly defines how many data items are in the container, i.e. to know you reached the end of the list.
Rick - advantage is, if you look at data item type for the container and you don't care about it, you can just skip straight over using the total length value.
Stan - fully concur.
Rick - can produce a doc, best practices style. Not a Data Item Type registration itself, anyone using this technique will define their Data Item type.
Lou - Each Data Item needs to be specified as allowed to be in a container.
Rick - this is a "meta-extension" so what kind of document would we write?
Justin - could use this concept in this "Pause" extension draft, and refer to this as an example later.
Two options: either a Generic Container Data Item, or specific Data Item type which is a container.
Stan - let's get started on a doc defining containers, we'll work out whether Informational/Best-Practice later.
This "Pause" extension depends on whether a container is a real thing or a meta-thing.
Lou - We can synchronize when that Container doc is written. Willing to wait until next IETF.
Rick - We will have it worked out by next IETF.

DiffServ Aware Credit Windowing Extension:
Another credit window draft exists. This one does flow control in one direction only, and uses DiffServ.
Update to draft clarified that router can't send traffic until credits are explicitly granted. 
Open and resolved issues appear as Appendices to the draft.
Resolved issue - Appendix A.6 in the draft. Decided not to do bidirectional flow control right now. Issue was in the setup. Lots of special cases added complexity. Could have the other direction as another extension. Not clear if anyone was going to use it. Example, PPP extensions - never used flow control from modem to router. Was this WG consensus? Yes.
Stan - Yes, OK to proceed this way. Would like to agree on abstract names for the 2 different roles, so it would be easy to document. Intent to get another rev of initial doc with abstraction, so that they can be more easily merged.
Lou - will try to use more generic terminology but not change messaging at this point.
Justin as chair - worry that we may go back and forth too long on this. Want to see progress by next IETF.
Back to presentation - this draft defines 1 DLEP extension, 2 Messages, 4 Data Items - one with potential container. (Summary of use for each on slide.)
5 open issues:
A.1 merging with existing credit window doc, planned, but when? Prefer to resolve open issues first, then merge.
A.2 Credit windows are per MAC currently. Not always supported. Some media share queues across a set of, or even across all destinations. This is missing. We have a proposal on how to solve that. 
Proposal is to replace queue definition with a credit window data item, describing one credit window identifier (CID). A CID can be per destination or shared across destinations (assigned to destinations in Destination Up message). It also defines a list of DSCPs used with that credit window, and an initial credits value. So CIDs can be defined at the Session level.
Rick - support for this way of doing it, not paired to a destination. Is there a Data Item associated with the CID initial credit grant? This does creation and initialization at the same time.
Lou - we could use 2 Data Items. What if grant came before definition?
Rick - data item processing is not order sensitive.
Lou - you'd have to scan the whole thing, then check for the creation data item, then the initialization data item.
Lou - this does support creation then later init, because it doesn't tell you what MAC address to associate with it. You would create the CID on the session level, then refer to CIDs in destination message. Also multiple destinations can share a CID.
Lou - in the per MAC case, you can provide the CID definition on Destination Up. Or you can do it at session start, and apply it to only one destination. The Destination Up contains a list of CIDs which can be used with that MAC destination. Router allowed to send to that MAC with any of those CIDs, so based on mapped DSCPs, it can determine which credit window to use and deduct used credits.
Justin as member - What if you have a conflict, i.e. a packet matches DSCP but matches multiple queues?
Lou - Traffic without a matching DSCP is dropped. If 2 windows have same DSCP in it, which credit window do we use? That's an error. Error can be detected by router when destination comes up, can see an overlapping credit window.
Stan - base DLEP spec has ability to deal with errors on up. Either terminate, or continue.
Lou - session terminate is too drastic.
Rick - clarification of error code. Destination Up Response has status code. 2 types of status codes, terminate/continue. If you think "peer's session has gone very wrong", you terminate. This doc should define status code/s like "credits have gone wrong and don't talk about this destination" or "credits have gone wrong and lets carry on" and what to do. 
Lou - or "credit window overlap". Maybe cease, ignore this MAC.
Rick - could pick a CID and notify which was chosen.
Stan - router could respond with Destination Down. Also an "Ignore" status code exists. 
Rick - If I sent you Destination Up Response with "not interested", you are not allowed to talk about it unless I announce it to you again. Put comments in doc to note this?
Rick - In DLEP core spec, stuff you announce at session init is overridden by destination messages. 
Also could reject a credit window ID.
Lou - Is there a decision?
This discussion can be taken to the list.
A.3 Supporting router limits. e.g. if router can't support the same number of credit windows, or does not support per-destination credit windows, how would the router tell the modem?
Rob Hamilton - avoid saying it can support that?
Lou - objective is to have the control signaling in place to be smart about using the capability available.
Rick - Assumption in DLEP is that the link between the router and the modem is better than the link to destination. Not too worried about usage of control plane.
So A.3 solution for issues 1 and 2 as presented on the slide, negotiation in session establishment.
Rick - session init was designed for this negotiation.
Lou - The more you can shift to session init, the faster you can use destination up.
Rick - Likes the CID model. Looking at issues of duplicates, can you push early processing?
Options for A.3 solution for issue 3 as presented on slide, report error in credit control message, or log.
Justin - if modem changes its queue/CID setup, for example if links change, if modem is trying to do something clever, you lose the ability to inform about changes.
Lou - you need to re-establish the profile. Modem says "now I'm using profile 4 for that destination instead of profile 5".
Stan - if a queue is defined as 5 code points, will it ever change to 7, or 2? Data rate changes are handled by credit increments.
Lou - think we can do this with sets. Question of scale.
Rick - split credit window instance from credit window set of DSCPs. Don't see why profiles couldn't be introduced later.
Lou - could have Destination Up message include a mapping of DSCPs to Credit Window IDs for that destination.
Rick - figure on slide 10. Split into 2 data items. Bottom two lines become "DSCP profile". "Here's a new credit window with new CID, it uses profile number x". Later introduce a new profile. Then switch a destination to the new profile.
Lou - Lots to consider now. Will write something down.
Issue A.4 - Absolute credit values vs increments. Currently there is a way to re-synchronize if the modem thinks the router is getting out of sync with its credit value when it responds. Stan's question was why don't we always do sets rather than increments. Some experimentation would be good to see if getting out of sync is an issue.
Stan - Alternatively, why don't we always use increments. More confusing to mix set and increment. 
Lou - eliminates possibility of doing a reset, or reducing the window.
Rob Hamilton - would you want to say sometimes we do absolutes and sometimes windows?
Lou - it does sometimes do both, modem controls it, we want to throttle what the router sends to the modem.
Skip A.5 on containers as already discussed.

Summary: Aiming for progress on these 4. Pause depends on container solution, and Credits draft has a lot of changes planned.

Rick - open question on container data item. Credit window extension had example of container. For the pause extension, the data item we can use as a container is a set of things, so Type, Length (n x single value length), followed by n values. In the credit window extension, it has header info. Data is associated with set as a whole.
Lou - Container gives processing scope, ordering. 
Rick - whole credit window data item could be a container.
Stan - generic container type in this case, inside it use a "credit window identifier" data item, followed by "initial credit window" data item. Container is then a wrapper around the data items.

Open mic:
Multicast FIBs - we need to bring some priority to this work in the IETF.
Justin - spoke to Sue Hares this week. Two drafts regarding RIBs. They do some of what we need a FIB to do for multicast in MANET. No duplicate packet detection. Not sure shoe-horning their solution in is the right approach, but we should definitely look at their good work.
Lou - could augment their models.
Routing area open meeting earlier - ROLL had AODV presented and was going to be referred to MANET. AODVv2 was declared dead for MANET. An individual submission exists. ROLL is chartered to do routing protocols and they have selected AODV. If we are asked to review, great. Don't need AODV arguments on MANET list.