Re: [Manet-dt] [Fwd: Re: DYMO SeqNum Decisions]

["Pedro M. Ruiz" <[e-mail]>]

Hi all,

Sorry for late answer, it took me a while to go through the whole 
thread, and check old e-mails with our previous discussions on this same 
issue.

I do remember we discussed quite a lot about this issue after Paris 
IETF. There were different solutions being proposed and simulated. I do 
remember Fran sent out the graphs of the different schemes...

Let me recapitulate so that other people in MANET-DT can get some context...

As Ian mentioned, the issue is that RREPs are being blackholed by some 
intermediate nodes. This may happen due to mobility, just changing the 
length of the reverse path back to the source.

We simulated two alternatives. first one was my proposal to increase 
OwnSeqNo when creating a RREP (I know we don't want this) and second one 
was Charlie's porposal of allow RREPs to be propagated if seqnos are 
equal and hopcount no more than 1 hop longer. The reason for the 
condition of 1 hop was to avoid creating loops.

The performance shown in the simulations was almost the same for both 
schemes. Thus, we decided to include the second alternative in v3 of the 
DYMO draft.

Even with these changes, I pointed out some time ago that blackholes 
could still happen when topology changes include a more than
2 hops difference between the intermediate node and the node sending the 
RREP.

Fran simulated a solution in which we allow a RREPs to go back to the 
source if seqnos were equal, regardless of the hop count and simulation 
results where as good as the two previous alternatives. I remember we 
were discussing whether allowing those RREP to be propagated could 
create a loop, and AFAIR, we didn't find a case in which that would 
happen. It seems that it was safe to allow those RREPs to be propagated 
without creating a loop. I think this is very similar to what Charlie 
said about having a local table where recent RREQs are stored.

Wouldn't that be a valid solution?

Regards,

--Pedro

Ian Chakeres wrote:

> Comments inline.
>
> On 8/25/06, Charles E. Perkins <[e-mail]> wrote:
>
>>
>> Hello again Ian,
>>
>> A few follow-on comments...
>>
>> ext Ian Chakeres wrote:
>> >> > Pedro & Fran ran into seq num problems last year. During IETF 65 
>> Ramon
>> >> > identified another sequence number issue related to this 
>> discussion.
>> >> > Both had problems with RREP being blackholed.
>> >> Were those problems caused by the scenario outlined in recent 
>> e-mails?
>> >
>> > Both these problems were because the RREP originator was not
>> > incrementing its sequence number.
>> That formulation prejudices the outcome.  I will interpret it to mean 
>> that,
>> both problems would be solved if the RREP originator would
>> increment its sequence number.  But the problem is _caused_ by
>> some other occurence.  It is this true cause of the problem that
>> I want to know more about.
>
>
> "The problem"  is that RREP were not being considered as fresh or
> superior, and therefore dropped.
>
> I would like to find a solution that does not require the RREQ target
> (RREP originator) to increment its sequence number, but I have not
> found one yet.
>
> Finding such a solution appears difficult, since the target does not
> know the state of routing tables in nodes along the path from the RREP
> originator to the RREP target (RREQ originator).
>
> I am querying you and others to propose a solution that would solve
> "The problem". Hopefully, one that does not require the RREP
> originator to increment its seqnum.
>
> One other note lower.
>
>> >> > If we force intermediate nodes to examine information about the 
>> target
>> >> > (last known seqnum and hopcnt) we might be able to know 
>> something at
>> >> > the target node about the route traversed. But we still need to 
>> ensure
>> >> > that a RREQ will reach the target, and I think any such logic could
>> >> > result in RREQ blackholing.
>> >> I think I am missing something here, unfortunately.  Can you say
>> >> just a little more about when the blackholing would occur?
>> >
>> > This condition would occur whenever an intermediate node discarded a
>> > RREQ (due to new rules) and it was the only route to the target.
>> Do you mean the new DYMO rules?  Or, which ones specifically?
>
>
> A possible set of new processing rules associated with dropping RREQ
> based on the target's last know sequence number and hop count that
> would allow the RREQ target to know something about the route
> traversed.
>
> I do think blackholing could occur if this (new processing rules) were
> implemented.
>
> Ian
>
>> -- 
>> Please address return e-mail to [e-mail]
>>
>>
>
> _______________________________________________
> Manet-dt mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/manet-dt
>


-- 
---------------------------------------------------------------------
Pedro M. Ruiz, Ph.D.                    E-mail: [e-mail]
Fac. Informatica, Univ. of Murcia       Phone:  [phone]
Campus de Espinardo s/n                 Fax:    [phone]
E-30100, Espinardo, Murcia              www: ants.dif.um.es/~pedrom/
SPAIN
---------------------------------------------------------------------


_______________________________________________
Manet-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt