[Roll] Minutes of the Interim ROLL Working Group Meeting *and* WG consensus on the protocol survey conclusion

Dear WG,

Please find below the minutes of the ROLL Interim Working Group meeting that
was help in San Jose on Oct 6.

This was an excellent very productive meeting where we managed to make good
progress and reached a consensus on an important question related to a key
Milestone. As usual such consensus must be confirmed on the mailing list.

When ROLL got chartered, one of our key milestones was to determined after
some careful analysis of the routing requirements whether or not we could
find an existing protocols that would meet our routing requirement with no
change (with no protocol changes). All participants to the interim meeting
agreed that there was no existing protocol that would meet the ROLL routing
requirements *with no protocol work*. Do not hesitate to express your
opinion on the mailing list before Oct 17 and then we will document the WG
decision.

The next step will consist of identifying whether an existing protocol can
be adapted or a new protocol must be designed.

Minutes of the Roll Interim Working Group Meeting  October 6 - 2008

JP Opens Meeting

Update on status
 - 3 routing requirement IDs almost ready: Last call should be before
Minneapolis
 - Excellent progress on the building automation routing requirement ID

Milestones
 - Routing metrics due nov

Objective for today: Objective of draft-ietf-roll-protocols-survey is to
answer the following question: ³Do LLNs require a new protocol specification
document at all ?²
Need to reach a consensus on this first question.
Second Step: ³Do we need extensions to an existing protocol or a new
protocol?²

Phil Levis presents updated document

2. Draft Goal

David Meyer (DM): what about extension?
Phil Levis (PL): to address extensions still require recharter

David Culler (DC): If the conclusion from the small set of criteria is NO,
it is not required that the criteria be complete.  If the conclusion
is yes, additional criteria could be very relevant.

DM> Low pass filter, yes.
DC> Right.
JP> this is what we have been chartered to do.
P> These criteria are such that if not satisfied the protocol will not
satisfy any of the routing requirements document
Geoff> Does that mean w/o modification
P> Yes

3. Approach
 - Draft considers criteria that occur in every RR doc.
 - Mimimalist set
 - Evaluation based on asssement based on most generous implementation of
protocol published as RFC or ID

Geoff Mulligan (GM): does "most liberal" interpetation include extensions?
PT: NO.

4. Deriving the Criteria
 - ROLL ID indus, urban, home

Pascal Thubert (PT): can we leverage the routing requirement docs for next
stage design
 - the union is useful for later design stages

JP: The base reference for protocol extensions will be the routing
requirements documents, not this document.

Sumita: should we consider whether certain protocols are closest to meeting
the reqs'
JP: out of scope at this stage.  First need to answer YES/NO

5. Neccessary but not sufficient
 - example, indus includes latency criteria

DC: wording in section 4 should be Union

6. 5 Criteria

DM: Can we combine non-independent criteria
PTs: some of the combinations lose key info
DC: interrelations bring in external criteria, ex: stretch and table size

7. Evaluation

Pass / Fail / ?

JP> Are we clear on the criteria evaluation ?
All> Yes

Concensus on applying the assessment of the criteria

L - is degree, but not under our control, by contrast with ³traditional²
wired networks.

8. Table scalability

DC: Fail case needs to be omega
DC: do we need to establish some bounds on the constant
 - Meyer - establish a "currently in the following range"

Kris Pister (KT): how far do we need to go toward the aymptotic behavior.
How big an N do we need to consider?

PT: not acceptable to have hard limits - experience with the internet is
that scale extends beyond expected limits

DC: important that the fail/pass not be extremely sensitive to the constant
or the upper limit

Anand: Millions are not at all impractical today
JP: Referring to Smart meters ?
Anand: Yes

Discussion around how hierarchy of various sorts effectively limit the
scaling bounds in the analysis.

K> Can we pick a value for the RAM
JP> No, implementation dependent

9. Loss response

Communication cost of an actively used link experiencing loss?

Given that there is underlying link dynamics, what is the cost at the
routing protocol layer of the response.

10. Control Cost

Cost of maintenance of the topology.

PT: may have requirements to make sure the link is still there.
JP:  question about waste
DC: it needs to be unbounded relative to non-zero data rate
JP: In case of no traffic, a reasonable constant of control cost is
acceptable

Proposed change in wording - control cost unbounded by data traffic
plus an arbitrarily small constant

PT: lots of different sorts of beacons are possible

Extended discussion around capturing the need to have low beacon rates but
not
zero at very low data rate

JP: We need to find an agreement on the exact definition.

11. Link costs

Discussion of distinct kinds of links.  Fail criteria is a lower bound

12. Node cost

JP> Be careful, some protocol allows for cost metrics but no node attributes
to be taken into account.

----------------------------------------------

JP> RIP Control cost should be a pass with triggered RIP.

With the modification of the control cost criteria, the one entry that
changes in the table is RIP control cost (triggered RIP) becomes a
pass.  

DM: But it may not converge when it is cranked down.

More careful analysis of RIP node cost downgraded that to a fail.

----------------------------------------------

Consensus that the answer to the main question is NO.

A new revision of the protocol survey that reflects the discussion during
the Inteirm meeting where a few changes have been requesting has been
posted: 
http://www.ietf.org/internet-drafts/draft-ietf-roll-protocols-survey-02.txt

Thanks.

JP and David.