Hi Vicky,
I think your E-Mail sums up the status quo and our previous attempts quite
nicely... I'm wondering if it would be appropriate to just use this text
on the MANET list as a response to Thomas' comments?
Regards,
Lotte
Hi all,
Regarding the comments on buffering from Thomas Clausen's
email...specifically:
*"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....*
*"*
The route not being bidirectional (ie a complete route existing in both
directions between OrigAddr and TargAddr) doesnt matter. Once we install a
valid route (either to OrigAddr or to TargAddr) we will start using it, it
doesnt matter if there is a route back... it can be requested if
necessary.
A link in the route being bidirectional or not, does matter... Thomas is
right about RREP_Ack. Because it is hop-by-hop, then even when a valid
route is installed we cant guarantee that the complete route is available.
But we would start sending anyway. The issue occurs if data packets are
forwarded to intermediate routers before the intermediate router installed
a valid route (in fact they might never install a valid route if a link is
not bidirectional). If this happened, there would be packet drops and
RERRs, and the route to OrigAddr would be removed at routers that were
trying to use it. A new RREQ would then have to go out on behalf of the
source of the traffic. So this problem would sort of fix itself....but not
without lost packets, RERRs, and a new RREQ/RREP cycle. But this issue
might be seen so infrequently in practise that the effort required to
avoid
this issue is not worth it.
In the end, when we discussed this before, we decided to make no changes.
So I'm not sure what to do this time around, either.
Regards,
Vicky.
---------- Forwarded message ----------
From: Thomas Clausen <ietf@xxxxxxxxxxxxxxxxx>
Date: Wed, Nov 18, 2015 at 1:35 AM
Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and
draft-ietf-manet-dlep-17
To: "Ratliff, Stanley" <sratliff@xxxxxxxxxxx>
Cc: "manet@xxxxxxxx" <manet@xxxxxxxx>
<snip>
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.
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....
Either way, the parts of the specification that relate to buffering
contain
a mixture of normative and non-normative verbiage (a lot of "can" but also
a lot of MUST/SHOULD) which I think could do with a tightening up.
But....is buffering even something that should be specified by this
document? It does not impact interoperability and it interferes
substantially with transport and congestion control, and I am not sure
that
we understand the consequences (I am not convinced that the claims in the
document on benefits to TCP are substantiated or even true).
<snip>
