[Manet-dt] Re: DYMO SeqNum Decisions

"Charles E. Perkins" <charles.perkins@nokia.com> Fri, 25 August 2006 22:22 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGk4T-0007gm-F5; Fri, 25 Aug 2006 18:22:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGk4R-0007gh-MR for manet-dt@ietf.org; Fri, 25 Aug 2006 18:22:35 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGk4Q-0004lR-7H for manet-dt@ietf.org; Fri, 25 Aug 2006 18:22:35 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7PMMQZa018614; Sat, 26 Aug 2006 01:22:27 +0300
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 01:21:31 +0300
Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 17:21:29 -0500
Received: from [10.241.174.150] ([10.241.174.150]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 17:21:29 -0500
Message-ID: <44EF77E8.8090209@nokia.com>
Date: Fri, 25 Aug 2006 15:21:28 -0700
From: "Charles E. Perkins" <charles.perkins@nokia.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: ext Ian Chakeres <ian.chakeres@gmail.com>
References: <374005f30608121539x76d7a943v8e7cb5c4261a308c@mail.gmail.com>
In-Reply-To: <374005f30608121539x76d7a943v8e7cb5c4261a308c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Aug 2006 22:21:29.0354 (UTC) FILETIME=[CFCAFEA0:01C6C894]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: "Elizabeth M. Belding \(work\)" <ebelding@cs.ucsb.edu>, manet-dt@ietf.org
Subject: [Manet-dt] Re: DYMO SeqNum Decisions
X-BeenThere: manet-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MANET Design Team <manet-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/manet-dt>
List-Post: <mailto:manet-dt@ietf.org>
List-Help: <mailto:manet-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=subscribe>
Errors-To: manet-dt-bounces@ietf.org

Hello again Ian,

I have gone through the .pdf file with the circles and
arrows and cases for incrementation logic.

I am currently favoring the design choice that intermediate
nodes should NOT increment their sequence number.
My reasoning is along the lines that, as you state, doing
so makes every downstream node to consider the
information as not only authoritative but pre-emptive
(i.e., all previous data MUST be updated).

Why is this a good thing?  Maybe one of the newer
RREQs would have more hopes, get stuck in a queue,
emerge later, and invalidate a route which was already
working fine along noncongested path components.

On the other hand, RREQs with the same sequence
number and fewer number of hops can also get stuck
in a queue and invalidate working routes with more
hops, but that is behavior that we already would
experience today.

Regards,
Charlie P.


ext Ian Chakeres wrote:
> As an exercise in ensuring dymo sequence numbers work properly, I've
> created a few slides discussing important dymo sequence number
> decisions.
>
> Pages 1 & 2 talk about judging routing information usefulness. The
> goal is to not have loops, while not requiring nodes to increment
> their OwnSeqNum unless absolutely necessary. Incrementing OwnSeqNum
> essentially disqualifies existing routing information in the network
> that may not be bad.
>
> Pages 3 & 4 talk about incrementing OwnSeqNum. Since nodes issuing
> RREQ don't know the state of routing tables at intermediate nodes,
> they need to increment their sequence number. Otherwise, receiving
> nodes might discard this information. The target on the other hand has
> more information from the RREQ message (last known values and some
> information about the route traversed). The target can use this
> information to optimize sequence number incrementing.
>
> Intermediate nodes that append their routing information have two
> options, updating their sequence number and ensure it will be fresh at
> other nodes, or not.  If the sequence number is not incremented it
> might not be considered fresh by intermediate nodes. It is not clear
> what the recommended procedure should be. Please make a suggestion. I
> suggest incrementing OwnSeqNum.
>
> Page 5 talks about the cases when an Intermediate node could reply.
> Currently we don't define intermediate node replies, but it is a
> useful concept. One more thing, I've introduced a concept "MaxAge"
> which is the maximum amount of time a piece of routing information can
> be maintained. This is to assist in reboots, by having a hard deadline
> on the maximum amount of time that a node must wait before
> participating.
>
> Please review the flowcharts and let me know if something doesn't make
> sense or is wrong.
>
> Ian Chakeres


-- 
Please address return e-mail to charles.perkins@nokia.com


_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt