Hello Lotte,
A designation as Experimental indicates that certain experiments remain
to be done -- right?
For implementation and operation on wireless networks (i.e., not
simulation), what results are needed?
Is it simply wanted to see if the network will sustain traffic?
Are you sure that going to Experimental demands that we identify which
experiments have already been conducted?
Please advise!
Regards,
Charlie P.
On 4/30/2016 3:59 AM, Lotte Steenbrink wrote:
Hi Charlie,
On 29 Apr 2016, at 19:40, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx> wrote:I am not looking for simulations. I am looking for actual use cases being run
Hello again Lotte,
I was perhaps too hasty claiming that no experiments are needed except for
interoperability.
I can think of the following:
- Experiments to show the performance degradation due to multicast RREP <answer:
I'm giving 10 to 1 that it is pretty bad>
- Experiments to show the performance of multi-interface IP address solution
<answer -- depends on what the solution is. But if we can use MAC address I am
pretty sure the performance would be practically as good as single-interface IP
address>
These are legitimate experimental responses to the publication of the draft.
However, there are a number of other experiments that could be run, and I'd
love to help
- Experiments to show the number of RERRs as a function of mobility
- Experiments to show that AODVv2 maintains the good scalability aspects of RFC
3561. I fear for the negative effects of multicast RREP on this, unfortunately.
- Experiments to show the effect of progressively increasing the number of
unidirectional links, maximum length of blacklist tables, etc.
- at least 5 other very important experiments I have wanted to do for years...
I would *love* to do these experiments. I wish I had grad students! If you or
any of your colleagues are interested in more papers, please let me know. I
know just how to run the experiments and with a good simulator we could go to
town.
on actual hardware, and I'm looking for work that has already been done because
as much as I'd love to have one, I do not possess Hermione Granger's nifty
trinket that can turn back time.
Best,
Lotte
Regards,
Charlie P.
On 4/29/2016 10:26 AM, Charlie Perkins wrote:
Hello Lotte,
I cannot justify the use of RFC 5444 on any experimental basis. Every
performance experiment that would be carried out would quite certainly show
worse performance. The only justification is RFC 5498, and RFC 5498 is not
characterized as Experimental although now experience would clearly support
such a designation. The main benefit of RFC 5444, address aggregation, would
have been done better by using the compression strategy in 6lowpan/6lo.
The only justification for removing Intermediate RREP and certain other
features was an attempt to satisfy Jiazi et al. Moreover he is very well aware
of these circumstances, and so this colors my interpretation of his request.
Should I dream up some fictional reason for removing the features? What if
there were no experimental basis whatsoever for the removal, but only political
reasons?
I do accept being an expert on RFC 3561, and I do want to make an honest
contribution in response to the comment, but I have a hard time imagining what
is actually wanted.
I am not very clear about why a draft going to Experimental has to discuss what
experiments occurred in the past. It would make sense to discuss what
experiments are still needed. But, the answer is none except purely for
interoperability testing, and no one seriously doubts that the draft is
specified in a way to greatly promote interoperability.
Can we discuss this some more? I would appreciate your follow-up observations
on my above comments.
Regards,
Charlie P.
On 4/29/2016 8:03 AM, Lotte Steenbrink wrote:
Hi Charlie,
I’m going through Jiazi’s review again right now, more specifically his remarks
about us needing to extend the experiment description (a point that has been
made by others too, I think). Among other things, it says:
You’re the expert on that one, do you think you could write up a paragraph or two about1) Because RFC 3561 has already been experimented for 13 years, as its version
2, AODVv2 should summarize what kind of experiences have been obtained in the
past 13 years, and justify the design choices made in the current draft (like
use of RFC5444, removing some of the features, etc)
that? The only work I can recall off the top of my head is
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1648456&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1648456
, where the „real environment“ is a few nodes on a lab table...
Am 29.04.2016 um 16:54 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
Hello folks,
I could submit a design for using RFC 7182 for the end-to-end authentication
unless you folks already have a plan for that.
I would also be willing to carry on the discussion about multi-interface IP
address (MIA) handling unless something has been decided about that. I didn't
see any follow-up to my previous discussion here or on the mailing list, so I
don't know the status.
Please let me know...
Regarding the MIA support, I think we ought to have a configuration variable called
MIA_SUPPORT. If TRUE, then the platform would have to meet certain requirements. These
can be formulated as requirements for "interface ID" support, or support for
MAC addresses. In the former case, I expect the requirement for support would be more
invasive. Supporting MAC addresses is much more natural for the operating system
platform.
Regards,
Charlie P.
