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

[JP Vasseur <[e-mail]>]

Hi,


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

> 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.
> 
> 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,
> 
> Miguel Sánchez, PhD Associate Professor [phone]
> Computer Egineering Department (DISCA)
> Polytechnic University of Valencia, Spain
> 
> On 5/30/08, Jukka MJ Manner <[e-mail]> wrote:
>> 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
>>  
>>  JP Vasseur wrote:
>>>  > Hi,
>>>  >
>>>  >
>>>  > On 5/30/08 7:26 AM, "Jukka MJ Manner" <[e-mail]> wrote:
>>>  >
>>>>  >> Hi JP,
>>>>  >>
>>>>  >> Some answers below.
>>>>  >>
>>>>  >> Jukka
>>>>  >>
>>>>  >> JP Vasseur wrote:
>>>>>  >>> Hi Jukka,
>>>>>  >>>
>>>>>  >>>
>>>>>  >>> On 5/29/08 4:17 AM, "Jukka MJ Manner" <[e-mail]> wrote:
>>>>>  >>>
>>>>>>  >>>> [2nd try, 1st one bounced for some reason]
>>>>>  >>> 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.
>>>>  >>
>>>>>>  >>>> 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.
>>>>>  >>> 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, ....)
>>>>  >> 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.
>>>  >
>>>  > 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.
>>>  >
>>>>>  >>> (2) There is no issue in having some similar routing requirements
>>>>> spelled
>>>>>  >>> out in the IDs. This is a good news.
>>>>  >> 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.
>>>  >
>>>>>>  >>>> If we are to work on a solution later on, it is somewhat
>>>>>> challenging to
>>>>>>  >>>> 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 ?
>>>>  >> 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,
>>>  >
>>>  > 4
>>>  >
>>>  > so does that mean we need to interpret all three
>>>>  >> concurrently while drafting solutions? Reading a single list of
>>>>  >> requirements would be easier, IMHO.
>>>  >
>>>  > The super-set of requirements will be taken into account in the protocol
>>>  > survey and then protocol selection/design.
>>>  >
>>>>  >> 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.
>>>  >
>>>  > Ah so you saw some differences ....
>>>  >
>>>  >
>>>  > Then there are
>>>>  >> those performance requirements (see below).
>>>>  >>
>>>>>>  >>>> 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.
>>>>>>  >>>>
>>>>>  >>> 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.
>>>>  >> 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.
>>>  >
>>>  > This is the approach that we took. Note that other WGs took the same
>>>  > approach (e.g. PCE, ...) and have been very successful.
>>>  >
>>>>>  >>> 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.
>>>  >
>>>  > Please look around and you will see many requirements documents with RFC
>>>  > 2119 language.
>>>  >
>>>>>>  >>>> We need a separate document that lists the concrete goals of such a
>>>>>>  >>>> routing
>>>>>> subsystem/protocol/architecture/service/whateveryouwanttocallit.
>>>>>  >>> 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.
>>>  >
>>>  > No, the requirements will make use of the RFC 2119 language.
>>>  >
>>>>>>  >>>> 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).
>>>>>  >>> 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.
>>>>  >> 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?
>>>  >
>>>  > They are indicative.
>>>  >
>>>>>  >>> Of course, we will use performance related metric during our protocol
>>>>> survey
>>>>>  >>> evaluation.
>>>>  >> 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.)
>>>>  >>
>>>>>>  >>>> This latter document is used in both analysing the existing schemes
and
>>>>>>  >>>> drafting a potential solution.
>>>>>  >>> See
>>>>>  >>> 
>>>>> 
http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.txt
>>>>  >> Yes, I know the draft.
>>>>  >>
>>>>>  >>> 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.
>>>>>  >>> Absolutely.
>>>>>  >>>
>>>>>>  >>>> 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.
>>>>>  >>> Please elaborate.
>>>>  >> 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.
>>>  >
>>>  > 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.
>>>  >
>>  
>>  
>> --
>>  
>>  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: [e-mail]
>>  P.O. Box 3000, FIN-02015 TKK      WWW:    www.netlab.tkk.fi
>> <http://www.netlab.tkk.fi>
>>  Finland                           Private:+358+(0)50+320 3018
>>  
>> _______________________________________________
>>  Roll mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/roll
>>  
> 
> 

_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll