John,
Well said. Bravo, my friend. Bravo.
And +1 on all counts.
Regards,
Stan
Sent from my iPhone
On Jun 27, 2015, at 8:29 AM, John Dowdell <john.dowdell486@xxxxxxxxx> 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 PerkinsHow do we know if it almost never arises? You cite simulation experience
<charles.perkins@xxxxxxxxxxxxx>:
Hello Stan,
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?
with 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:okay with Vicky's version, but maybe we could squeeze in a sentence
Hi all,
Am 25.06.2015 um 17:52 schrieb "Ratliff, Stanley"+1, if that's doable considering the time we have left. Otherwise, I'd
<sratliff@xxxxxxxxxxx>:
John,
My opinions on the items before us:
1. Unconfirmed routes: Go multicast, as was suggested by Justin Dean.
also be
outlining the consequences of not using rrep_ack?
Concerning the Gateways, I'll trust whatever you all decide, since Ithink I have the experience it takes to make a useful decision.
don't
Regards,router. I've not heard, therefore it's not clear, exactly where Justin &
Lotte
2. Gateways: Leave text in about Gateway router not being default
Charlie
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.
_____________________________________________________
