Subject: Re: [manet] Path Accumulation in DyMO

From: Charlie P <[email-masked]>
Date: Fri, 19 Nov 2004 11:56:29 -0800

Hello Luke,

Luke Klein-Berndt wrote:

>Right now it is clear that having Path Accumulation information would be
>valuable, but it isn't completely clear how it can be best used right
>now. There are some scenarios were the might be gains from having the
>additional destinations along a route, but there are some scenarios,
>such as high mobility, where those additional destinations could be
>stale leading to short lived routes.
>  
>
The reason for standardizing is to maximize interoperability, and
here we can see clear benefits from mandating path accumulation:
- simpler data structure overall
- probably less congestion under a majority of the circumstances
- enables simpler computation at each node wishing to use the data
- decrease substantially the need for reverse route maintenance
   and timeout.  But, note that the code for those operations is
   still needed.  It just doesn't need to be exercised very often.
- etc., as mentioned in other emails.

Consider the implementation complexity.  Roughly speaking, it boils
down to copying a list and extending it by (sizeof IP_address).
That's not too bad.  Plus, a conformant IP stack already has to
perform a more difficult similar task in order to implement the
source routing options for IPv4 and the analogous header for
IPv6.  I don't see implementation as a difficulty unless you also
wanted to fudge the IP header processing itself (eek!!).

Maybe more serious is the limitation on message size which
would be imposed by a goal to avoid fragmentation.  For IPv4,
this doesn't seem to be too serious unless we are dealing with
large node populations.  In fact, I think there is a solution that
does not add very much code on top of what is already required,
but there's no need to discuss that until we decide one way or
the other.  If the decision turns out to rest on code complexity,
then I'll formulate another message about such a potential
solution.

If you believe the above, then the bottom line is that if we
do NOT mandate path accumulation, you _still_ don't get
any extra sleep.  And who knows, maybe we would all
lose sleep over failure to do the right thing (just kidding!).

Overall, I am much in favor of mandating path accumulation,
but not at the risk of deraiiling the specification effort.

Regards,
Charlie P.

>If the standard is going to be deployed I don't think we should add a
>feature because it could be interesting, we should add it because it
>provides known gains. The is especially true if it takes away from an
>existing feature like simplicity.
>
>Here is what I would do: Leave path accumlation of the Standard for
>DyMO. Carfully define the extension section of DyMO, so that it can
>handle things like Path Accumulation Extensions. It is also important to
>define how DyMO should handle extensions it doesn't know, ie probably
>just ignoring them. This would it easier for industry to create DyMO
>Standard based products. Exstensibility would also allow researchers to
>create extensions like Path Accumulation or newer un-thought-of
>improverment with existing products. 
>
>I definitely think that we should either have every node use Path
>Accumulation or not. Otherwise the value of Path Accumulation gets
>deluted and the algorithm for building a route gets less fun.
>
>Basically I am lazy would rather not implement things that are not going
>to improve functionality. We have all done a lot of research in this
>field, and if we don't have a clear reason for including something in
>the standard, it might not belong... but as per my previous sentence, I
>would also make my life easier :) 
>
>- Luke Klein-Berndt
>
>
>
>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] 
>>On Behalf Of Ian Chakeres
>>Sent: Thursday, November 18, 2004 3:34 PM
>>To: Charles E. Perkins; Thomas Heide Clausen; 'manet'; Justin Dean
>>Subject: Re: [manet] Path Accumulation in DyMO
>>
>>
>>First I want to issue a query to the list.  Does anyone think 
>>we should 
>>use path accumulation to alleviate creating a reverse route to the 
>>source during RREQ propagation? I'd like to get consensus 
>>that this is 
>>a non-issue.
>>
>>Given that we don't perform path accumulation for the reason of not 
>>storing the reverse route during RREQ propagation, I think 
>>there are a 
>>large number of possibilities for disseminating additional 
>>information. 
>>For example, we could include each node on the path, and 
>>their sequence 
>>number. Alternatively we could create a more modular option 
>>that allows 
>>us to include only some nodes on the path. Or even more versatile a 
>>method to disseminate routes that are not on the RREQ/RREP path (i.e. 
>>gateways). It could even carry additional information, hop count, 
>>metric, security information, etc...
>>
>>Given all these choices I would prefer to leave this as an open issue 
>>pending experimentation, instead of attempting to specify the 
>>"way" to 
>>do it in the base spec.  Obviously we could do both, specify one way 
>>and allow additional options for others.  I'm open to that 
>>option also.
>>
>>Does anyone have a feeling as to what if any technique should be 
>>included in the base specification but not mandated? What information 
>>should be disseminated?
>>
>>Thanks.
>>Ian Chakeres
>>
>>On Nov 18, 2004, at 5:11 AM, Thomas Heide Clausen wrote:
>>    
>>
>>>Ian,
>>>
>>>I am still of the general opinion that leaving an option unspecified
>>>is a
>>>bad thing, assuming that it's an option which (i) a plurality of
>>>deployments might use and (ii) where different 
>>>approaches/implementations
>>>might impair interoperability.
>>>
>>>What's the general observations on (i) and (ii) regarding
>>>path-accumulation?
>>>
>>>--thomas
>>>___
>>>Sent with SnapperMail
>>>www.snappermail.com
>>>
>>>...... Original Message .......
>>>On Fri, 12 Nov 2004 06:59:15 -0500 Ian Chakeres <[email-masked]>
>>>wrote:
>>>      
>>>
>>>>At the MANET meeting I presented DyMO (Dynamic MANET On-demand 
>>>>Routing Protocol).  My slides from the presentation are 
>>>>        
>>>>
>>available at 
>>    
>>
>>http://moment.cs.ucsb.edu/~idc/pub/chakeres_ietf61_presentatio
>>    
>>
>n.pdf.
>  
>
>>>There was a short discussion about using path accumulation in the 
>>>base specification.  Most people expressed their feelings that path 
>>>accumulation is useful for additional route information 
>>>dissemination. I believe there was consensus to not include path 
>>>accumulation in the core spec though it should definitely be included
>>>      
>>>
>
>  
>
>>>as an optimization. If you disagree, lets discuss it more on the 
>>>list.
>>>
>>>Thanks.
>>>Ian Chakeres
>>>
>>>
>>>_______________________________________________
>>>manet mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/manet
>>>
>>>      
>>>
>
>
>_______________________________________________
>manet mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/manet
>
>
>
>  
>

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Justin Dean <[email-masked]>
Date: Fri, 19 Nov 2004 16:11:17 -0500

One big issue that may be some cause for concern when using path accumulation
is security.  By allowing packet modification a single compromised node can 
cause
quite a bit of havoc throughout the network.  I am not saying that it can 
not be done
only that it seems to me to be inherently less secure than not having 
accumulation.

As a routing person path accumulation is the way to go because of the 
reasons Charlie
mentioned as well as others.  Looking at it in terms of security/deployment 
person
no path accumulation should be safer.

Because I am more of a routing person I want path accumulation; there is 
just so much more
information to work with by using it.  As for Ian's question of what should 
be included in the
base specification.  I would propose a modular information field, which 
could be turned on
using some bytes in the header.  The actual information field containing a 
type field and a
value field. (with a bit reserved in the type field for continuation, ie 
next 32 bits is another value
field not an address)  Other than defining the fields I don't think 
anything further should be
included in base specification. Let types be defined by later options 
specifications. I also think
default mode of operation should just be addresses.

The above idea along with storing link information could be used to 
compress packets which
are in danger of becoming too large.  By removing a bunch of path 
information recording it locally
and putting in a value field with the corresponding hop count between end 
points that were not removed.
On return trip the information could be added back into the packet.

Justin Dean

At 11:56 AM 11/19/2004 -0800, Charlie P wrote:

>>>From: [email-masked] [mailto:[email-masked]] On Behalf 
>>>Of Ian Chakeres
>>>First I want to issue a query to the list.  Does anyone think we should 
>>>source during RREQ propagation? I'd like to get consensus that this is a 
>>>non-issue.
>>>
>>>storing the reverse route during RREQ propagation, I think there are a 
>>>large number of possibilities for disseminating additional information. 
>>>For example, we could include each node on the path, and their sequence 
>>>number. Alternatively we could create a more modular option that allows 
>>>pending experimentation, instead of attempting to specify the "way" to 
>>>do it in the base spec.  Obviously we could do both, specify one way and 
>>>allow additional options for others.  I'm open to that option also.
>>>
>>>>deployments might use and (ii) where different approaches/implementations
>>>>>At the MANET meeting I presented DyMO (Dynamic MANET On-demand Routing 
>>>>>Protocol).  My slides from the presentation are
>>>available at
>>>
>>>>There was a short discussion about using path accumulation in the base 
>>>>specification.  Most people expressed their feelings that path 
>>>>accumulation is useful for additional route information dissemination. 
>>>>I believe there was consensus to not include path accumulation in the 
>>>>core spec though it should definitely be included
>>>>
>>
>>
>>
>>>>as an optimization. If you disagree, lets discuss it more on the list.
>>>>
>>>>Thanks.
>>>>Ian Chakeres
>>>>
>>>>

---

From: "Luke Klein-Berndt" <[email-masked]>
Date: Fri, 19 Nov 2004 16:26:18 -0500

Hi Charlie,
	I think my basic feeling is that we should either mandate Path
Accumulation for all nodes or not include it. Making it optional, where
only some nodes would add themselves to the list, would make it more
complex to implement and take away from some of its usefulness. 

	To me it seems like performance wise they would be roughly equal
on average, and since they are about the same to implement, I think
either method would work. I do agree that Path Accumulation does have
advantages. One of them is that it delivers more information, of course
more information does mean that the packets are bigger. If stratigies
for handling routes that are too large for a packet was kept simple or
put in another document, I would be for path accumulation. It might also
turn out that you don't want to be building routes that are too long to
fit inside a packet. There might end up being a relation between maximum
packet size and the maximum length of a reliable route.

	I am happy with either method. I think the Path Accumulation
should be used for building routes instead of an option used to
gathering more information. My main concern is just keeping the base
standard straight forward and relativly easy to follow. The less
conditional cases the better!

-Luke Klein-Berndt

> From: Charlie P [mailto:[email-masked]] 
> Sent: Friday, November 19, 2004 2:56 PM
> To: Luke Klein-Berndt
> Cc: 'manet'
> >Right now it is clear that having Path Accumulation 
> information would 
> >be valuable, but it isn't completely clear how it can be best used 
> >right now. There are some scenarios were the might be gains 
> from having 
> >the additional destinations along a route, but there are some 
> >scenarios, such as high mobility, where those additional 
> destinations 
> >could be stale leading to short lived routes.
> >  
> >
> The reason for standardizing is to maximize interoperability, 
> and here we can see clear benefits from mandating path accumulation:
>    stil needed.  It just doesn't need to be exercised very often.
> Consider the implementation complexity.  Roughly speaking, it 
> boils down to copying a list and extending it by (sizeof 
> IP_address). That's not too bad.  Plus, a conformant IP stack 
> already has to perform a more difficult similar task in order 
> to implement the source routing options for IPv4 and the 
> analogous header for IPv6.  I don't see implementation as a 
> difficulty unless you also wanted to fudge the IP header 
> processing itself (eek!!).
> 
> this doesn't seem to be too serious unless we are dealing 
> with large node populations.  In fact, I think there is a 
> solution that does not add very much code on top of what is 
> already required, but there's no need to discuss that until 
> we decide one way or the other.  If the decision turns out to 
> rest on code complexity, then I'll formulate another message 
> about such a potential solution.
> 
> >handle things like Path Accumulation Extensions. It is also 
> important 
> >to define how DyMO should handle extensions it doesn't know, ie 
> >probably just ignoring them. This would it easier for industry to 
> >create DyMO Standard based products. Exstensibility would also allow 
> >researchers to create extensions like Path Accumulation or newer 
> >un-thought-of improverment with existing products.
> >
> >Basically I am lazy would rather not implement things that are not 
> >going to improve functionality. We have all done a lot of 
> research in 
> >this field, and if we don't have a clear reason for 
> including something 
> >in the standard, it might not belong... but as per my previous 
> >sentence, I would also make my life easier :)
> >
> >- Luke Klein-Berndt
> >
> >
> >
> >  
> >
> >>>is a bad thing, assuming that it's an option which (i) a 
> plurality of