Le 15/04/2019 à 10:04, Pascal Thubert (pthubert) a écrit :
Hello Alexandre.
I hoped I was clear before.
Take 4 cars, A, B, C, D separated by 100 meters each,
DO you know that in OCB the allowed power levels are much higher than in
WiFi? This has impact on your assumption that at 100m spacing between
pairs of cars is still ok with 4 cars: they all hear each other ok.
In OCB one can go as far as 800m between two cars in open outdoors,
safely. We did.
In some countries one can go even further. I would love to try this in
America where power levels can go up to 40dbm (i.e. maybe 2km).
So, if you try to make 4 cars in America to follow your pencil and paper
test you need maybe 8km distance. You need a few drivers to work for
you and as many programmers. You also need walkie-talkies. Can you get
that?
Alex
such that all
can hear C, though A has a bad quality, and A and D are too far
apart. C advertises a prefix in RA(PIO), all can hear it.
- Try pinging A from D using the address based on that prefix, won't
ping. - Try configuring A's address on D it will be accepted, which
means that DAD will not work either.
This is nothing new, common to all the short/middle range radios we
have looked at. You may try the same placing C at the corner of a
street, A and D in orthogonal streets. This has nothing to do with
low power and everything to do with radio propagation. The exception
is Wi-Fi, and that's because the BSS emulates the broadcast domain,
as I think I explained already. RFC 8505 recreates the Wi-Fi design
but at L3... and the use cases above were made to work on other
radios with similar properties. More in the 6TiSCH architecture I
guess...
Sorry you consumed all the time I could dedicate, and more.
All the best,
Pascal
-----Original Message----- From: Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx> Sent: lundi 15 avril 2019 15:35 To:
Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> Cc: Brian E
Carpenter <brian.e.carpenter@xxxxxxxxx>; NABIL BENAMAR
<n.benamar@xxxxxxxxxxxxx>; Sri Gundavelli (sgundave)
<sgundave@xxxxxxxxx>; nabil benamar <benamar73@xxxxxxxxx>;
ietf@xxxxxxxx; its@xxxxxxxx; int-dir@xxxxxxxx;
draft-ietf-ipwave-ipv6-over- 80211ocb.all@xxxxxxxx Subject: Re:
draft-ietf-ipwave-ipv6-over-80211ocb-38
Pascal - do you know of a OCB use and some scenario where ND does
not work?
(I mean some trials that you may have done with OCB; if you never
played with OCB and wiht IP on it, I think it makes no sense to
describe speculations of it).
Alex
Le 15/04/2019 à 08:53, Pascal Thubert (pthubert) a écrit :
This text is wrong, Alexandre.
There is a distinction between performance issue and does not
work. You
can not MUST a protocol that by design will only work in a subset
of the possible situations.
What you can do is document in which situations it can be made to
work
(P2P and full overlap of the broadcast domains) and explain the
drawbacks (eg if broadcast is sent at higher power or slower phy
then it impacts unicast communications).
Then you want to open the door to using more suitable techniques
in future
documents, which the MUST seems to discourage.
Regards,
Pascal
Le 14 avr. 2019 à 18:38, Alexandre Petrescu
<alexandre.petrescu@xxxxxxxxx> a écrit :
Brian,
Le 14/04/2019 à 04:20, Brian E Carpenter a écrit :
All we need is a simple statement in the spec which puts
some scope limits, w.r.t the missing ND pieces and
issues.
Yes, that is clearly essential, as well as an associated
health warning that implementers must not rush ahead because
of the risk of non-interoperability.
There is already paragraph, and an Appendix, about potential ND
issues. I
think that text qualifies as an associated health warning.
I do not know what do you mean about the risk of
interoperability. This ND
that works is interoperable between several OCB cards, IP Road Side
Units, and linuces. (I can cite brands that I al familiar with and
that interoperate.
This is the current paragraph and Appendix that qualify as a
warning that
you suggest:
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.
Alex
Regards Brian
On 14-Apr-19 13:58, NABIL BENAMAR wrote: +1 Sri
On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave)
<sgundave@xxxxxxxxx <mailto:sgundave@xxxxxxxxx>> 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"
<brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>>
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
