Re: [Int-dir] [ipwave] Expertise on ND problems on OCB

[Charlie Perkins <[e-mail]>]

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.  More to the point in this
    discussion, it's about reducing interference by reducing the number
    of multicasts needed in a multilink subnet.  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.

  * 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.

  * 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?

I think the draft could benefit from a very clear applicability 
statement, specifically including the projected number of vehicles in 
the subnet.  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.  Maybe for clarity it would be helpful 
to include a diagram of a general target network with more than three or 
four vehicles.

You can also tell me that my opinion lacks relevance since I have not 
carefully read the draft.

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]>> 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]>>
>>>>>       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