Le 15/04/2019 à 16:16, Charlie Perkins a écrit :
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.
I will avoid suggesting RFC8505 is only for low-power mesh. Ideally I
would like to know which power levels are used in these meshes, and
group them with the power levels in OCB, and maybe call them a range
where that RFC may apply.
* 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 agree, maybe both simulation and car use would be conclusive.
* 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?
'Directly', to me, means directly at networking layer (layer 3). To me,
it also means these link local addresses are present in the src and dst
fields of the first IP header of a packet.
The topologies with the hidden terminal problem: I did not see them in
practice.
The hidden-terminal problem was formulated for WiFi non-OCB.
I do not know how the hidden terminal problem works. I feel like if I
start looking into it I will grow additional white hairs. I feel like I
better avoid it.
I think other people have some experience with the hidden terminal
problem in non-OCB WiFi and 802.15.4. I am listening to them.
I think nobody has any experience with the hidden terminal problem in
OCB settings. I have some doubts, but still I think it is almost nobody.
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.
I think I agree in general.
I would like to discuss details:
- is it more reasonable to put the applicability statement in the IP-
over-OCB document, or in the vehicular-networking problem statement
document? I prefer the latter. If you prefer the former, please
tell where in the document.
- to put the number of vehicles in subnet is reasonable to qualify the
applicability statement. This should be in relationship with the max
power range and the assumed PHY propagation (antennas, etc.)
- the multicast aspects are referred to in the IP-over-OCB draft by
pointing to [I-D.ietf-mboned-ieee802-mcast-problems. I think this is
sufficient.
Maybe for clarity it would be helpful to include adiagram of a
general target network with more than three or four vehicles.
There is such a diagram in the vehicular-networking problem statement
draft. It is Figure 1. There are successive dots (like '...' expansion
dots) which suggest there are are more than a few vehicles.
Please read the draft.
Alex
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)
<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
.
_______________________________________________ its mailing list
its@xxxxxxxx https://www.ietf.org/mailman/listinfo/its
