Hello John,
I did not suggest we pick any particular technology. But throughout
IETF's history there has always been consideration of reality -- and
right now most ad hoc networks that I know about run over 802.11 except
in the military which uses a lot of strange stuff.
Anyway, what do you think about my suggestion for it to be an optional
behavior with the technical considerations clearly described?
I totally disagree that message based systems are disassociated from
caring about interference. That argument leads directly to disaster and
to unusable systems -- immediately one does not care if all messages are
kilobytes in length. If RFC5444 is used to support that argument, then
we are doomed. You could say the same thing about TCP -- it's divorced
from interference. And yet no one would require all TCP messages to be
multicast with next hop specified, even though the arguments could be
made very similar to the point under discussion here.
Regards,
Charlie P.
On 6/27/2015 5:29 AM, John Dowdell wrote:
Charlie and all
I believe I have read and digested the emails on this topic and have the
following to offer.
1. We haven’t specified a radio technology to use in the draft, far less
considered the whys, wherefores and esoteric points of 802.11 protocols
various. In the wild, I haven’t seen that many mobile ad-hoc networks built in
anger, e.g. for the military or first responders, but those that I have seen
have not used 802.11 technology between routers. Even some radios from a vendor
with whom Stan and I are familiar didn’t use vanilla 802.11 but made a whole
load of tweaks. Exactly which tweaks are a closely guarded trade secret, but
the tweaks are there all the same. Acknowledging the arguments on interference,
in my own home I had to move a pile of computers off 802.11 to 802.3 just to
get the things to work properly, since the networks of my neighbours didn’t get
on terribly well with mine and my Access Points couldn’t cope with the number
of stations either. That’s before we get to the polarised viewpoints about
whether 802.11 ad-hoc mode or 802.11s are actually usable or not, which I will
step around for now.
2. So the reason we haven’t specified a radio technology is because we can’t.
This being the IETF and not the IEEE or ETSI, we have to specify the protocol
in it’s own little world. Therefore we are unable to make any assumptions about
how well or badly the inter-router communication system may or may not perform.
I do not disagree with the arguments presented on this list about how certain
wireless protocols perform, mainly because I can’t as I do not have the depth
of experience. But thanks for the information anyway and I’ll bear it in mind
for other work.
3. In the brave new world of RFC5444, AODVv2 cannot send packets, nor dictate how
they may or may not be formed, nor can we make any assumptions about how many
packets or retransmissions may be sent. We just can’t, because we are ring-fenced
into sending messages, and how the data is sent to the physical interface is no
longer our concern. In fact we should be royally chastised for thinking about
packets because that is the business of RFC5444 and whatever other protocols are in
the path to the physical interface. If those other protocols wish to rewrite the
data so it is transmitted upside down and back to front, we in AODVv2 author team
cannot even so much as raise an eyebrow. Quoting from the applicability statement in
RFC5444, "Packets may be unicast or multicast and may use any appropriate
transport protocol or none”. I believe the whole point of RFC5444 was to provide a
single path for aggregated message flows between adjacent manet routers in order to
significantly reduce numbers of packets and thus collisions and retransmissions.
4. Neither can we actually take account of any discussions on how well or not a
certain radio performs multicast or unicast, for the reasons explained above. I
can think of many radios that will not perform multicast very well at all, but
I can’t let that cloud my judgement. As an author team, we have to decide what
is best for our own protocol, and the rest of the communications protocol stack
both upstream and downstream does not exist, other than the edge interfaces to
adjoining protocols.
5. Thus we must make the decision on whether to unicast or multicast RREP based
on what is best for AODVv2 performance at the message level, and nothing else.
As I understand it, if we want to send an RREP in unicast before the route is
marked as confirmed, we would have to place an entry in the routing table to
the neighbour just to get the RREP to send. For multicast, we can just send it.
If we do multicast, I believe that means RREP-Ack must also be sent multicast.
If we do send unicast, any other protocol (that we have absolutely no control
over) can also use the published entry in the routing table, which could lead
to all sorts of issues.
I believe I have just thrown my hat in the ring for multicast.
For myself, there is a point of order here which I will have to raise with the
RFC5444 author team, in that how exactly are you supposed to direct a 5444
parser to send some information multicast? I’m sure that should be explained in
the usability draft recently published.
Regards
John
On 26 Jun 2015, at 17:41, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Lotte and Stan,
I would be willing to have this technical discussion incorporated into an
optional section of the draft that explains the following:
- multicast RREP is optional as discussed (i.e., MAY)
- the problem being solved is clearly exhibited
- the costs of multicast (as I have listed them, and maybe more) are clearly
shown
Then implementers can make an informed decision about whether to implement the
MAY.
I look forward to your opinion on these following points:
The things that are most important in performance for wireless networks have to
do with interference (disregarding security for a moment).
Things like packet size do matter, but way more important is the dynamics of
the control signaling. A good way to understand protocol congestion is simply
to count the number of packets that have to be sent. This is typically much
more important than packet size.
So, for instance, any flooding operation has first-order effect on performance,
because the total number of packets grows as n^2.
Unreliable transmission exacerbates this problem. It is often taken into
account by using a multiplicative factor of (1 + ETX), where ETX is the
expected number of retransmissions before a packet is received.
I gather that you do not dispute my points about the excess overhead and poorer
reliability of multicast. These are not my opinions. These are well understood
facts and have been been measured many times.
Judging from your email, the major point of dispute lies in whether or not the
problem actually occurs in practice. But this problem scenario is exactly the
same for both AODVv1 and AODVv2, so AODVv1 experience is quite relevant. If
you don't believe this, I would very much like to have a technical discussion
about how AODVv2 is different from AODVv1 so that I can understand.
I really feel like Stan and you are reacting to my position as simple
intransigence, and I promise you that I have no such motivation.
Regards,
Charlie P.
On 6/26/2015 8:52 AM, Lotte Steenbrink wrote:
Hi,
Am 26.06.2015 um 17:13 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
Hello Stan,How do we know if it almost never arises? You cite simulation experience with
I stand corrected. I probably shouldn't have said that -- it's way too early
for me here.
But I really can't understand why the two points I summarized for Lotte are not
practically conclusive, and there hasn't been any discussion about it in the
list.
Worse performance? Why do that? Especially for a condition that almost never
arises?
AODVv1, but we have no experience with AODVv2 over real radios, in lossy
networks, let alone in networks of a certain size.
There is an issue, and I don't feel comfortable brushing it off with “this
never happened in our simulations for AODVv1”. If we had infinite time, I'd
love to investigate the entire thing more thoroughly. But we don't, so I'm
inclined to go with a solution that can at least be a starting point for a
discussion.
To be fair, I don't have the experience I'd like to have, even though I did
some implementation work. Personally, I've only come across instances of the
issue when our emulation environment was acting weirdly, and it's cost me some
sleepless nights. I'd love to have more reliable data and experience, but
unfortunately mistakes were made, things didn't progress as planned, and I'm
kicking my ass for it every day (while working to improve ;) ).
Regards,
Lotte
Regards,
Charlie P.
On 6/26/2015 8:09 AM, Ratliff, Stanley wrote:
-----Original Message-----Incorrect. I read it. It didn't change my position.
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of Charlie Perkins
Sent: Friday, June 26, 2015 11:07 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: Decision time, folks
Hello Lotte,
Did you read my email to Justin about the difference between multicast and
unicast?
To summarize:
- multicast is an *order of magnitude* more expensive than unicast, even
over a single hop with one neighbor
- multicast is NOT reliable over 802.11 and unicast IS reliable (so RREP is
*less
likely* to be received).
I don't understand how you could vote for multicast if you read that.
Is it just that you don't believe me?
I doubt that Stan read it.
Stan
Regards,_____________________________________________________
Charlie P.
On 6/26/2015 12:25 AM, Lotte Steenbrink wrote:
Hi all,okay with Vicky's version, but maybe we could squeeze in a sentence
Am 25.06.2015 um 17:52 schrieb "Ratliff, Stanley" <sratliff@xxxxxxxxxxx>:+1, if that's doable considering the time we have left. Otherwise, I'd also be
John,
My opinions on the items before us:
1. Unconfirmed routes: Go multicast, as was suggested by Justin Dean.
outlining the consequences of not using rrep_ack?
Concerning the Gateways, I'll trust whatever you all decide, since I don'tthink I have the experience it takes to make a useful decision.
Regards,router. I've not heard, therefore it's not clear, exactly where Justin & Charlie
Lotte
2. Gateways: Leave text in about Gateway router not being default
are in their discussion wrt Gateways. For example, is that the only issue left?
Are there substantial points remaining that might adversely affect a request
for last call?
come to consensus for now.Regards,
Stan
-----Original Message-----
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-
bounce@xxxxxxxxxxxxx] On Behalf Of John Dowdell
Sent: Thursday, June 25, 2015 5:04 AM
To: AODVv2 Discuss
Subject: [aodvv2-discuss] Decision time, folks
Good morning all
As you all know, draft submission cut off time is 2359 UTC on Monday
6 July (= 0059 July 7 in UK). Vicky is on holiday next week, and
Lotte is fast approaching (if not already in) exam time, which means
we need to go firm on two topics currently under discussion by the
time Vicky starts work at 0900 UK time tomorrow (so that's 0100
Friday for Charlie,
0400 Stan and 1000 Lotte) in order for Vicky to make final
substantive changes. Any remaining scraps can be tidied up on the
Monday 6th when Vicky returns from holiday and we can submit.
I believe Working Group Last Call does not mean we can't make any
more changes. You'll have seen (and some of you have lived) the
changes to DLEP as it went through and following the last call
period. We still haven't had a great deal of feedback from the
working group which means they're either busy, don't have an
opinion, or are ok with it, but regardless we still need to plough on and
Prague.Details can still be worked on, and indeed I was just discussing
with Vicky the prospect of an author team call while most of us are at
can change things.So the two topics are gateways and routes to neighbours.
I'm not going to direct the outcome, that wouldn't be fair, but I
need you all to come to a position of "good enough for now", to
arrive at a document that we can all defend at Prague, and that
position needs to be arrived at by the time mentioned above. This
may mean each of you need to concede on certain points of detail,
perhaps against your better judgement, but it won't be the last time we
I'm really pleased with the progress, we have come a long way. Let's_____________________________________________________
work together to get these last points agreed (for now) and written up.
Thanks and Best Regards
John
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary and/or
confidential. It is intended solely for the use of the individual or
entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email in
error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this
email in error, please delete it and immediately notify the sender.
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
