Minutes IETF98: manet
minutes-98-manet-01

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.