Subject: [manet] FW: : Re: Routing Directorate Review Comments on draft-ietf-mane t-tbrpf-08.txt

From: Scott Corson <[email-masked]>
Date: Sun, 18 May 2003 07:16:03 -0400

Folks,

FYI... here are some comments on TBRPF from its Routing Directorate review
and a corresponding response.  Some of the items have more general
applicability.

Cheers,

-Scott

Monday, May 12, 2003, 11:39:28 PM, mike shand wrote:

>>To: mike shand <[email-masked]>
>>cc: [email-masked], [email-masked], [email-masked],
>>         Joseph Macker <[email-masked]>,
>>         Scott Corson <[email-masked]>
>>Reply-To: [email-masked]
>>From: [email-masked]
>>Subject: Re: Routing Directorate Review Comments on 
>>draft-ietf-manet-tbrpf-08.txt
>>Date: Mon, 12 May 2003 12:54:09 -0700
>>Sender: [email-masked]
>>
>>
>>Hello Mike,
>>
>>Thank you for comments/questions.  I have discussed them with
>>Mark Lewis and Fred Templin.  Please see our responses below.
>>
>> > I am conducting a routing directorate  (rtg-dir) review of this draft,
and
>> > I have a few (relatively trivial) comments/questions. I would be
grateful
>> > for your responses.
>> >
>> >       Mike Shand
>> >
>> >
>> >
>> >
>> > 1. Introduction
>> >
>> >       The term "proactive routing protocol" has a specific meaning 
>> within the
>> > MANET context. It might be useful for readers unfamiliar with the
concept
>> > to give a brief definition in the "terminology" section.
>>
>>We can add the following definition:
>>
>>  Proactive routing protocol
>>     A routing prototocol in which each node maintains routes to all 
>> reachable
>>     destinations at all times, whether or not there is currently any need
to
>>     deliver packets to those destinations. In contrast, an "on-demand" 
>> routing
>>     protocol discovers and maintains routes only when they are needed.
>>
>> >
>> > 4. Applicability Section
>> >
>> > Is there some evidence to support the claim "it can support networks
with
>> > up to a few hundred nodes".?
>> > e.g. that is the design scope, or simulations and or implementations
>> > support this.
>>
>>We can change this to the following:
>>
>>   Simulations have shown that TBRPF can support up to 250 nodes
>>   in mobile networks using IEEE 802.11 with a data rate of 2 Mbps.
>>   The number of nodes that can be supported depends on several factors,
>>   including the data rate, the rate of topology changes, and the network
>>   density (average number of neighbors)."
>>
>> > 5.1 Overview of neighbor discovery
>> >
>> > There seems to be an inconsistency in the use of MUST/MAY in this
section
>> > (and possibly in other sections as well).
>> >
>> > In para 7 "must" appears uncapitalized. This seems reasonable, given
that
>> > this is just an overview.
>> >
>> > However, in the last para we have "MAY".
>>
>>We will change this so that only lower case "must"s and "may"s are used in
>>the overview section.  There is another "MAY" in Section 5.2 (Overview of
>>Routing) that will also be changed to lower case.
>>
>> > 6.1 TBRFP Packet header
>> > F- flag extension. Should it say that when using F to insert single
octet
>> > of padding, the flag extension bits MUST be zero?
>>
>>OK, we will change this to make it clear.
>>(However, I think it is already implied.)
>>
>> > C- Checksum included.
>> > The phrase "a 16 bit checksum beginning in the first octet of the
header
>> > extension" is ambiguous, since it is not (yet) clear whether the
>> > "beginning" refers to the data over which the checksum is calculated,
or
>> > the location of the computed checksum. Subsequent text reveals that it
is
>> > the latter, but this could be made clear by saying something like
>> >
>> > "a 16 bit checksum in the first two octets of the header extension".
>>
>>OK. We will use your suggested wording.
>>
>> > Also, this mechanism means that a single bit error (clearing the C bit)

>> can
>> > result in undetected corruption. Note that in this case the 16 bits of
>> > checksum will be interpreted as something else. Is that a concern?
>>
>>Good point. We can fix this by eliminating the C bit and always including
>>the checksum.
>>
>> >
>> > 6.2 TBRPF Packet Body
>> >
>> > This use of TLVs is somewhat strange. Normally the L field is always
>> > present immediately after the T field and hence a new (and not
recognized)
>> > type can be introduced, such that it is simply parsed over and ignored.
>> > This cannot be done with the proposed structure. IPv6 option TLVs DO
have
>> > the normal property. It is probably confusing to call the TBRPF 
>> messages TLVs
>>
>>Good point.  We will remove the reference to TLV.  I think this was left
>>over from a previous version of TBRPF that included the L field.
>>We omitted the L field in order to minimize overhead, which is an
>>important objective for MANETs.
>>
>> > The draft doesn't say what to do with non-recognized type values. Drop
the
>> > packet?
>>
>>Yes, we will add that no further messages in the packet are to be
>>processed when a non-recognized type is encountered. (Since messages
>>are processed in order, this still allows new types to be introduced
>>in future versions, as long as new message types are placed after
>>old message types in a given packet.)
>>
>> >
>> > 6.2.1 Padding Options
>> >
>> > Senders MAY
>>
>>OK.
>>
>> > Is the use of the F bit to insert a one octet pad redundant  because of

>> the
>> > existence of the Pad1 option? Or are the two intended to serve
different
>> > purposes. (the former inserts padding prior to the length and router ID
>> > header extensions). It seems odd to have TWO mechanisms to achieve the 
>> same
>> > ends.
>>
>>You are correct that the two mechanisms are intended to serve different
>>purposes, since the Pad1 option cannot be used to separate the first
>>octet of the header from any header extensions that follow.
>>
>> >
>> > 7.8 Configurable parameters.
>> >
>> > MAX_JITTER Jitter is usually expressed as a percentage, not an absolute
>> > value, and value of 25% is typical. Is there a particular reason for
>> > specifying it this way?
>>
>>I have seen it both ways.  Is there a good technical reason for using
>>percentage instead of an absolute value?
>>Can you give me a well-known reference that uses percentage?
>>
>>It seems to me that the amount of jitter required to avoid collisions is
>>best expressed as an absolute value (e.g., 0.1 sec), which does not depend
>>on the HELLO interval.
>>
>>One reason for not expressing it as a percentage is that this might
>>unintentionally imply that it is OK, for example, to reduce the HELLO
>>interval from 1 sec to .1 sec while keeping the jitter at 10%.
>>(10% would be OK for 1 sec but is probably too small for .1 sec.)
>>
>>Also, a larger jitter increases overhead (since it is subtracted and 
>>therefore
>>results in more frequent messages) so we want to keep it at a minimum.
>>For example, we would not want to use .25 sec if .1 sec is sufficient.
>>
>> >
>> > 10.6 Support for nonMANET Hosts
>> >
>> > Should there be a section about how a TBRPF domain interfaces with the
>> > internet at large? Are there any special considerations?  Or is
everything
>> > which needs to be covered dealt with in section 10.5?
>>
>>Note that Network Prefix messages are described in in detail Section 8.
>>(Section 10.5 discusses how these messages might be used in MANETs.)
>>
>>We believe that anything beyond this is beyond the scope of the document
>>(e.g., how to obtain a global address from a gateway or the use of mobile 
>>IP).
>>We do note in Section 8.1 that gateway routers can advertise default 
>>prefixes.
>>If you think it would help, we could explain more clearly (in a few
sentences)
>>that gateway routers can be used to provide Internet connectivity and that
>>they can use Network Prefix messages to advertise external prefixes to the
>>MANET nodes.
>>
>> >
>> > That's all I have. I haven't reviewed the protocol specification for
>> > correctness. I assume the authors and WG have already done that:-)
>> >
>>
>>-----------------------
>>Richard Ogier
>>Sr. Research Engineer
>>SRI International
>>333 Ravenswood Ave.
>>Menlo Park, CA 94025
>>Tel: 650-859-4216
>>Fax: 650-859-4812
>>Email: [email-masked]
>>------------------------
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet