Subject: Fwd: Re: Routing Directorate Review Comments on draft-ietf-manet-tbrpf-08.txt

From: mike shand <[email-masked]>
Date: Tue, 13 May 2003 07:39:28 +0100

>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]
>------------------------

---

From: Alex Zinin <[email-masked]>
Date: Fri, 16 May 2003 22:10:35 -0700

Mike, Joe, Scott-

 Could you guys pls send a message to the WG with
 the comments that Mike sent and the follow-ups?

 Thanks.

-- 
Alex
http://www.psg.com/~zinin/