Re: [ipwave] Expertise on ND problems on OCB

[Abdussalam Baryun <[e-mail]>]

Hi Charlie,



On Mon, Apr 15, 2019 at 4:17 PM Charlie Perkins <
[e-mail]> wrote:

> Hello Alex and all,
>
> I have a few comments, although I have only briefly scanned the OCB draft.
>
>    - RFC 8505 isn't just about low power.
>
> The titles says that, so the authors said that and including the IETF
WG that published and examined it under such use cases.


>    - More to the point in this discussion, it's about reducing
>    interference by reducing the number of multicasts needed in a multilink
>    subnet.
>
> IMHO, there are differences when we have multilinks of low-power of short
range, and multilinks of high-power long range.

>
>    - Please note that I am neither discouraging nor advocating the use of
>    RFC 8505 for v6-over-OCB, but I think it would be better to avoid
>    suggesting that it is only useful for low-power mesh.
>
> I think it is better we focus discussion on one doc not two

>
>    -
>    - Even if you did have four cars to run experiments, the results could
>    hardly be considered conclusive.  Simulation can be very helpful in such
>    circumstances.  You know the velocities and the range of the signal. You
>    have many many thousands of easily accessible real-world topologies, and
>    even the interference characteristics.
>
> the 4G coverage is doing ok in connecting Cars in high velocity with
 interference, so we can get connectivity between V2X in transportation
environment.

>
>    -
>    - I made a quick scan of the draft and found this: "All nodes in the
>    subnet MUST be able to communicate directly using their link-local unicast
>    addresses.".  Does this mean that the solution is not applicable for
>    topologies exhibiting the hidden terminal problem?  Or, does "directly"
>    mean something else?
>
> No the topology includes hidden stations, but stations are using collision
avoidance so it is ok.

>
>    -
>
> I think the draft could benefit from a very clear applicability statement,
> specifically including the projected number of vehicles in the subnet.
>
The number of the subnet is changeable, but I expect it to be depending on
the MAC technology  CSMA/CA and frequency band/channels. Why you want to
discuss the numbers while many RFCs don't do that. The subnetwork or
OBU-number is not the issue in this draft, but the IPv6 over V2X-OCB.

>   If every vehicle on the subnet can expect deliver of multicast packets
> to every other vehicle on the subnet, then the problem is different than if
> hidden terminal effects occur or if multicast is unreliable for some other
> reason.
>
Yes it does expect, but it is seeking mostly service not neighbour
discovery, so if not delivered for some reason then it can get service from
others,

> Maybe for clarity it would be helpful to include a diagram of a general
> target network with more than three or four vehicles.
>
ok

> You can also tell me that my opinion lacks relevance since I have not
> carefully read the draft.
>
no problem, thanks for your discussion,

AB

> Regards,
> Charlie P.
>
>
> On 4/15/2019 4:54 AM, Alexandre Petrescu wrote:
>
> Hi Brian,
>
> Le 14/04/2019 à 22:49, Brian E Carpenter a écrit :
>
> Hi Alexandre,
>
> On 15-Apr-19 04:38, Alexandre Petrescu wrote:
>
>
> [...]
>
>     The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used
>     over 802.11-OCB links.  Transmitting ND packets may prove to have
>     some performance issues.  These issues may be exacerbated in OCB
>     mode.  Solutions for these problems SHOULD consider the OCB mode of
>     operation.  The best of current knowledge indicates the kinds of
>     issues that may arise with ND in OCB mode; they are described in
>     Appendix J.
>
>
> That's exactly the text that I find problematic. I can't write a new
> version because I lack your expert knowledge, but IMHO it should be
> more specific:
>
>
> I do have expert knowledge on ND on OCB, although only at a certain
> level.  It works.
>
> Other people may claim ND does not work on OCB, but have they tried OCB at
> all?
>
> It is the people who claim ND does not work on OCB should write the new
> version of the 'TBD' text.
>
> It is very simple to try ND on OCB.  I published a howto on the email
> list.  A Hackathon w/o me was tried following that howto.  A few other
> organisations that I work with tried it (w/o me).  I did not received
> feedback from them about ND not working.
>
> What is difficult to try is to reproduce the ND-over-OCB problem imagined
> by Pascal.  It is difficult to try because it involves 4 cars (I dont have
> that many).  It  is also difficult to try because it seems to miss the fact
> that OCB can do high power.  Maybe that high power solves the problems that
> appear in ND over low power.
>
> For my part, I cant put text about ND on OCB without having an
> implementation of that problem.
>
> It is for that reason that I asked Pascal, or anybody else claiming ND
> does not work on OCB, to try it and write that text 'TBD'.
>
> Alex
>
>
>      The baseline Neighbor Discovery protocol (ND) [RFC4861] MUST be used
>      over 802.11-OCB links.  However, as on any wireless link,
> transmission
>      of multicast ND packets may fail in OCB. In particular, scenarios
>      where TBD TBD TBD are likely to be unreliable and SHOULD NOT be
>      deployed until an alternative standardised solution is available.
>      The best of current knowledge indicates the kinds of issues that
>      may arise with ND in OCB mode; they are described in Appendix J.
>
> Also I don't like this phrasing in Appendix J:
>
>     Early experiences indicate that it should be possible to exchange
>     IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR
>     (Address Resolution).
>
> Could you rather say the opposite:
>
>     Early experience indicates that it is possible to exchange
>     IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR
>     (Address Resolution) in good conditions. However, this does not
>     apply if TBD TBD TBD...
>
> Regards
>      Brian
>
>
>
>
> Alex
>
>
> Regards
>      Brian
>
> On 14-Apr-19 13:58, NABIL BENAMAR wrote:
>
> +1 Sri
>
> On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave) <[e-mail]
> <mailto:[e-mail]> <[e-mail]>> wrote:
>
>       I understand your point Brian, but IMO there are enough reasons not
> to
>       delay this work.
>
>       There are many use-cases/applications where there is a stable
> topology of
>       RSU¹s and OBU¹s. The regulations around 5.9 Ghz (DSRC) band allows
> the
>       channel use for non-priority/non-traffic safety related
> applications. For
>       example, a vehicle in a gas station can receive a coupon from the
>       802.11-OCB radio (AP/RSU) in the gas station. There, its a stable
> topology
>       that classic ND is designed for. In this operating mode, its
> perfectly
>       reasonable to use classic ND and it works. The authors have shown
> enough
>       lab data on the same.
>
>       Ideally, I agree with you that it makes lot more sense to publish
> both the
>       specs at the same time. But, for what ever reasons the WG went on
> this
>       path. Authors have spent incredible amount of efforts in getting the
> draft
>       this far and we cannot ignore that. You can see the efforts from the
>       version number; when did we last see a draft version -037?
>
>       We also need to distill the recent ND discussions and filter out the
>       threads that are clearly motivated to insert a ND protocol that is
>       designed for a totally different operating environment. An argument
> that a
>       protocol designed for low-power environments is the solution for
> vehicular
>       environments requires some serious vetting. Looking at the
>       characteristics, always-sleeping, occasional internet connectivity,
>       low-power, no memory, no processing power, no mobility ..etc,
> meeting
>       vehicular requirements is some thing most people in the WG do not
> get it.
>
>       Bottom line, IMO, we should move this forward and publish the
> document.
>       All we need is a simple statement in the spec which puts some scope
>       limits, w.r.t the missing ND pieces and issues. There are other
> proposals
>       in the WG that will address the gaps and bring closure to the work.
>
>       Sri
>
>
>
>
>
>
>
>
>
>
>       On 4/12/19, 1:28 PM, "Brian E Carpenter" <
> [e-mail] <mailto:[e-mail]>
> <[e-mail]>>
>       wrote:
>
>       >On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
>       >>If you go back and check 2017 archives, I did raise many of these
>       >>issues.  But, we clearly decided to limit the scope excluding
> address
>       >>configuration, DAD, ND aspect, link models. When there is such a
> scope
>       >>statement, it should clearly move these comments to the draft that
>       >>defines how ND works for 802.11-OCB links.
>       >
>       >This is of course possible. In general the IETF hasn't done that,
> but has
>       >followed the lead set by RFC 2464 with the complete specification
> of
>       >IPv6-over-foo in one document.
>       >
>       >However, I don't believe that publishing an RFC about the frame
> format
>       >without *simultaneously* publishing an RFC about ND etc would be a
> good
>       >idea. That would leave developers absolutely unable to write useful
>       >code, and might easily lead to incompatible implementations. Since
>       >we'd presumably like Fords to be able to communicate with Peugeots,
>       >that seems like a bad idea.
>       >
>       >Regards
>       >   Brian
>
>
>
> .
>
>
>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>