Subject: [Manet-dt] DYMO Path Accumulation

From: Ian Chakeres <[email-masked]>
Date: Sun, 9 Oct 2005 13:15:31 -0700

As mentioned during the last IETF, there were some problems with Path
Accumulation (PA).  These problems were related to
1. SHOULD that PA occur.
2. RERR generated in response to these additional routes timing out

To handle 1. I suggest changing the spec to say MAY with some
conditions when you would want to.

To handle 2. I suggest changing the spec to say that RERR should not
be generated for routes that are not used.  That is, routes over which
packets are never routed.

Does anyone have any comments about my proposal?

Ian

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

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Mon, 10 Oct 2005 06:34:54 +0200

Hi Ian

>
>As mentioned during the last IETF, there were some problems 
>with Path Accumulation (PA).  These problems were related to 
>1. SHOULD that PA occur. 2. RERR generated in response to 
>these additional routes timing out
>
>To handle 2. I suggest changing the spec to say that RERR 
>should not be generated for routes that are not used.  That 
>is, routes over which packets are never routed.
>

Let me try to clarify with following example, Node S and D send data
using following path.

S -> 1 -> 2 -> 3 -> D

Due to Path accumulation at Node 3, you have the additional route to
node 1 with next hop node 2. That means, when node 2 is unreachable,
node 3 generates RERR with the unreachable list, consisting of node S
and node 1. 

Here you meant to remove node 1 from the list, assuming there is no data
communication between node 1 & node 3.

This proposal seems ok to reduce RERR generation. How do we identify
that route has not been used for forwarding data?

Koojana

>[email-masked] https://www1.ietf.org/mailman/listinfo/manet-dt
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 10 Oct 2005 10:19:46 +0300

Hello Ian,

These both sound like good ideas to me, especially the latter.
On the other hand, if no neighbors are using the path, the
extraneous RERR should only amount to a wasted local
broadcast.

I remain hopeful that one day we'll solve the puzzle about
why path accumulation isn't helping as it was expected to do.

Regards,
Charlie P.

---

From: "Francisco J. Ros" <[email-masked]>
Date: Mon, 10 Oct 2005 10:58:05 +0200

Hi Ian,

I fully agree with your proposed changes.

Regards,
fran

---

From: "Justin Dean" <[email-masked]>
Date: Tue, 11 Oct 2005 07:56:09 -0400

I personally would like to see some more studies with much longer timeouts.
And maybe optionally a special way of handling older stored routes.  ie
faster timeouts when those routes are trying to be used.

Justin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ian Chakeres
Sent: Sunday, October 09, 2005 4:16 PM
To: [email-masked]
Subject: [Manet-dt] DYMO Path Accumulation

As mentioned during the last IETF, there were some problems with Path
Accumulation (PA).  These problems were related to 1. SHOULD that PA occur.
2. RERR generated in response to these additional routes timing out

To handle 1. I suggest changing the spec to say MAY with some conditions
when you would want to.

To handle 2. I suggest changing the spec to say that RERR should not be
generated for routes that are not used.  That is, routes over which packets
are never routed.

Ian

---

From: Ian Chakeres <[email-masked]>
Date: Tue, 11 Oct 2005 09:14:54 -0700

I think PA has some usefulness, but as mentioned it depends on lots of
factors.  I'd like to include the possibility of including the PA
information and leave it to future (more complex) caching strategies
to take full advantage.

I agree longer timeouts will in general help things, as long as these
fit the mobility :).

Does anyone have a good idea, what should the default timeouts values be?

Ian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Oct 2005 10:16:00 +0300

Hello Ian,

We have a lot of recent information about timeouts.
Maybe other people do also.  Anyway, I'll write
more about it later.  Just now there's a tornado
in my virtual office.

Regards,
Charlie P.