Folks,
considering that we'll have to get AODV done *now* in order to save it
from being killed, and we're still undecided on some critical issues that
have been raised, I feel like we need to make sure we
a) have an overview over unresolved issues
b) are transparent about our discussion and status on these issues (i.e.
show that we're not ignoring them, but that we're just stuck on some).
Charlie achieved that a while ago with the use of
http://trac.tools.ietf.org/wg/manet/trac/report/1, which seems like the
right tool for the job, so I decided to follow in his footsteps. I've
collected all issues I could find and will put them into the issue tracker
this evening (i.e. in about 10 hours from now) when I get home. At the
bottom of this e-mail you'll find what I've collected so far. All issues
are divided by a dotted line. Please feel free to append/correct anything
that's missing. Alternatively, feel free to join the comments in the issue
tracker later on. :)
Cheers,
Lotte
use of RFC 6621 causes interoperability problems
------------------------------------------------
Brought up by Christopher Dearlove
(http://www.ietf.org/mail-archive/web/manet/current/msg18164.html):
But this has made me think about the RFC 6621 reference in AODVv2. It's
always been clear this has been rather a throwaway comment that needed
thought, but until now I hadn't really given it any.
And it doesn't work. RFC 6621 is fundamentally unusable here. Let's
consider each on turn.
RFC 6621 is about packets. But not even RFC 5444 packets but IP packets.
It's about whether or not to forward them. But RFC 5444 packets aren't
just not forwarded in unchanged IP packets, they aren't even forwarded at
all. They are each a single hop construct, and if a message is forwarded
(which is by the routing protocol, as far as RFC 5444 is concerned, it's
a new message) it will be in a new packet, with possibly new companions.
Status:
Resolved (removed from the draft)
RREP_Ack hop by hop vs end to end
---------------------------------
Brought up by Thomas Clausen
(http://www.ietf.org/mail-archive/web/manet/current/msg18163.html):
Also on buffering, I am wondering if the "start delivering buffered
packets" conditions (penultimate paragraph in 6.6, and of course through
the processing sections) is sufficient; I suspect that the condition
"When a valid route is installed" is not sufficient - that there are
situations where a routing table entry is installed, but the complete
route is not available or is not bidirectional?This obviously is related
to RREP_Ack being hop-by-hop and not end-to-end....
Follow-up by Vicky
(http://www.ietf.org/mail-archive/web/manet/current/msg18171.html):
Thomas is right about hop-by-hop RREP_Ack. For intermediate nodes who
install a route to OrigAddr based on a one-hop RREP_Ack from their next
hop toward OrigAddr, it's not guaranteed that the complete route to
OrigAddr is available. Since the route is valid, the router may start
forwarding data packets to OrigAddr. An issue occurs if data packets are
forwarded to intermediate routers before the intermediate router installs
a valid route. If this happened, those data packets would be dropped and
RERRs generated (and regenerated toward the source of the data packets by
any router using it), and the route to OrigAddr would be removed at some
but maybe not all of the routers that installed it. A new RREQ would then
have to go out on behalf of the source of the traffic. So this problem
would eventually fix itself....but not without some dropped packets,
RERRs, and a new RREQ/RREP cycle. 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.e. the extra control
traffic of acknowledging every link in every route ever requested, even
when some links are already known to be bidirectional).
If you disagree, then we need to make RREP_Ack end-to-end and accept the
fact that this will result in many more RREP_Ack messages being generated
than in the current version.
Status:
We're stuck 4:1. Awaiting comments.
Buffering issues
----------------
Brought up by Thomas Clausen
(http://www.ietf.org/mail-archive/web/manet/current/msg18163.html,
http://www.ietf.org/mail-archive/web/manet/current/msg18242.html):
The second issue is that I also suspect that there is some issue with
buffering, or rather with how it is specified; starting in section 6.6, I
am not sure that leaving that as "a matter of policy at each router" is
entirely right.
[...]
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).
Status:
--
RREQ "forwarding" vs "regeneration"
-----------------------------------
Brought up by Thomas Clausen
(http://www.ietf.org/mail-archive/web/manet/current/msg18163.html):
The protocol currently talks about "message is regenerated" rather than
"forwarded". I have understood that this means that a RREQ is actually
not an "end to end" entity, but is a "hop by hop" entity.
First, that is a curious design choice, is there any reason why this is
so considered?
Responded to by
Vicky(http://www.ietf.org/mail-archive/web/manet/current/msg18167.html),
asking:
Can we really use the term "forwarding" if we are changing the metric
value, adding a validity time, adding/removing AckReq or removing
addresses and their associated TLVs?
Status:
Awaiting comment from Thomas (or others)
Security considerations insufficient
------------------------------------
Brought up by:
Support from: Thomas Clausen
(http://www.ietf.org/mail-archive/web/manet/current/msg18163.html
Status:
