Hi Stan, all,
Apologies for the way I've pasted and replied, my phone doesn't make it
easy to do neatly.
- Some AODVv2 node 'A' needs to find a route to node 'Q'.
- So, 'A' initiates RREQ, and the search begins.
- The RREQ ultimately gets to 'Q', and 'Q' responds RREP. Said RREP begins
wending its way back to 'A'.
- RREP is received by intermediate node 'F', which is part-way along the
path back to 'A'.
- At this point, node 'F', in an attempt to be really astute, effectively
says "Well, look at this! I see an RREP from 'Q' back to 'A'. I'm on the
path back to 'A', so I'll make the assumption that I now have a route to
'A'!
--------
VICKY: Kinda... but the reason it has a route to A is because it first
received the RREQ containing a route to A, so it's got an idea that there's
potentially a route back (assuming bidirectionality of all the links back
to A). In fact it only verifies the first hop toward A by using RREP_Ack,
and then assumes that all the other links beyond that are bidirectional.
--------
- RREP continues wending its way back to 'A'.
- 'A' either fails, or moves, or somehow/somewhere/someway breaks
connectivity.
- 'F', the intermediate node, suddenly and unexpectedly has traffic bound
for 'A'. Using the assumption above, 'F' now starts transmitting towards
'A', because after all, the RREP went in that direction.
--------
VICKY: Again, kinda. It would forward it based on the fact it installed the
route earlier, because it knew the link to the first hop toward A was via a
bidirectional link.
--------
- The RREP gets to the penultimate hop back towards 'A'. QUESTION: Does the
penultimate node know that 'A' is no longer hanging around? What does the
penultimate node do with the RREP? (and my apologies for not already
knowing that)...
-------
VICKY: same as every other router receiving the RREP, it looks up a route
to A. In this case, since the link to A broke, it would have no route to A
and would send a RERR back to the traffic source, ie back to RREP_Gen.
The actual case we were looking at is if one of the links is
unidirectional, and we send a RREP but it doesn't get received. If at some
point down the track, say at C, the Ack doesn't come back, the route to A
would get deleted at C but not reported I don't think. But because links CD
DE EF were all bidirectional, D E and F have installed a route to A and
might forward traffic on it....see next point...
-------
- Behind the (now failed) RREP, here comes the traffic suddenly sourced
from node 'F' to 'A'. The penultimate node now has no choice but to throw
that traffic on the floor.
-------
VICKY: whichever router discovered the unidirectional link will drop that
traffic yes, and should send a RERR back to PktSource, resulting in routes
to A being deleted at routers that maybe should never have assumed that the
route to A was valid anyway. Then after the RERR, PktSource's router would
have to send a RREQ to find a new and valid route to A.
--------
We had this discussion not long ago, the answer is to force Acks to come
from RREQ_Gen first, then progressively ack back toward RREP_Gen, i.e. not
being allowed to send an Ack until you receive an Ack from your next hop.
Meaning we need a lot more AODVv2 messages and we need to do the same end
to end ack for the route to the OrigAddr in every RREQ.
But the argument was that this requires a whole load more AODVv2 traffic
and that this situation may not arise very often in practise, and that the
traffic generated for the times when there would be a unidirectional link
which would cause the problem of dropped traffic and extra RERR/RREQ/RREP
processes to fix it, might be less than the extra traffic we would require
for every route discovery to avoid the potential of this issue occurring.
Hope that's clear...feel like I'm rambling....
Vicky.
On 30 Nov 2015 21:16, "Stan Ratliff" <ratliffstan@xxxxxxxxx> wrote:
Vicky/All -
I just want to make sure I understand the problem:
- Some AODVv2 node 'A' needs to find a route to node 'Q'.
- So, 'A' initiates RREQ, and the search begins.
- The RREQ ultimately gets to 'Q', and 'Q' responds RREP. Said RREP begins
wending its way back to 'A'.
- RREP is received by intermediate node 'F', which is part-way along the
path back to 'A'.
- At this point, node 'F', in an attempt to be really astute, effectively
says "Well, look at this! I see an RREP from 'Q' back to 'A'. I'm on the
path back to 'A', so I'll make the assumption that I now have a route to
'A'!
- RREP continues wending its way back to 'A'.
- 'A' either fails, or moves, or somehow/somewhere/someway breaks
connectivity.
- 'F', the intermediate node, suddenly and unexpectedly has traffic bound
for 'A'. Using the assumption above, 'F' now starts transmitting towards
'A', because after all, the RREP went in that direction.
- The RREP gets to the penultimate hop back towards 'A'. QUESTION: Does
the penultimate node know that 'A' is no longer hanging around? What does
the penultimate node do with the RREP? (and my apologies for not already
knowing that)...
- Behind the (now failed) RREP, here comes the traffic suddenly sourced
from node 'F' to 'A'. The penultimate node now has no choice but to throw
that traffic on the floor.
Do I understand the problem correctly?
I've got an idea or two, but I want to wait & see if I've got this down.
Regards,
Stan
On Mon, Nov 30, 2015 at 9:33 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Any suggestions folks? The same comment we've received many times about[snip]
buffering TCP, and this comment which makes me re-think hop-by-hop Ack
(again).
*" I do not know that there's substantial enough deployment experience
with the protocol for "so infrequently in practice" to make the above an
actual argument against the issues raised (and, which you confirm, I
understand?) --- this certainly not if targeting std. track."*
It's a question of how often links might be found to be unidirectional,
i.e. how often would we be sending RERRs and RREQ/RREPs to fix a route that
was installed prematurely (before bidirectionality of every hop was
confirmed), compared to how much extra routing traffic we'd generate to
ensure the bidirectionality of every link in a route before installing it
as valid.
Regards,
Vicky.
---------- Forwarded message ----------
From: Thomas Clausen <ietf@xxxxxxxxxxxxxxxxx>
Date: Mon, Nov 30, 2015 at 11:43 AM
Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and
draft-ietf-manet-dlep-17
To: Victoria Mercieca <vmercieca0@xxxxxxxxx>
Cc: manet <manet@xxxxxxxx>
I think that what I wrote can be summarized into two comments:
o It would seem that buffering, as specified, does not accomplish what
it states that it accomplishes: packets are (as you describe) still being
sent while no route is available, and therefore will be dropped later.
=> Consequently, it seems that buffering is a futile exercise?
o (This part you did not address) Buffers have huge impacts on TCP
performance, and I doubt if (even disregarding the issue above) the
issues on e.g. TCP are well enough understood by this WG
(Bufferbloat was an example of where people got it wrong, despite
having extensive experience).
And then, a comment on what you write:
*"But there was a suggestion that this issue might be seen so
infrequently in practise that the overhead required to avoid this issue is
not worth it "*
I do not know from where the referred to suggestion comes, but ... I do
not know that there's substantial enough deployment experience with the
protocol for "so infrequently in practice" to make the above an actual
argument against the issues raised (and, which you confirm, I understand?)
--- this certainly not if targeting std. track.
Best,
Thomas
Sent from my iPad
