Subject: [manet] COmments on DYMO draft

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 09 Mar 2005 18:28:41 -0800

Hello Ian/Charlie/Elizabeth:

I have read the DYMO draft. I have some editorial comments on the draft.
I am not sure if similar comments are already discussed in the mailing
list.

Thanks,
-Samita

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

Overall:

Since the draft is targetting a standard track document, it will benefit
from a clearer introduction.

Currently, it seems this document assumes that the reader is already 
familiar with
AODV and other reactive protocols; instead it will be beneficial to the 
reader
if the introduction provides a bit of analysis describing how this draft is
more applicable than AODV or DSR or other reactive MANET protocols.
At least a separate section on describing how this draft is different 
from AODV
experimental RFC, will be very helpful.

Then a clearer description of the protocol overview is necessary in a 
nutshell.

For example, in introduction it talks about RERR, but no mention of RREQ 
or RREP.
Please add RERR, request/reply acronyms in the Terminology section.

Also please describe the "loop" problem and how DYMO solves that. The 
one line
mention in the introduction is not enough. There are lot of information 
in the
draft, but I failed to co-relate them without getting confused. A 
general description
of  ' which element is doing what' is very important for the reader to 
understand - perhaps
a flow-chart or state diagram would be helpful.

"Unsupported Extensions" naming is very confusing - can we call then as 
"Future extensions"
or something else to indicate that these can be used later for future usage.

The abstract talks about "It offers quick adapatation to dynamic 
conditions, low processing
and memory overhead, low network utilization". But in the body of the 
document, there is
no specific paragraph or section to address each of those claims made above.

section 2.

IPBroadcastAddress:

I don't know of any IPv6 broadcast address. I have checked the ADDRARCH 
document,
but it only talks about unicast and multicast. Is MANET introducing a 
new broadcast
mechanism in IPv6?  My impression was that IPv6 wanted to get rid of 
Broadcast addr.

MANETcast
 This definition is quite vague. I don't understand this address scope.

Section 3 and 4:
Please describe the Detailed Operation and meaning of different data 
structure
elements before laying out the section 3.

Section 3.3 provides field descriptions - but they are very difficult to 
co-relate
with the corresponding field definitions.

Thus, I suggest please have some text describing the Routing table 
entry  and please
provide description of each field under each structure definition.

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

---

From: Ian Chakeres <[email-masked]>
Date: Wed, 9 Mar 2005 20:37:28 -0600

Thank you very much for your comments. We are working hard on dymo-01 
based on all the comments we have received. It should be ready in less 
than a month. Several of your comments have already been addressed in 
the working document.

Thanks.
Ian Chakeres

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 10 Mar 2005 11:44:14 +0900

Hi Samita and Ian

> section 2.
>
> IPBroadcastAddress:
>
> I don't know of any IPv6 broadcast address. I have checked the 
> ADDRARCH document,

This is right observation, however we can always use multicast as a 
broadcast address.
For example, ff02::1 can be used as an limited broadcast address for 
one-hop neighbors.

> This definition is quite vague. I don't understand this address scope.

Is this question from where is MANET edge.
IMO, If there is no clear definition of that, it's hard to define 
MANETcast.

ryuji

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 09 Mar 2005 19:13:31 -0800

> For example, ff02::1 can be used as an limited broadcast address for 

Right, we can use ff02::1 ( all-node multicast  in a link) for the 
single hop, then  I assume the
adhoc network forwarder(s) at the edge of the link  could forward again 
to the other side
of link as all-node multicast address and so on.  But I was  wondering 
if  it is possible to
use  a designated multicast address for this purpose.  All  nodes in the 
adhoc  or mesh
network MAY not  be a forwarder or router.  So, those nodes  that are 
capable of  forwarding
and routing packets should join a multicast address.  This will  avoid  
sending more packets
than necessary.  If  we want to include LowPAN  or sensor nodes,  not 
all  nodes are capable
of forwarding packets . Since they are low-powered and  sleep off and 
on, we don't want to
wake them up  by sending broadcast packets to everyone.

Thanks,
-Samita

---

From: Ian Chakeres <[email-masked]>
Date: Wed, 9 Mar 2005 21:19:20 -0600

Our definition of MANETcast is an attempt to be general enough to allow 
an implementation to choose another multicast address to deliver DYMO 
packets, if or when one becomes available.

Ian Chakeres

On Mar 9, 2005, at 9:13 PM, Samita Chakrabarti wrote:
>>> but it only talks about unicast and multicast. Is MANET introducing 
>>> a new broadcast
> adhoc network forwarder(s) at the edge of the link  could forward 
> again to the other side
> use  a designated multicast address for this purpose.  All  nodes in 
> the adhoc  or mesh

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 10 Mar 2005 13:35:04 +0900

Hi Samita

You can use flooding (MPR) with ff02::2 :-)

ryuji

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 10 Mar 2005 19:37:24 -0800

Hi Ryuji,

Below, I did not recommend ff02::2. 

Rather, I was  suggesting a designated multicast address.

Thanks,
-Samita

Ryuji Wakikawa wrote:

>>>> mechanism in IPv6?  My impression was that IPv6 wanted to get rid 
>>>> of Broadcast addr.
>>>
>>>
>>>
>> of link as all-node multicast address and so on.  But I was  
>> wondering if  it is possible to
>> and routing packets should join a multicast address.  This will  
>> avoid  sending more packets

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 10 Mar 2005 19:47:59 -0800

Ian Chakeres wrote:

> Our definition of MANETcast is an attempt to be general enough to 
> allow an implementation to choose another multicast address to deliver 
> DYMO packets, if or when one becomes available. 

Hi Ian,

As it was pointed out in the meeting today that the danger of 
underspecifying and leaving it up to
the implementors would  lead to interop problem. Designated multicast 
address seem to be the
right thing.

Thanks,
-Samita