HI Charlie,
Am 30.04.2016 um 15:13 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
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>I am not looking for simulations. I am looking for actual use cases being
wrote:
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.
run 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 a1) 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)
paragraph or two about 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.
