Re: [Autoconf] [Fwd: New Version Notification fordraft-baccelli-multi-hop-wireless-communication-03]

["Charles E. Perkins" <[e-mail]>]

Hello folks,

With Teco's permission, I am relaying this technical
exchange to the mailing list.  Emmanuel and I expect
to submit a revised draft soon.  We hope that the
working group will be interested to accept it as a
working group document.

Regards,
Charlie P.

====================================================

Hello Teco,

I hope you'll appreciate the timeliness
of this response :-)  Is it O.K. if I
forward the technical substance of your
email here to the mailing list?

On 11/18/2009 10:46 AM, Teco Boot wrote:
> Hi,
>
> I've two remarks:
>
> 1: Exposed node.
...
> The problem is *prevented from sending*.
> The text below Figure 2 is OK.
> The text above is not correct, also confirmed by Thomas.
> The current text:
>     Even
>     though node C cannot hear D, node D can nevertheless hear C, because
>     node D is outside node A's radio range.  As shown, the exposed node
>     problem is a practical example of the asymmetry of multi-hop ad hoc
>     wireless communications mentioned in Section 2.1.
> - It is not "cannot hear", the ENP is "prohibited to send".
> - ENP has nothing to do with asymmetry

Thanks for your patient attempts to correct this
problem with the draft.  I have reformulated the
section under discussion in a way that I hope is
correct.  I also added a new paragraph and figure
that does illustrate asymmetry, under the example
condition of unequal transmission power.

> 2: The DAD trigger.
> We came to the conclusion to clean up the addressing model on LLs.
> The DAD trigger is true, but it has nothing to do with the model
> itself. And there is no trigger for non-LL DAD also.
> But by removing the "there is no link down trigger", we lose the
> description of this behavior.
> I suggest to add this behavior in the multi-hop-wireless-communication
> draft. I discussed this with few others at IETF, all confirmed this was
> a good relocation. Some said that this behavior also occurs in other
> link types (e.g. FrameRelay: short cable end-node to FR switch is always
> up, but FR may have some troubles). There are many other examples. But
> still, I think it occurs in MANET normal operation and therefore it is
> worth mentioning in your draft.

Emmanuel is going to take a crack at inserting
some text for this, I believe.  It is a matter
somewhat "unlike" the other problems discussed
in our draft, but if it has been discussed by
others and no one objects, I am O.K. with including
it.  However, if people object, I am also O.K.
with taking it back out.

Regards,
Charlie P.