Subject: [Roll] Some thoughts on the requirements documents [2nd try]

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 29 May 2008 11:17:06 +0300

[2nd try, 1st one bounced for some reason]

Hi

I went through the various requirements documents and I'm a bit puzzled.
In general the drafts are easy to read and we have many interesting
scenarios described that open up nicely the environment. Yet, the drafts
list similar requirements, there is very little difference in what they
expect the routing service to do.

If we are to work on a solution later on, it is somewhat challenging to
find out the what our goals truly are.

IMHO, the requirements documents should focus on the scenarios and use
cases of sensor networks, and list in general what the routing subsystem
aught to do. These drafts should not use RFC 2119 language.

We need a separate document that lists the concrete goals of such a
routing subsystem/protocol/architecture/service/whateveryouwanttocallit.
Here there is also a clear need to separate functional and performance
requirements. Typically performance values and goals are mutually
exclusive, e.g., we can't have low power and high performance at the
same time (with some definition of what is low and what is high).

This latter document is used in both analysing the existing schemes and
drafting a potential solution. I would expect that we end up with one
general solution, where the parameters can be tuned to certain direction
to make it fit different use cases.

Actually, we also need to document the threats we see in the
environment, and focus on the routing subsystem. The current drafts have
some thoughts about that, but its only a beginning.

Regards,
Jukka
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Thu, 29 May 2008 11:24:30 -0400

Hi Jukka,

> [2nd try, 1st one bounced for some reason]

You need to subscribe to the list.

> expect the routing service to do.

Two comments here:
(1) I think that there are significant differences between the requirement
set forth in the IDs, in term of functionality (e.g. constrained based
routing, scale, ....)
(2) There is no issue in having some similar routing requirements spelled
out in the IDs. This is a good news.

> find out the what our goals truly are.

Sounds fairly obvious to me. How can you select/define a solution w/o
knowing what the requirements are ?

> aught to do. These drafts should not use RFC 2119 language.

No. "Requirements" and "Use cases" (what we usually call "Applicability
statement" at the IETF) have very different purposes and what we need to do
according to our charter is first to spell out the requirement documents.

Note that RFC 2119 is very much appropriate in requirement documents.

> routing subsystem/protocol/architecture/service/whateveryouwanttocallit.

Not sure what you mean here.

> same time (with some definition of what is low and what is high).

One of the key reasons why the Internet has been so successful is that we
avoid to specify performances, so I disagree with your vision here.

Of course, we will use performance related metric during our protocol survey
evaluation.

> drafting a potential solution.

See 
http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt

I would expect that we end up with one
> to make it fit different use cases.

Absolutely.

> some thoughts about that, but its only a beginning.

Please elaborate.

Thanks.

JP.

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 30 May 2008 08:26:44 +0300

Hi JP,

Some answers below.

Jukka

> You need to subscribe to the list.

I quite well know, thanks - I've been hanging around in the IETF for 
quite some time. And I was subscribed on the list, too.

> set forth in the IDs, in term of functionality (e.g. constrained based

To me the documents looked, in terms of _requirements_ very, very 
similar. Sure, there are small differences, but most of the things are 
the same.

> out in the IDs. This is a good news.

The point is: what is the value of saying similar things many times?

> knowing what the requirements are ?

The point was that the current drafts talk about usecases and list
requirements in a mixed way, and repeat the same things. For the work to
proceed, we eventually need to gather a single set of requirements, in
particular to make the work more focused. The WG charter lists three
usecase/reqs drafts, so does that mean we need to interpret all three
concurrently while drafting solutions? Reading a single list of
requirements would be easier, IMHO.

E.g., one draft says we need to support couple hundred nodes, another 
one says we need to support couple thousand, one drafts says we could 
support multicast, another says that multicast is a must. Then there are 
those performance requirements (see below).

> according to our charter is first to spell out the requirement documents.

The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN,
6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one
requirements/goals document describing in a single place what the work 
is tackling. Roll has 3 documents, it doesn't make it any simpler for an
outsider, or probably even the WG, to figure out the requirements of the
work.

> Note that RFC 2119 is very much appropriate in requirement documents.

RFC2119 only talks about language issues, it doesn't tell how one should
present requirements.

> Not sure what you mean here.

Use the current drafts as the use cases for Roll (without RFC2119 
language). Then take out the requirements, use RFC2119 language and 
formulate a single document that can then be used to steer the design of 
a solution.

> avoid to specify performances, so I disagree with your vision here.

I kinda know that... Again, the point is that the drafts already do 
that, i.e., they specify absolute performance values to be achieved. I 
don't want to have strict performance values, but the WG documents 
already do that. Should these then be taken out from the existing drafts?

> Of course, we will use performance related metric during our protocol survey

If the various WG requirement documents list performance values, then 
the WG must achieve those. (I would expect an eventual AD and/or IESG 
review to ask you to remove those performance requirements, though.)

> http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt

Yes, I know the draft.

>> some thoughts about that, but its only a beginning.

Well, the industrial use cases draft already talks about trust issues 
and compartmentalizing things. The urban reqs also hints at some threats 
that would be present in that environment. The home reqs doesn't list 
any, yet. Several WGs have a separate document that highlights the 
threats, c.f. RFC4081 or RFC4832.

Maybe I'm just the only one having difficulty in seeing where the work 
of the WG as a whole is going and what the goals are. In that case you 
can just neglect my questions and suggestions.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Fri, 30 May 2008 09:47:38 +0200

Hi,

> similar. Sure, there are small differences, but most of the things are

Just to take one example, the specification of a routing protocol for a few
dozen of nodes (Home Automation) and several hundreds of thousands (urban
networks) is not exactly the same and has strong implications on the design.

> The point is: what is the value of saying similar things many times?

Please look at the history of the WG. We decided to be application driven.
Thus the task consists of analyzing the routing requirements of (in our
case) 4 applications. If it turns out that several applications have similar
requirements, this is a perfectly good outcome, that will simply the task of
the WG to select or specify a new WG.

> usecase/reqs drafts,

4

so does that mean we need to interpret all three
> requirements would be easier, IMHO.

The super-set of requirements will be taken into account in the protocol
survey and then protocol selection/design.

> support multicast, another says that multicast is a must.

Ah so you saw some differences ....

Then there are 
> outsider, or probably even the WG, to figure out the requirements of the

This is the approach that we took. Note that other WGs took the same
approach (e.g. PCE, ...) and have been very successful.

> RFC2119 only talks about language issues, it doesn't tell how one should

Please look around and you will see many requirements documents with RFC
2119 language.

> formulate a single document that can then be used to steer the design of

No, the requirements will make use of the RFC 2119 language.

> already do that. Should these then be taken out from the existing drafts?

They are indicative.

> can just neglect my questions and suggestions.

All comments are most welcome. But indeed, I haven't received any other
similar complaints. This is indeed quite the opposite with many comments
from regular contributors finding that the WG formed a few months ago was
moving fairly quickly. There is still quite some work on the requirements
IDs but we're getting close to our Milestone.

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 30 May 2008 11:16:02 +0300

Hi JP,

Don't get me wrong, I'm not complaining as you seem to think. 
Application driven approach is fine. I'm trying to understand how four 
sets of requirements (in the broad sense incl. security), partly 
mutually excluding, are used in the future. Is the WG in fact going 
towards 4 distinct parallel tracks in the survey, and specification of 
the architecture? So it is a non-goal to have a unified vision of how 
routing in sensor networks in the broad sense should perform.

Regards,
Jukka

-- 

Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Fax:    +358+(0)9+451 2474
Department of Communications      Office: E309 (Otakaari 5)
and Networking                    E-mail: [email-masked]
P.O. Box 3000, FIN-02015 TKK      WWW:    www.netlab.tkk.fi
Finland                           Private:+358+(0)50+320 3018
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Miguel Sanchez" <[email-masked]>
Date: Fri, 30 May 2008 21:07:22 +0200

Hi Jukka,

I can see how different set of requirements may make a single workable
solution impossible. Having four application scenarios does not mean that 4
different protocols will be needed but we may end up with more than one
though.

If we look at the Internet routing we can see that several protocols are
being used.

Kind regards,

Miguel Sánchez, PhD Associate Professor +349638779709
Computer Egineering Department (DISCA)
Polytechnic University of Valencia, Spain

On 5/30/08, Jukka MJ Manner <[email-masked]> wrote:
> >>>> routing
> subsystem/protocol/architecture/service/whateveryouwanttocallit.

---

From: JP Vasseur <[email-masked]>
Date: Sat, 31 May 2008 14:24:30 +0200

Hi,

On 5/30/08 10:16 AM, "Jukka MJ Manner" <[email-masked]> wrote:

> the architecture?

No, the survey will look take into account all the requirements spelled out
in the 4 requirement documents. And of course, the architecture ID and
potential protocol work will not have parallel tracks.

So it is a non-goal to have a unified vision of how
> routing in sensor networks in the broad sense should perform.

This only place whether we'll have parallel "tracks" is for the routing
requirements, which makes sense by essence.

Thanks.

JP.

>>>>> drafting a potential solution.
http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.tx>>>>
t

---

From: JP Vasseur <[email-masked]>
Date: Sat, 31 May 2008 14:56:26 +0200

Hi,

On 5/30/08 9:07 PM, "Miguel Sanchez" <[email-masked]> wrote:

> JP> Absolutely as long as we carefully document the applicability but this is
> premature to discuss this until we have converged on the protocol survey. Note
> that we, as a WG, may also agree to not meet all requirements if some of them
> require to add unreasonable weight/overhead to the protocol.
> 
> If we look at the Internet routing we can see that several protocols are being
> used.
> 
> JP> But this is slightly different though. You do not use more than one IGP at
> the same time in the same region (unless in very specific conditions such as
> network migration). Further, you always try to avoid using routing at multiple
> layers with cross layer violation, which we must avoid.
> 
> Thanks.
> 
> JP.
> 
> Kind regards,
> 
>> <http://www.netlab.tkk.fi>