Subject: [ipwave] Type/subType in little-edian (New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-18.txt)

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Feb 2018 09:43:04 +0200

Hi WG,

I maybe missed the discussion regarding the below,

draft>page 7>

The distinction between the two formats is given by the value of the

field "Type/Subtype". The value of the field "Type/Subtype" in the

802.11 Data header is 0x0020. The value of the field "Type/Subtype"

in the 802.11 QoS header is 0x0028.

AB> the HEX number shows 16 bit which is not number of bits for
virsion+type+subtype.

AB> if we use the little-edian order as described in section 9.2.2
(IEEE802.11-2016-std), and also in RFC1042, then we work the bits from
std-table-9.1, the 802.11 data header type= B2B3= 01,
subtype=B4B5B6B7=0000. Then this is in IEEE-Hex = 0x10.

AB> The 802.11 QoS data header type= B2B3= 01, subtype=B4B5B6B7=0001. Then
this is in IEEE-Hex = 0x11.

RFC1042>

The IEEE likes to specify numbers in bit transmission order, or bitwise
little-endian order.

The Internet protocols are documented in byte-wise big-endian order.

AB> in the std-doc the put the table-9.1 in Internet binary, but not IEEE
binary. However, section 9.2.2 describes.

AB> I prefer we let them like in the std-doc as bits in IEEE binary, but
not sure what WG thinks, please suggest,

Regards

AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Feb 2018 13:21:06 +0100

> AB> the HEX number shows 16 bit which is not number of bits for 

I agree with you.  There was an error in interpreting the dump.

I propose to better interpret the "Type/Subtype" as to be of length 6 
bits.  Leftmost 4 bits is Subtype and rightmost 2 bits is Type.

The Type is always of value 2, to mean Data frame.

The SubType is usually value 0, which means 802.11 Data.

Some times the Subtype is value 8.  This means this is 802.11 QoS Data.

As such, the text becomes:
>             The distinction between the two formats is given by the
>             value of the field "Subtype" in the Frame Control Field.
>             The value of the field "Subtype" in the 802.11 Data header
>             is 0x0.  The value of the field "Subtype" in the 802.11
>             QoS header is 8.

Unless, of course, we want to remove the description of this distinction 
between 802.11 QoS Data and 802.11 Data headers.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 23 Feb 2018 18:32:28 +0100

IPWAVErs,

The issue below is an important issue.

I want to ask the group which of 802.11 Data headers or 802.11 QoS Data
headers are more likely to be the right ones?  In order to RECOMMEND in
this draft to carry IP messages.

For my part I tend to prefer to recommend 802.11 Data (Subtype 0).

Many implementations of BSM in America and CAM and SPAT in Europe are
sent with 802.11 QoS Data headers (Subtype 8).  Numerous other
implementations of CAM and DENM in Europe are sent with 802.11 Data
headers instead (Subtype 0).

This means that a CAM sent by implementation of company X is not
understood by a CAM receiver open source rendits for example, because of
that difference in Subtype.

If we put that CAM on IP there will still be lack of interoperability,
unless we recommend IP to be carried by a particular 802.11 header (Data
or QoS Data).

Alex

Le 22/02/2018 à 13:21, Alexandre Petrescu a écrit :
>> The distinction between the two formats is given by the value of
>> the field "Subtype" in the Frame Control Field. The value of the
>> field "Subtype" in the 802.11 Data header is 0x0.  The value of the
>> field "Subtype" in the 802.11 QoS header is 8.
> 
> Unless, of course, we want to remove the description of this
> distinction between 802.11 QoS Data and 802.11 Data headers.
> 
> Alex
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Feb 2018 09:38:51 -0800

> unless we recommend IP to be carried by a particular 802.11 header (Data

I would propose that we use the Data header. My experience with the QoS Data with Wi-Fi was that there wasn’t enough of a performance difference with QoS for it to make a difference to the IP layer.

Tony

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 23 Feb 2018 21:16:11 +0100

Hi Alex,

If we consider ETSI (and I guess WAVE), the use of 802.11 QoS is due to the requirements of the Traffic Classes as LL priorization (DENM priority over basic CAM and priority over long CAM etc..). This is also required by the DCC implementation and the CAR 2 CAR profile in EU. 

Now, as you abstract ETSI and WAVE (thus pure IP), my understanding is that QoS remains required from the IEEE 802.11p (ok, IEEE 802.11-2016 OCB) as there is a specification of the EDCA parameters for OCB. Besides, I do not think it costs much to keep the EDCA in, as it first allows to safe a half of the MAC queueing time (the EDCA parameters for the two low AC are less, up to a quarter of a DIFS...so, it could be beneficial to allow this even for IP. Second, the EDCA allows TXOpps (Transmit Opportunities)..although put to 'zero' for OCB (I think), this mechanism still allows an AP to reserve a given time a long(er) connectivity with one device (e. streaming of video etc..). Finally, it does not cost anything..you can always take the lowest AC and you get the same behavior as non-QoS..

Bottom line, the fact that some IP implementation to decode OCB assume non-QoS frames looks more to me like an implementation error and we should not propagate this...

Btw, I remains really not convinced of the use of CAM over IP..this is a recurring discussion over the thread...C-V2X will not use IP for CAM, ETSI and WAVE will not use IP for CAM...the basic CAMs are used for pure positioning and the recent 'increase' of information put in CAM looks to be like a bad strategy as we end up having a container carrying too many things and being too big for what it is...(WLAN is good at squeezing various small packets but really not good at big things especially in broadcast mode)...a better strategy would be to define new messages tailored to the information needs, and have smart service scheduling...(especially benefiting from IP-related mechanisms)

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 23 February 2018 18:32
To: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

IPWAVErs,

I want to ask the group which of 802.11 Data headers or 802.11 QoS Data headers are more likely to be the right ones?  In order to RECOMMEND in this draft to carry IP messages.

Many implementations of BSM in America and CAM and SPAT in Europe are sent with 802.11 QoS Data headers (Subtype 8).  Numerous other implementations of CAM and DENM in Europe are sent with 802.11 Data headers instead (Subtype 0).

This means that a CAM sent by implementation of company X is not understood by a CAM receiver open source rendits for example, because of that difference in Subtype.

If we put that CAM on IP there will still be lack of interoperability, unless we recommend IP to be carried by a particular 802.11 header (Data or QoS Data).

Alex

Le 22/02/2018 à 13:21, Alexandre Petrescu a écrit :
>> field "Subtype" in the Frame Control Field. The value of the field 
>> "Subtype" in the 802.11 Data header is 0x0.  The value of the field 
>> "Subtype" in the 802.11 QoS header is 8.
> 

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 23 Feb 2018 21:21:50 +0100

HI Tony,

The word QoS is misleading in WiFi…it is not QoS and is only a prioritization of different ‘classes’ of traffic. I am surprised though that IP could not benefit much from it…maybe was it due to TCP? I mean, TX opp are a really beneficial aspect if you need to advantage one MN over others.

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Friday 23 February 2018 18:39
To: Alexandre Petrescu
Cc: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

 

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Feb 2018 12:32:20 -0800

> The word QoS is misleading in WiFi…it is not QoS and is only a prioritization of different ‘classes’ of traffic. I am surprised though that IP could not benefit much from it…maybe was it due to TCP…

For prioritization to have any significant effect on IP, you need consistent QoS treatment end-to-end, which the Internet simply does not provide. Further, the queues that build up on the Wi-Fi AP weren’t ever sufficient to cause any useful prioritization. 

The downside, of course, is the larger header size with QoS.

Tony

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 23 Feb 2018 12:40:11 -0800

Jerome,

> IP could not benefit much from it…

??  Was IP using diff-serv?  It would seem that if you are going to
shuffle queues (sort traffic) at layer 2, you need to at layer 3 as
well.  And the sorting flags need to be coherent at both layers??

On Fri, 2018-02-23 at 21:21 +0100, Jérôme Härri wrote:
> HI Tony,
>  
> The word QoS is misleading in WiFi…it is not QoS and is only a
> prioritization of different ‘classes’ of traffic. I am surprised
> though that IP could not benefit much from it…maybe was it due to
> TCP? I mean, TX opp are a really beneficial aspect if you need to
> advantage one MN over others.
>  
> BR,
>  
> Jérôme
>  
> I would propose that we use the Data header. My experience with the
> QoS Data with Wi-Fi was that there wasn’t enough of a performance
> difference with QoS for it to make a difference to the IP layer.
>  
> Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 24 Feb 2018 12:55:31 +0100

The header is called "802.11 QoS Data" by wireshark.  I find the use of 
"QoS" in line with the use of "traffic classes".

IP _could_ benefit from it, but in order to describe a mapping, it 
should be in another document.  Such mappings are not currently 
developped nor implemented (e.g. map a Traffic Class field in the IP 
header into a traffic class field in the 802.11 QoS Data header).

Alex

Le 23/02/2018 à 21:21, Jérôme Härri a écrit :
> prioritization of different ‘classes’ of traffic. I am surprised though 
> that IP could not benefit much from it…maybe was it due to TCP? I mean, 
> TX opp are a really beneficial aspect if you need to advantage one MN 
> over others.
> 
> BR,
> 
> Jérôme
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Tony Li
> *Sent:* Friday 23 February 2018 18:39
> *To:* Alexandre Petrescu
> *Cc:* [email-masked]
> *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in 
> IPv6-over-802.11-OCB
> 
> 
> 
> I would propose that we use the Data header. My experience with the QoS 
> Data with Wi-Fi was that there wasn’t enough of a performance difference 
> with QoS for it to make a difference to the IP layer.
> 
> Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 24 Feb 2018 13:53:35 +0100

Le 23/02/2018 à 21:16, Jérôme Härri a écrit :
> Hi Alex,
> 
> If we consider ETSI (and I guess WAVE), the use of 802.11 QoS is due 
> to the requirements of the Traffic Classes as LL priorization (DENM 
> priority over basic CAM and priority over long CAM etc..). This is 
> also required by the DCC implementation and the CAR 2 CAR profile in 
> EU.

That is a requirement.

But is there an implementation of mapping the priority of CAM over DENM
into a QoS Control field in QoS Data Header?

I doubt there is, because the implementations of CAM I see put the
Priority field to 6, which means Voice.  So they transmit CAM as Voice
even though it is not voice.

We can not reckon in IPv6-over-OCB document something which makes little
sense (send CAM as Voice).

> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding 
> is that QoS remains required from the IEEE 802.11p (ok, IEEE 
> 802.11-2016 OCB) as there is a specification of the EDCA parameters 
> for OCB. Besides, I do not think it costs much to keep the EDCA in, 
> as it first allows to safe a half of the MAC queueing time (the EDCA 
> parameters for the two low AC are less, up to a quarter of a 
> DIFS...so, it could be beneficial to allow this even for IP. Second, 
> the EDCA allows TXOpps (Transmit Opportunities)..although put to 
> 'zero' for OCB (I think), this mechanism still allows an AP to 
> reserve a given time a long(er) connectivity with one device (e. 
> streaming of video etc..). Finally, it does not cost anything..you 
> can always take the lowest AC and you get the same behavior as 
> non-QoS..

Well, this text is more informal in nature.   It is something that
describes a potential behaviour but we have no proof of existing such
behaviour, no proof of interoperability.  This could be part of an
INFORMATIONAL Internet Draft.

> Bottom line, the fact that some IP implementation to decode OCB 
> assume non-QoS frames looks more to me like an implementation error 
> and we should not propagate this...

Well, wireshark has problems interpreting 802.11 QoS Data containing CAM
messages.  Many receivers of QoS Data dont know what to do with the
fields because they are not agreed.

I dont want to propagate that disagreement into the IP-over-OCB draft.

> Btw, I remains really not convinced of the use of CAM over IP..this 
> is a recurring discussion over the thread...

Yes, it is recurring.

> C-V2X will not use IP for CAM,

LTE-V2X will carry CAM in IP.  What is C-V2X and why does not it use IP?

> ETSI and WAVE will not use IP for CAM...

That is their problem.

ETSI transports IP over GeoNetworking - that is not the right way to do it.

> the basic CAMs are used for pure positioning

The mandatory fields in CAM or more than just lat/long/altitude.  There
is also mandatory time in a strange format, car dimensions, curve, non
standard precisions and more.

> and the recent 'increase' of information put in CAM

If CAM worries about size, I think CAM should think about its existing
redundancy.  For example, position is carried twice in a CAM message: in
the CAM itself and in the GeoNetworking header.  That is an issue they
should address first.

> looks to be like a bad strategy as we end up having a container 
> carrying too many things and being too big for what it is...

I agree.  But I think we should compare header sizes and then there will
be surprises.

CAM transported in IP may be a smaller packet than CAM transported in
BTP and GeoNetworking.

> (WLAN is good at squeezing various small packets but really not good
> at big things especially in broadcast mode)...a better strategy would
> be to define new messages tailored to the information needs, and have
> smart service scheduling...(especially benefiting from IP-related 
> mechanisms)

I fully agree with this.

Alex

---

From: Russ Housley <[email-masked]>
Date: Sat, 24 Feb 2018 14:55:26 -0500

> well.  And the sorting flags need to be coherent at both layers??

Indeed.  Without specifying the linkage between the IEEE 802.11 QoS and DiffServ code points, there will not be any significant value.

If memory serves, there was recently sone discussion about DiffServe in 6man.  However, I do not know if the work being done there would cover this situation.

Russ

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 24 Feb 2018 23:22:15 +0200

> this draft to carry IP messages.

why or, why not data and QoS data? Why right or wrong way of thinking?
Could we think any upper layer have many options for many usecases within
ITS applications.

> headers instead (Subtype 0).

What about performance considerations, it is not known yet, but I think it
is better to consider that if we take the data header only approach that
means we may not be using MAC layer's services which can open a question.

> that difference in Subtype.

No, there is communication between nodes for interoperability for each
layer,

> unless we recommend IP to be carried by a particular 802.11 header (Data

I think using QoS data header is optional, and if used can make advantages
for ip transmission.

AB

---

From: Rex Buddenberg <[email-masked]>
Date: Sat, 24 Feb 2018 17:02:42 -0800

in line

On Sat, 2018-02-24 at 23:22 +0200, Abdussalam Baryun wrote:
> 
> 
> On Fri, Feb 23, 2018 at 7:32 PM, Alexandre Petrescu <alexandre.petres
> [email-masked]> wrote:
> > IPWAVErs,
> > 
> why or, why not data and QoS data? Why right or wrong way of
> thinking? Could we think any upper layer have many options for many
> usecases within ITS applications.
> 
What do you mean by 'QoS data'?  Beware. both qos and QoS have several
meanings, particularly if you haven't done your definition homework.

First.  qos (that experienced) at layer 3 is first-in, first-out of a
router.  If you want to change that, then diff-serv provides QoS
control -- you can sort packets according to the DSCP into four bins
which are then drained in order.

Second.  But think about this in the context of radio-WAN --> wired
(usually fiber) terrestrial WAN (v to i, if you must).  The terrestrial
WAN is provisioned in 10s of Gbits while the radio provides Mbits of
data -- one 10,000th of the capacity of the fiber.  If there's no
congestion on the fiber there is no QoS control mechanism on the planet
that can improve qos.  Coversely, there are several ways to make things
worse. One, ironically, is to turn on diff-serv and spend CPU cycles
sorting datagrams rather than sending the %%^&&*( traffic.  

Second, there are a couple ways to 'implement QoS' in the radio-WAN
(layer 2).  
     If you have the carrier-sense multiple access MAC that defines
both 802.3 and 802.11, then about the only thing you can do is mark a
frame as more urgent than the others (perhaps by setting something
congruent with DSCP).  That doesn't get it onto the network any faster,
and if the router-and-upstream is overprovisioned anyway, you get no
benefit.
     On the other hand, if you have a scheduling MAC like that in LTE
or IEEE 802.16, you have a hatful of ways to define, and implement QoS
control.  There are more knobs on the standards than anyone will ever
use.  At least one of the possible ways to tickle QoS control is for
the base station to give a needy (and urgent) subscriber station a
larger transmit window.  (some of my students and I once tried to map
these coherently onto diff-serv categories; gave up in frustration).

Thirdly, be careful what you ask for.  In the original IP specification
there was an entire byte marked for 'QoS'.  It was never defined (and
in practice, capacity on the internet gained faster than congestion),
so there wasn't much point.  At one point DISA (Defense Information
System Agency, owner of DoD's part of the internet) proposed 2^8
different sort bins -- after all, that's the number of bits we have
available! (Imagine the CPU cycles spent sorting THAT ... for every
datagram).   Diff-serv defines four which is about right.  The old
naval message system defined five precedence categories.  

> What about performance considerations, it is not known yet, but I
> think it is better to consider that if we take the data header
> only approach that means we may not be using MAC layer's services
> which can open a question. 
> > 
> No, there is communication between nodes for interoperability for
> each layer,
> 
> 
> > 
> I think using QoS data header is optional, and if used can make
> advantages for ip transmission.
> 
> AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 25 Feb 2018 18:58:26 +0100

> with QoS for it to make a difference to the IP layer.

I agree.

I propose the following text.

OLD:
>    In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11
>    Data" or alternatively as "IEEE 802.11 QoS Data", as illustrated in
>    Figure 2.

NEW:
>    In OCB mode, it is RECOMMENDED to transmit IPv6 packets as "IEEE
>    802.11 Data" (the value of the field Subtype in the Frame Control
>    Field is 0).

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 26 Feb 2018 10:04:36 +0200

The experience test you referred to is not clarified, was it a ITS
environment experience or was it a fixed wireless experience. Furthermore,
the WiFi technology ieee802.11 is developed so which WiFi technology was
used. Moreover, did your experience use Video and voice communication or
your proposal is only for data communication only.

So if your IP packet are data then your experience is right, but if the IP
packet is carrying voice or video I don't agree. IMO we could not exclude
from the draft voice and video communication in the ITS
environment/use-case.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 26 Feb 2018 10:22:08 +0200

> sorting datagrams rather than sending the %%^&&*( traffic.

I only now am thinking point to point in MAC layer, let us don't go out of
the draft's use-case. Why you are thinking of the PHY layer in terms of
CPU, while we should think about the unstable physical links and capacity.

> and if the router-and-upstream is overprovisioned anyway, you get no

We need to discuss only 802.11 OCB, and I think we need fastest as
possible, and MAC layer does fragmentation for faster purposes and sends
frames in parallel MIMO,

> these coherently onto diff-serv categories; gave up in frustration).

The 802.11-2016 already defined the windows for OCB which is different from
BSS, so why not use its capabilities of QoS,

>
>
> Thirdly, be careful what you ask for.

I don't ask for any thing, the user of IP will ask us, we provide the
optional use of QoS use-cases,

>  In the original IP specification

I don't agree, I think ITS has a variable link capacity which is not
stable, but you are referring to stable capacity and connections.

AB

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Mon, 26 Feb 2018 09:37:20 +0100

Be careful with voice and audio transmission in ITS using 5,9 GHz. That 
seems to be prohibited by regulation in Europe; well, not explicitly, 
but this is a possible interpretation of the technical requirements 
presented in regulatory documents. In Germany, it is prohibited.

Hans-Joachim

Am 26.02.2018 um 09:04 schrieb Abdussalam Baryun:
> environment experience or was it a fixed wireless experience. 
> Furthermore, the WiFi technology ieee802.11 is developed so which WiFi 
> technology was used. Moreover, did your experience use Video and voice 
> communication or your proposal is only for data communication only.
>
> So if your IP packet are data then your experience is right, but if 
> the IP packet is carrying voice or video I don't agree. IMO we could 
> not exclude from the draft voice and video communication in the ITS 
> environment/use-case.
>
> On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>
>         I would propose that we use the Data header. My experience
>         with the QoS Data with Wi-Fi was that there wasn’t enough of a
>         performance difference with QoS for it to make a difference to
>         the IP layer.
>
>
>     I agree.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>

-- 
Dr. Hans-Joachim Fischer
Managing Director

--------------------------------------------------------------------------------

                ESF News edition 2018/1
https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf

--------------------------------------------------------------------------------
       Towards deployment of C-ITS based on proven technology
Avoid risks and delay by looking on potential future technologies.

                The real advocate on ITS is ISO TC204!
--------------------------------------------------------------------------------
+ + + Instaurare omnia in Christo + + +
--------------------------------------------------------------------------------
The information contained in this message is confidential and may be legally
privileged. This email is intended for the addressee(s). Addressees may be
individual persons or members of mailing list.
If you are not an addressee, you are hereby notified that any use,
dissemination, or reproduction of this email and its optional attachements is
strictly prohibited and may be unlawful. If you are not an addressee, please
contact the sender by return e-mail and destroy all copies of the original
message.
--------------------------------------------------------------------------------
ESF GmbH
Fichtenweg 9
89143 Blaubeuren
+49 (7344) 175340 (Direct line Dr. Fischer)
+49 (7344) 919188 (Central office)
+49 (7344) 919123 (Fax)
https://fischer-tech.eu :  Main web of ESF GmbH
http://its-standards.eu : News on cooperative ITS standardization
http://its-testing.org :  International consultancy for cooperative ITS
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
ESF online-news:        http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:      http://its-standards.info/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
-------------------------------------------------------------------------------

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 10:24:54 +0100

Hi Alex,

> That is a requirement.
>
> But is there an implementation of mapping the priority of CAM over DENM into a QoS Control field in QoS Data Header?
>
> I doubt there is, because the implementations of CAM I see put the Priority field to 6, which means Voice.  So they transmit CAM as Voice even though it is not voice.
>
> We can not reckon in IPv6-over-OCB document something which makes little sense (send CAM as Voice).

Of course there is....the QoS fields actually means the Access Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority (from a MAC perspective)...When looking at the EDCA 'naming' you should not care much of the 'name'...this was done at the time internet was only composed of voice, video etc..you should look at the underlying values of each AC.

So, EDCA is composed of two fields:
1) AIFN - a deterministic idle time before even considering reducing CW
2) CW - a random timer to decrease each time the channel is idle. 

QoS Data combinations for OCB:
AC_VO: AIFN=2, CW=8
AC_VI: AIFN=2, CW=16
AC_BE: AIFN=3, CW=32
AC_BK: AIFN=7, CW=32

So, it does not matter the name (Voice, video)..what matters is that in implementation (BSM for instance), AIFN=2 so that it takes the fastest access (deterministic) and as such has the highest priority. This is also what you found: CAM on Priority field 6, so AC_VI so AIFN=2. BSM uses the same strategy. 

Now, on the CAR 2 CAR specification, it is recommended a different priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR provides a 'strict' prioritization between DENMs and CAMs. Emergency DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other traffic AC_BK.

So, bottom line is: all ETSI and WAVE implementation use the QoS Data field as they use EDCA. If you found an implementation that does not use the QoS, it is wrong according to the standard.

>> Now, as you abstract ETSI and WAVE (thus pure IP), my understanding is 
>> that QoS remains required from the IEEE 802.11p (ok, IEEE
>> for OCB. Besides, I do not think it costs much to keep the EDCA in, as 
>> it first allows to safe a half of the MAC queueing time (the EDCA 
>> 'zero' for OCB (I think), this mechanism still allows an AP to reserve 
>> a given time a long(er) connectivity with one device (e.
>> streaming of video etc..). Finally, it does not cost anything..you can 
>> always take the lowest AC and you get the same behavior as non-QoS..

>describes a potential behaviour but we have no proof of existing such behaviour, no proof of interoperability.  This could be part of an INFORMATIONAL Internet Draft.

Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think anything is required from IETF...just follow the IEEE 802.11-2016 specs and do whatever is allows above it...I will double check again on the IEEE 802.11-2016, but if what I think is confirmed, the whole discussion does not make any sense..., as it is my understanding that the OCB requires EDCA, so QoS_Data...so, you cannot change that at IP level.

>> Bottom line, the fact that some IP implementation to decode OCB assume 
>> non-QoS frames looks more to me like an implementation error and we 
>> should not propagate this...

>Well, wireshark has problems interpreting 802.11 QoS Data containing CAM messages.  Many receivers of QoS Data dont know what to do with the fields because they are not agreed.

Yes, and this is why is the prototype we use, we actually have an parser for CAM to be supported by Wireshark...it does not come by default. But I am surprised..what kind of problem would wireshark face with the QoS Data? 

> I don't want to propagate that disagreement into the IP-over-OCB draft.

To me, this looks more like an implementation issue, rather than a standard issue...but I will ask my team to check on our prototype...

>LTE-V2X will carry CAM in IP.  What is C-V2X and why does not it use IP?

Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but might have changed), there is two options for protocol stack: IPv6 (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it is so mentioned that BSM and CAM will use the non-IP option, as it is also required to use the ETSI/WAVE security provisions to secure the C-V2X mode 4 (as no SIM= no security), as the ETSI/WAVE security provisions works for non-IP packets (geonet or WSM)...

Of course, it does not block from using IP...it is again the same discussion we had with ITS-G5/DSRC...for safety communication, IP is not required...you can do everything without and faster. And considering that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=no SEC) DO NOT have any form of security mechanism embedded, they must use the those specified by ETSI/WAVE for accessing CCH.

Again, C-V2X mode 4 (the current V2X techno for Safety-critical communication) shall not be seen as following the same path as other cellular techno. It does not provide QoS (at all), as it channel access is contention-based (a bit like CSMA)...so collisions will occur (unlike 4G and 5G operated, where you are either dropped or you pass). And as such, IP is also not required, even if all 4G and 5G use IP.

>That is their problem.

Disagree: you need to be compatible with them...so, whatever IETF will do shall not break anything that has been done on ETSI or WAVE. This is one of the requirement for accessing the ITS-G5 spectrum in EU, and I believe the same in the US.

>ETSI transports IP over GeoNetworking - that is not the right way to do it.

Disagree: we need to integrate security mechanisms specified by ETSI even if we use IPv6. Today, we do not have any security specification providing 'trust', privacy and authentication for using 802.11-OCB (I believe it is the work of IPWAVE and it is not completed yet...). 
The mistake ETSI did is to try to be nice with IETF and help them to provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a different path: 'not my problem', which then explain why ETSI officially does not endorse IPWAVE (unfortunately, despite my many discussions with them)...from an ETSI perspective, using IPv6 over ITS-G5 is solved...(might be ugly, but it is solved).

>The mandatory fields in CAM or more than just lat/long/altitude.  There is also mandatory time in a strange format, car dimensions, curve, non standard precisions and more.

Yes, correct...but these are configurable fields, which may or may not be integrated...recent studies even showed that even the standard CAM size is not clear anymore..you have a 'range' of size, and that is a problem for wireless optimization...especially if you need to do wireless congestion control.

>If CAM worries about size, I think CAM should think about its existing redundancy.  For example, position is carried twice in a CAM message: in the CAM itself and in the GeoNetworking header.  That >is an issue they should address first.

Well, of course, this is a waste...but one reason for such existence is from the possibility to relay a packet (agnostic from the upper messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure 1-hop TSB)...
Yet, today we start seeing even BSM investigating ways to do multi-hop 'position' based relaying to reach longer distance. 

And if you think about it, one day, your IPv6-over-OCB might need to use a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is highly mobile environment will not be that efficient...position-based mechanisms will be required (proven in various previous studies)...now, your L3 will not be able to inspect the GPS position of your CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, which will end up being similar than now...

If you do not want to do this, then the IRTF people might come with ICN, but then would this be done above L3 or at L3...if still at L3, you still will have a contextual L3 packet that might be redundant with application/service layer messages...(the cost of using OSI)

But this is just my personal view and very long term...for now, if we only look at CAM, indeed we can have twice the GPS position (but wait: not the same granularity and you do not have elevation in geonet). But if you look at  the bigger picture: doing CAM-over-geonet only required a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 address autoconfiguration..that requires additional IPv6 packets to be transmitted...this is similar to compare an apple with a tomato.

>I agree.  But I think we should compare header sizes and then there will be surprises.
>CAM transported in IP may be a smaller packet than CAM transported in BTP and GeoNetworking.

Not that much if you counts also all IPv6-related control/management packets required to transmit your CAM-over-OCB, in a highly dynamic environment...

> I fully agree with this.

:-) at least we do on this :-)

Cheers,

Jérôme

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 10:34:29 +0100

>From: its [mailto:[email-masked]] On Behalf Of Dr. Hans-Joachim Fischer
>

>Be careful with voice and audio transmission in ITS using 5,9 GHz. That seems to be prohibited by regulation in Europe; well, not explicitly, but this is a possible >interpretation of the technical requirements presented in regulatory documents. In Germany, it is prohibited.

>Hans-Joachim

Sorry to come again on this…this is a big misunderstanding…there is NO audio and NO video transmitted…

It is just that the WiFi uses AC with old names…which ETSI and WAVE uses for something else…let’s describe it so:

At L2, there is 4 access categories, with proven properties in channel access (I do not want to go in that direction, but there is plethora of publications showing the impact of using EDCA and unfair access if different WLAN uses DCF and others uses EDCA). 

At L2, 

-          AC_1 (VO) provides the highest channel access priority

-          AC_2 (VI) provides the second highest channel access priority

-          AC_3 (BE) provides a neutral access priority

-          AC_4 (BK) provides the lowest access priority

A L3 packet must be mapped to one of these 4 access categories (whatever their names). 

It is a high(er) layer decision to do the mapping, as WLAN will only look at the priority field and map (no question asked). 

Thus, a higher layer is forbidden to transmit VI traffic, but not to use AC_VI if another type of traffic needs this level of priority. 

Hoping it is clearer now,

BR,

Jérôme

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 10:41:11 +0100

Oh, and forgot to mention that there is a clear mapping in 802.11-2016 between the 7-bits priority field (802.1D) and the 4 queues…nothing to do here.

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Monday 26 February 2018 10:34
To: 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'; 'Alexandre Petrescu'
Cc: 'Tony Li'; 'its'
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

At L2, 

BR,

Jérôme

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 12:38:36 +0100

Hi Alex, All,

After double checking IEEE802.11-2016, here are two aspects I need to correct (sorry for my mistake)L:
1) both data and QoSData are allowed when Dot11OCBActivated=true;
2) EDCA parameters were wrong ( I wrongly used the nonOCB ones)

QoS Data combinations for OCB:
AC_VO: AIFN=2, CWmin=4 CWmax=8 
AC_VI: AIFN=3, CWmin=8 CWmax=16
AC_BE: AIFN=6, CWmin=16 CWmax=1024
AC_BK: AIFN=9, CWmin=16 CWmax=1024

Both Data and QoSData are theoretically possible, so indeed the draft should cover this aspect. 

Yet, I still suggest to keep QoS for IPv6, again as even if it does not bring much 'now' for IPv6, it does not cost much either...and we should not forgot that we might interact with EDCA transmissions (QoS) and as such could create harmful interference on the DSRC/ITS-G5 channels.

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Monday 26 February 2018 10:25
To: 'Alexandre Petrescu'; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Hi Alex,

>> can always take the lowest AC and you get the same behavior as non-QoS..

  

 

Cheers,

Jérôme

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 26 Feb 2018 13:16:49 +0100

Hi,

see inline.

> Indeed.  Without specifying the linkage between the IEEE 802.11 QoS and DiffServ code points, there will not be any significant value.

There is such a document, it was recently published as RFC:
Mapping Diffserv to IEEE 802.11
https://datatracker.ietf.org/doc/rfc8325/

> If memory serves, there was recently sone discussion about DiffServe in 6man.  However, I do not know if the work being done there would cover this situation.

Cheers
 Roland

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Feb 2018 13:26:43 +0100

> 1) both data and QoSData are allowed when Dot11OCBActivated=true;

Yes, IEEE allows for both alternatives.

The Data alternative is what open-source implementations do.  (the OCB 
mode in linux kernel).

The QoSData alternative is what many closed-source non-IP stacks do.

> AC_BK: AIFN=9, CWmin=16 CWmax=1024

Thanks for the detail.

> Both Data and QoSData are theoretically possible, so indeed the draft should cover this aspect.

I agree both are theoretically possible, but I dont know whether the 
draft should cover both.

On my side, I do not know how these QoSData headers are generated by 
software, because I have no access to that software.  It is closed 
source.  I know some of the company names doing it.

On another hand, the Data headers are open source, so we know how they 
are generated.

> Yet, I still suggest to keep QoS for IPv6, 

Well, how about keeping just an entry point for QoSData now, to speed to 
IESG, and later write a document about IPv6-over-OCB-QoS.

> again as even if it does not bring much 'now' for IPv6, it does not
> cost much either...and we should not forgot that we might interact
> with EDCA transmissions (QoS) and as such could create harmful
> interference on the DSRC/ITS-G5 channels.

If there is interference, it is because IEEE allows both Data and 
QoSData; it is not because IP prefers Data.

Here I am more afraid of lack of interoperability, rather than of 
interference.  Some stacks are not interoperable because of these Data 
vs QoSData assumptions.

github.com/rendits does not interoperate with company X and Y, nor 
vice-versa, because of these Data vs QoSData.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 13:31:50 +0100

Excellent...

Thanks Roland..

I think we should mention this in this IPv6-over-OCB draft...

BR,

Jérôme

-----Original Message-----
From: Bless, Roland (TM) [mailto:[email-masked]] 
Sent: Monday 26 February 2018 13:17
To: Russ Housley; Rex Buddenberg; Jérôme Härri; Tony Li; Alexandre Petrescu
Cc: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Hi,

see inline.

Cheers
 Roland

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Feb 2018 14:16:22 +0100

> I think we should mention this in this IPv6-over-OCB draft...

Right now the draft mentions draft-ietf-tsvwg-ieee-802-11-11 which is a 
precursor of that RFC.  I could update it to the RFC number if necessary.

draft says:
>    The mapping between qos-related fields in the IPv6 header (e.g.
>    "Traffic Class", "Flow label") and fields in the "802.11 QoS Data
>    Header" (e.g.  "QoS Control") are not specified in this document.
>    Guidance for a potential mapping is provided in
>    [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB
>    mode.

The existence of that RFC8325 does not solve the interoperability problem.

If we continue to say that IPv6 could be sent either as QoSData, or 
alternatively as Data, any day someone will send it differently than the 
others can receive.

If, on the other hand, the linux kernel implemented QoSData in an open 
source code, and that it worked fine, then I could agree with you.  But 
up to now I feel like the QoSData is implemented _only_ by closed-source 
proprietary code to which I have no access.

If someone could show a packet dump of an IPv6 packet carried with 
802.11 QoSData header, then I would agree to document it in this draft.

Alex

---

From: François Simon <[email-masked]>
Date: Mon, 26 Feb 2018 11:12:31 -0500

If this comment relates to the access category (AC): background (BK), best effort (BE), video (VI) and voice (VO), it is derived from IEEE 802.1D which indicates a list of “traffic type that can benefit from segregation from the others and seems to command wide spread support”. The four access categories: AC_BK, AC_BE, AC_VI, and AC_VO defined in OCB are derived from the 802.1D list.  This is just INFORMATIVE and does not implies any restriction.  The naming as been retained to represent priorities: AC_BK – lowest priority and AC_VI – highest priority; Any 802.11 data or 802.11 QoS data can be assigned any of the four priorities.   Fygs

From: its [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: Monday, February 26, 2018 3:05 AM
To: Alexandre Petrescu <[email-masked]>
Cc: Tony Li <[email-masked]>; its <[email-masked]>
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

The experience test you referred to is not clarified, was it a ITS environment experience or was it a fixed wireless experience. Furthermore, the WiFi technology ieee802.11 is developed so which WiFi technology was used. Moreover, did your experience use Video and voice communication or your proposal is only for data communication only.

So if your IP packet are data then your experience is right, but if the IP packet is carrying voice or video I don't agree. IMO we could not exclude from the draft voice and video communication in the ITS environment/use-case. 

On Sun, Feb 25, 2018 at 7:58 PM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]> > wrote:

I agree.

OLD:

NEW:

Alex

---

From: François Simon <[email-masked]>
Date: Mon, 26 Feb 2018 11:18:53 -0500

AC_VO (voice) is only a label indicating the highest priority; nothing more is implied.

From: its [mailto:[email-masked]] On Behalf Of Dr. Hans-Joachim Fischer
Sent: Monday, February 26, 2018 3:37 AM
To: Abdussalam Baryun <[email-masked]>; Alexandre Petrescu <[email-masked]>
Cc: Tony Li <[email-masked]>; its <[email-masked]>
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Be careful with voice and audio transmission in ITS using 5,9 GHz. That seems to be prohibited by regulation in Europe; well, not explicitly, but this is a possible interpretation of the technical requirements presented in regulatory documents. In Germany, it is prohibited.

Hans-Joachim

I agree.

OLD:

NEW:

Alex

-- 
Dr. Hans-Joachim Fischer
Managing Director

               ESF News edition 2018/1

---

From: François Simon <[email-masked]>
Date: Mon, 26 Feb 2018 11:22:06 -0500

Correct !

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Monday, February 26, 2018 4:25 AM
To: 'Alexandre Petrescu' <[email-masked]>; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Hi Alex,

  

 

Cheers,

Jérôme

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Feb 2018 17:22:41 +0100

> AC_VO (voice) is only a label indicating the highest priority; nothing 

YEs, sure, but imagine someone sends real voice; that will compete with 
CAM 'voice' - we dont want that either :-)

In such situation, what one would like in standards is to see 'highest 
priority' instead of 'voice'.

Alex

> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Dr. Hans-Joachim 
> Fischer
> *Sent:* Monday, February 26, 2018 3:37 AM
> *To:* Abdussalam Baryun <[email-masked]>; Alexandre Petrescu 
> <[email-masked]>
> *Cc:* Tony Li <[email-masked]>; its <[email-masked]>
>     Furthermore, the WiFi technology ieee802.11 is developed so which
>     WiFi technology was used. Moreover, did your experience use Video
>     and voice communication or your proposal is only for data
>     communication only.
> 
>             with the QoS Data with Wi-Fi was that there wasn’t enough of
>             a performance difference with QoS for it to make a
>             difference to the IP layer.
> 
> 
>         I agree.
> 
> ESF online-news:http://fischer-tech.eu/Feeds/esf.rss
> 
> C-ITS online news:http://its-standards.info/Feeds/cits.rss
> 
> ESF Online Nachrichten:http://fischer-tech.de/Feeds/esfD.rss
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Feb 2018 17:40:53 +0100

> Correct !

Is there a mapping between the Access Categories and IPv6 Traffic Class 
fields?

RFC8200:
> 3.  IPv6 Header Format
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |Version| Traffic Class |           Flow Label                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |         Payload Length        |  Next Header  |   Hop Limit   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +                         Source Address                        +
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +                      Destination Address                      +
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       Version             4-bit Internet Protocol version number = 6.
> 
>       Traffic Class       8-bit Traffic Class field.  See Section 7.
> 
>       Flow Label          20-bit flow label.  See Section 6.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 17:41:59 +0100

Hi Alex,

Well, from the IP layer, what you see is a 7 bit User Priority, nothing else..feel free to label the 7 UP as you want....how it is translated is L2 business (and naming..)..so we should not care much about the names.

Now, you raised an issue (that was also identified by other OCB people reading the thread..and will probably also provide feedback soon) is the coexistence between traffic.

CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI. Event-based BSM uses AC_VI and non-even-based BSM uses AC_BE (I think)...so, if you send IPv6 traffic with DCF (where DIFS = 2, same as AC_VI), then you will compete directly with  DENM and event-based BSM, which is * very* problematic...thus my suggestion to keep QoSData so that we at least have an option to avoid interfering with CAM/DENM.

Now, if you want to transmit CAM with IPv6-over-OCB, then you 'clearly' needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE CAM/BSM have the same L2 'priority' in accessing the channel, otherwise you risk creating harmful interference and packet collisions.

BR,

Jérôme 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday 26 February 2018 17:23
To: François Simon; 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'
Cc: 'Tony Li'; 'its'
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

> AC_VO (voice) is only a label indicating the highest priority; nothing 

YEs, sure, but imagine someone sends real voice; that will compete with CAM 'voice' - we dont want that either :-)

In such situation, what one would like in standards is to see 'highest priority' instead of 'voice'.

Alex

> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Dr. 
> Hans-Joachim Fischer
> *To:* Abdussalam Baryun <[email-masked]>; Alexandre 
> Petrescu <[email-masked]>
> Be careful with voice and audio transmission in ITS using 5,9 GHz. 
> That seems to be prohibited by regulation in Europe; well, not 
> explicitly, but this is a possible interpretation of the technical 
> requirements presented in regulatory documents. In Germany, it is prohibited.
> 
> Hans-Joachim
>

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 17:47:03 +0100

Hi Alex, All,

Made a minor mistake: the 802.1D UP are actually 8 values, 0-7. So 8 bits, and accordingly you can directly map the IPv6 TC to the UP...there is a spec in ETSI for that, but not sure if there is one spec in IETF for that..(did not have time to read Roland's identified RFC yet...maybe it is there...)

BR,

Jérôme
-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Monday 26 February 2018 17:41
To: François Simon; 'Jérôme Härri'; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

> Correct !

Is there a mapping between the Access Categories and IPv6 Traffic Class fields?

Alex

> If you do not want to do this, then the IRTF people might come with 
> ICN, but then would this be done above L3 or at L3...if still at L3, 
> you still will have a contextual L3 packet that might be redundant 
> with application/service layer messages...(the cost of using OSI)
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Feb 2018 18:07:52 +0100

Le 26/02/2018 à 17:47, Jérôme Härri a écrit :
> Hi Alex, All,
> 
> Made a minor mistake: the 802.1D UP are actually 8 values, 0-7. So 8 
> bits, and accordingly you can directly map the IPv6 TC to the 
> UP...there is a spec in ETSI for that, but not sure if there is one 
> spec in IETF for that.

At IETF there is a spec that says that the Traffic Class field in the
IPv6 header contains a DSCP (differentiated service code point) of
length 6bit and the other 2bits are 'currently' unused. (RFC2474).

As such, I dont think a one-to-one mapping between a 802.1D UP value and
a DSCP value is possible, unless some compression algorithm is used.

So, I dont think that mapping is as straightforward as one might see it
at a first sight.

> (did not have time to read Roland's identified RFC yet...maybe it is
> there...)

I looked at the RFC8325 referred to by Roland.  As the mapping of an
8-bit value to a 6-bit value is not straightforward they do agree on a
number of inconsistencies and potential conflicts.

Remark, in none of those conflicts and inconsistencies they talk about
anything related to vehicular networks.

Even though one may assimilate 'CAM' to something like 'voice' because
it has relatively same stringency in delivery requirements, one should
better think twice: there is a huge difference of effect between an
audio call subjected to some hicups and noise, and a CAM not reaching a
destination thus making some vehicle believe there is no obstacle.

That is why I thik RFC8325 could be a good starting point, but there
should be more.

And until then, I think it is good to just go with Data in IPv6-over-OCB.

Alex

> 
> BR,
> 
> Jérôme -----Original Message----- From: Alexandre Petrescu 
> [mailto:[email-masked]] Sent: Monday 26 February 2018 
> 17:41 To: François Simon; 'Jérôme Härri'; [email-masked] Subject: Re: 
> [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB
> 
> 
> 
>> | | + + | | +                         Source Address + | | + + | |
>> | | + + | | +                      Destination Address + | | + + | 
>> | 
>> -----Original Message----- From: its [mailto:[email-masked]] 
>> On Behalf Of Jérôme Härri Sent: Monday, February 26, 2018 4:25 AM 
>> To: 'Alexandre Petrescu' <[email-masked]>; 
>> [email-masked] Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data 
>> in IPv6-over-802.11-OCB
>> 
>> Hi Alex,
>> 
>>> That is a requirement.
>>> 
>>> But is there an implementation of mapping the priority of CAM 
>>> over DENM into a QoS Control field in QoS Data Header?
>>> 
>>> I doubt there is, because the implementations of CAM I see put 
>>> the Priority field to 6, which means Voice.  So they transmit
>>> CAM as Voice even though it is not voice.
>>> 
>> Of course there is....the QoS fields actually means the Access 
>> Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they 
>> use the QoS Control filed of IEE 802.11p to send CAM/BSM with 
>> higher priority (from a MAC perspective)...When looking at the
>> EDCA 'naming' you should not care much of the 'name'...this was
>> done at the time internet was only composed of voice, video
>> etc..you should look at the underlying values of each AC.
>> 
>> So, EDCA is composed of two fields: 1) AIFN - a deterministic idle 
>> time before even considering reducing CW 2) CW - a random timer to 
>> decrease each time the channel is idle.
>> 
>> QoS Data combinations for OCB: AC_VO: AIFN=2, CW=8 AC_VI: AIFN=2, 
>> CW=16 AC_BE: AIFN=3, CW=32 AC_BK: AIFN=7, CW=32
>> 
>> So, it does not matter the name (Voice, video)..what matters is 
>> that in implementation (BSM for instance), AIFN=2 so that it takes 
>> the fastest access (deterministic) and as such has the highest 
>> priority. This is also what you found: CAM on Priority field 6, so 
>> AC_VI so AIFN=2. BSM uses the same strategy.
>> 
>> Now, on the CAR 2 CAR specification, it is recommended a different 
>> priority: AC_BE, as it uses DP2. The reason behind this is the 
>> CAR2CAR provides a 'strict' prioritization between DENMs and CAMs. 
>> Emergency DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE 
>> and any other traffic AC_BK.
>> 
>> So, bottom line is: all ETSI and WAVE implementation use the QoS 
>> Data field as they use EDCA. If you found an implementation that 
>> does not use the QoS, it is wrong according to the standard.
>> 
>>>> Now, as you abstract ETSI and WAVE (thus pure IP), my 
>>>> understanding is that QoS remains required from the IEEE 
>>>> 802.11p (ok, IEEE 802.11-2016 OCB) as there is a specification 
>>>> of the EDCA parameters for OCB. Besides, I do not think it 
>>>> costs much to keep the EDCA in, as it first allows to safe a 
>>>> half of the MAC queueing time (the EDCA parameters for the two 
>>>> low AC are less, up to a quarter of a DIFS...so, it could be 
>>>> beneficial to allow this even for IP. Second, the EDCA allows 
>>>> TXOpps (Transmit Opportunities)..although put to 'zero' for
>>>> OCB (I think), this mechanism still allows an AP to reserve a
>>>> given time a long(er) connectivity with one device (e.
>>>> streaming of video etc..). Finally, it does not cost
>>>> anything..you can always take the lowest AC and you get the
>>>> same behavior as non-QoS..
>> 
>>> Well, this text is more informal in nature.   It is something 
>>> that describes a potential behaviour but we have no proof of 
>>> existing such behaviour, no proof of interoperability.  This 
>>> could be part of an INFORMATIONAL Internet Draft.
>> 
>> Well, my text is informal, but the specs are not. IEEE 802.11p 
>> (IEEE 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I 
>> do not think anything is required from IETF...just follow the IEEE 
>> 802.11-2016 specs and do whatever is allows above it...I will 
>> double check again on the IEEE 802.11-2016, but if what I think is 
>> confirmed, the whole discussion does not make any sense..., as it 
>> is my understanding that the OCB requires EDCA, so QoS_Data...so, 
>> you cannot change that at IP level.
>> 
>> 
>>>> assume non-QoS frames looks more to me like an implementation
>>>> error and we should not propagate this...
>> 
>>> Well, wireshark has problems interpreting 802.11 QoS Data 
>>> containing CAM messages.  Many receivers of QoS Data dont know 
>>> what to do with the fields because they are not agreed.
>> 
>> Yes, and this is why is the prototype we use, we actually have an 
>> parser for CAM to be supported by Wireshark...it does not come by 
>> default. But I am surprised..what kind of problem would wireshark 
>> face with the QoS Data?
>> 
>> 
>> To me, this looks more like an implementation issue, rather than a 
>> standard issue...but I will ask my team to check on our 
>> prototype...
>> 
>> Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is 
>> again a bit like 802.11p...'LTE Prose for V2X' is the real 
>> name...), mode 4 (ad-hoc mode..currently chosen by all vendors 
>> (except maybe Huawei, but might have changed), there is two
>> options for protocol stack: IPv6 (again, only IPv6) and non-IP
>> (L2)...you can use non-IP packets and it is so mentioned that BSM
>> and CAM will use the non-IP option, as it is also required to use
>> the ETSI/WAVE security provisions to secure the C-V2X mode 4 (as no
>> SIM= no security), as the ETSI/WAVE security provisions works for
>> non-IP packets (geonet or WSM)...
>> 
>> Of course, it does not block from using IP...it is again the same 
>> discussion we had with ITS-G5/DSRC...for safety communication, IP 
>> is not required...you can do everything without and faster. And 
>> considering that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no
>> SIM=no SEC) DO NOT have any form of security mechanism embedded,
>> they must use the those specified by ETSI/WAVE for accessing CCH.
>> 
>> Again, C-V2X mode 4 (the current V2X techno for Safety-critical 
>> communication) shall not be seen as following the same path as 
>> other cellular techno. It does not provide QoS (at all), as it 
>> channel access is contention-based (a bit like CSMA)...so 
>> collisions will occur (unlike 4G and 5G operated, where you are 
>> either dropped or you pass). And as such, IP is also not required, 
>> even if all 4G and 5G use IP.
>> 
>> 
>> Disagree: you need to be compatible with them...so, whatever IETF 
>> will do shall not break anything that has been done on ETSI or 
>> WAVE. This is one of the requirement for accessing the ITS-G5 
>> spectrum in EU, and I believe the same in the US.
>> 
>> Disagree: we need to integrate security mechanisms specified by 
>> ETSI even if we use IPv6. Today, we do not have any security 
>> specification providing 'trust', privacy and authentication for 
>> using 802.11-OCB (I believe it is the work of IPWAVE and it is not 
>> completed yet...). The mistake ETSI did is to try to be nice with 
>> IETF and help them to provide a way to use IPv6 over ITS-G5 in a 
>> secured way...WAVE took a different path: 'not my problem', which 
>> then explain why ETSI officially does not endorse IPWAVE 
>> (unfortunately, despite my many discussions with them)...from an 
>> ETSI perspective, using IPv6 over ITS-G5 is solved...(might be 
>> ugly, but it is solved).
>> 
>>> The mandatory fields in CAM or more than just lat/long/altitude. 
>>> There is also mandatory time in a strange format, car
>>> dimensions, curve, non standard precisions and more.
>> 
>> Yes, correct...but these are configurable fields, which may or may 
>> not be integrated...recent studies even showed that even the 
>> standard CAM size is not clear anymore..you have a 'range' of
>> size, and that is a problem for wireless optimization...especially
>> if you need to do wireless congestion control.
>> 
>>> If CAM worries about size, I think CAM should think about its 
>>> existing redundancy.  For example, position is carried twice in
>>> a CAM message: in the CAM itself and in the GeoNetworking
>>> header. That >is an issue they should address first.
>> 
>> Well, of course, this is a waste...but one reason for such 
>> existence is from the possibility to relay a packet (agnostic from 
>> the upper messages, unfortunately, we cannot use a Zero-NET for
>> CAM as it is pure 1-hop TSB)... Yet, today we start seeing even
>> BSM investigating ways to do multi-hop 'position' based relaying
>> to reach longer distance.
>> 
>> And if you think about it, one day, your IPv6-over-OCB might need 
>> to use a multi-hop networking protocol (e.g. MANET)..but doing the 
>> MANET way is highly mobile environment will not be that 
>> efficient...position-based mechanisms will be required (proven in 
>> various previous studies)...now, your L3 will not be able to 
>> inspect the GPS position of your CAM-over-IP...so, you will need
>> to have GPS (or so) position at IP/L3, which will end up being
>> similar than now...
>> 
>> ICN, but then would this be done above L3 or at L3...if still at
>> L3, you still will have a contextual L3 packet that might be 
>> redundant with application/service layer messages...(the cost of 
>> using OSI)
>> 
>> But this is just my personal view and very long term...for now, if 
>> we only look at CAM, indeed we can have twice the GPS position
>> (but wait: not the same granularity and you do not have elevation
>> in geonet). But if you look at  the bigger picture: doing 
>> CAM-over-geonet only required a single CAM, that's it. For 
>> IPv6-over-OCB, you need all the IPv6 address 
>> autoconfiguration..that requires additional IPv6 packets to be 
>> transmitted...this is similar to compare an apple with a tomato.
>> 
>>> I agree.  But I think we should compare header sizes and then 
>>> there will be surprises. CAM transported in IP may be a smaller 
>>> packet than CAM transported in BTP and GeoNetworking.
>> 
>> Not that much if you counts also all IPv6-related 
>> control/management packets required to transmit your CAM-over-OCB, 
>> in a highly dynamic environment...
>> 
>>> (WLAN is good at squeezing various small packets but really not 
>>> good at big things especially in broadcast mode)...a better 
>>> strategy would be to define new messages tailored to the 
>>> information needs, and have smart service 
>>> scheduling...(especially benefiting from IP-related mechanisms)
>> 
>>> I fully agree with this.
>>

---

From: François Simon <[email-masked]>
Date: Mon, 26 Feb 2018 12:12:29 -0500

In the RFC you can call it what ever you wish.

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Monday, February 26, 2018 11:23 AM
To: François Simon <[email-masked]>; 'Dr. Hans-Joachim Fischer' <[email-masked]>; 'Abdussalam Baryun' <[email-masked]>
Cc: 'Tony Li' <[email-masked]>; 'its' <[email-masked]>
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 18:23:51 +0100

Hi Alex,

I see...indeed not straightforward...is the RFC pointed out by Roland doing the mapping? If so, we could use it...otherwise, we could define what we prefer...(for example, the ETSI also did it for Geonet...mapping a geonet TF to the AC_...a bit arbitrary, but was tailored made)

BR,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Monday 26 February 2018 18:08
To: Jérôme Härri; 'François Simon'; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

At IETF there is a spec that says that the Traffic Class field in the
IPv6 header contains a DSCP (differentiated service code point) of length 6bit and the other 2bits are 'currently' unused. (RFC2474).

As such, I dont think a one-to-one mapping between a 802.1D UP value and a DSCP value is possible, unless some compression algorithm is used.

So, I dont think that mapping is as straightforward as one might see it at a first sight.

> (did not have time to read Roland's identified RFC yet...maybe it is

I looked at the RFC8325 referred to by Roland.  As the mapping of an 8-bit value to a 6-bit value is not straightforward they do agree on a number of inconsistencies and potential conflicts.

Remark, in none of those conflicts and inconsistencies they talk about anything related to vehicular networks.

Even though one may assimilate 'CAM' to something like 'voice' because it has relatively same stringency in delivery requirements, one should better think twice: there is a huge difference of effect between an audio call subjected to some hicups and noise, and a CAM not reaching a destination thus making some vehicle believe there is no obstacle.

That is why I thik RFC8325 could be a good starting point, but there should be more.

Alex

>> -----Original Message----- From: its [mailto:[email-masked]] On 
>> Behalf Of Jérôme Härri Sent: Monday, February 26, 2018 4:25 AM
>>> But is there an implementation of mapping the priority of CAM over 
>>> DENM into a QoS Control field in QoS Data Header?
>>> 
>>> Priority field to 6, which means Voice.  So they transmit CAM as 
>>> Voice even though it is not voice.
>>> 
>> Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use 
>> the QoS Control filed of IEE 802.11p to send CAM/BSM with higher 
>> priority (from a MAC perspective)...When looking at the EDCA 'naming' 
>> you should not care much of the 'name'...this was done at the time 
>> internet was only composed of voice, video etc..you should look at 
>> the underlying values of each AC.
>> 
>> So, it does not matter the name (Voice, video)..what matters is that 
>> in implementation (BSM for instance), AIFN=2 so that it takes the 
>> fastest access (deterministic) and as such has the highest priority. 
>> This is also what you found: CAM on Priority field 6, so AC_VI so 
>> AIFN=2. BSM uses the same strategy.
>> 
>> So, bottom line is: all ETSI and WAVE implementation use the QoS Data 
>> field as they use EDCA. If you found an implementation that does not 
>> use the QoS, it is wrong according to the standard.
>> 
>>>> as it first allows to safe a half of the MAC queueing time (the 
>>>> EDCA parameters for the two low AC are less, up to a quarter of a 
>>>> DIFS...so, it could be beneficial to allow this even for IP. 
>>>> Second, the EDCA allows TXOpps (Transmit Opportunities)..although 
>>>> put to 'zero' for OCB (I think), this mechanism still allows an AP 
>>>> to reserve a given time a long(er) connectivity with one device (e.
>>> existing such behaviour, no proof of interoperability.  This could 
>>> be part of an INFORMATIONAL Internet Draft.
>> 
>> Well, my text is informal, but the specs are not. IEEE 802.11p (IEEE 
>> 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not 
>> think anything is required from IETF...just follow the IEEE
>> 802.11-2016 specs and do whatever is allows above it...I will double 
>> check again on the IEEE 802.11-2016, but if what I think is 
>> confirmed, the whole discussion does not make any sense..., as it is 
>> my understanding that the OCB requires EDCA, so QoS_Data...so, you 
>> cannot change that at IP level.
>> 
>> 
>>> Well, wireshark has problems interpreting 802.11 QoS Data containing 
>>> CAM messages.  Many receivers of QoS Data dont know what to do with 
>>> the fields because they are not agreed.
>> 
>> standard issue...but I will ask my team to check on our prototype...
>> 
>> again a bit like 802.11p...'LTE Prose for V2X' is the real name...), 
>> mode 4 (ad-hoc mode..currently chosen by all vendors (except maybe 
>> Huawei, but might have changed), there is two options for protocol 
>> stack: IPv6 (again, only IPv6) and non-IP (L2)...you can use non-IP 
>> packets and it is so mentioned that BSM and CAM will use the non-IP 
>> option, as it is also required to use the ETSI/WAVE security 
>> provisions to secure the C-V2X mode 4 (as no SIM= no security), as 
>> the ETSI/WAVE security provisions works for non-IP packets (geonet or 
>> WSM)...
>> 
>> discussion we had with ITS-G5/DSRC...for safety communication, IP is 
>> not required...you can do everything without and faster. And 
>> considering that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=no 
>> SEC) DO NOT have any form of security mechanism embedded, they must 
>> use the those specified by ETSI/WAVE for accessing CCH.
>> 
>> communication) shall not be seen as following the same path as other 
>> cellular techno. It does not provide QoS (at all), as it channel 
>> access is contention-based (a bit like CSMA)...so collisions will 
>> occur (unlike 4G and 5G operated, where you are either dropped or you 
>> pass). And as such, IP is also not required, even if all 4G and 5G 
>> use IP.
>> 
>> 
>> will do shall not break anything that has been done on ETSI or WAVE. 
>> This is one of the requirement for accessing the ITS-G5 spectrum in 
>> EU, and I believe the same in the US.
>> 
>> Disagree: we need to integrate security mechanisms specified by ETSI 
>> even if we use IPv6. Today, we do not have any security specification 
>> providing 'trust', privacy and authentication for using 802.11-OCB (I 
>> believe it is the work of IPWAVE and it is not completed yet...). The 
>> mistake ETSI did is to try to be nice with IETF and help them to 
>> provide a way to use IPv6 over ITS-G5 in a secured way...WAVE took a 
>> different path: 'not my problem', which then explain why ETSI 
>> officially does not endorse IPWAVE (unfortunately, despite my many 
>> discussions with them)...from an ETSI perspective, using IPv6 over 
>> ITS-G5 is solved...(might be ugly, but it is solved).
>> 
>>> There is also mandatory time in a strange format, car dimensions, 
>>> curve, non standard precisions and more.
>> 
>> not be integrated...recent studies even showed that even the standard 
>> CAM size is not clear anymore..you have a 'range' of size, and that 
>> is a problem for wireless optimization...especially if you need to do 
>> wireless congestion control.
>> 
>>> existing redundancy.  For example, position is carried twice in a 
>>> CAM message: in the CAM itself and in the GeoNetworking header. That 
>>> >is an issue they should address first.
>> 
>> Well, of course, this is a waste...but one reason for such existence 
>> is from the possibility to relay a packet (agnostic from the upper 
>> messages, unfortunately, we cannot use a Zero-NET for CAM as it is 
>> pure 1-hop TSB)... Yet, today we start seeing even BSM investigating 
>> ways to do multi-hop 'position' based relaying to reach longer 
>> distance.
>> 
>> And if you think about it, one day, your IPv6-over-OCB might need to 
>> use a multi-hop networking protocol (e.g. MANET)..but doing the MANET 
>> way is highly mobile environment will not be that 
>> various previous studies)...now, your L3 will not be able to inspect 
>> the GPS position of your CAM-over-IP...so, you will need to have GPS 
>> (or so) position at IP/L3, which will end up being similar than 
>> now...
>> 
>> But this is just my personal view and very long term...for now, if we 
>> only look at CAM, indeed we can have twice the GPS position (but 
>> wait: not the same granularity and you do not have elevation in 
>> geonet). But if you look at  the bigger picture: doing 
>> IPv6-over-OCB, you need all the IPv6 address autoconfiguration..that 
>> requires additional IPv6 packets to be transmitted...this is similar 
>> to compare an apple with a tomato.
>> 
>>> I agree.  But I think we should compare header sizes and then there 
>>> will be surprises. CAM transported in IP may be a smaller packet 
>>> than CAM transported in BTP and GeoNetworking.
>> 
>> Not that much if you counts also all IPv6-related control/management 
>> packets required to transmit your CAM-over-OCB, in a highly dynamic 
>> environment...
>> 
>>> at big things especially in broadcast mode)...a better strategy 
>>> would be to define new messages tailored to the information needs, 
>>> and have smart service scheduling...(especially benefiting from 
>>> IP-related mechanisms)
>> 
>>> I fully agree with this.
>>

---

From: François Simon <[email-masked]>
Date: Mon, 26 Feb 2018 15:38:35 -0500

I am not sure where these values come from:

AIFSN: The values assigned for each AC are the DEFAULT values. Those values may not fit all applications.  This attribute specifies the number of slots, after a SIFS, that the STA,
for a particular AC, senses the medium idle either before transmitting or executing a backoff.  The value is (2..15);

CWmin: The minimum contention window size is defined by the aCWmin value. This attribute specifies the value of the minimum size of the window that is used by a STA for a particular AC for generating a random number for the backoff.  It is calculated by 2x – 1 where x is an integer. aCWmin is 0..255

CWmax: The maximum contention window size is defined by aCWmax.  The aCWmax is  0..65535

The defaults for CWmin and CWmax are specified in IEEE 802.11-2016, Clause  9.4.2.29 EDCA Parameter Set element.

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Monday, February 26, 2018 6:39 AM
To: 'Alexandre Petrescu' <[email-masked]>; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Hi Alex, All,

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Monday 26 February 2018 10:25
To: 'Alexandre Petrescu'; [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Hi Alex,

  

 

Cheers,

Jérôme

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 26 Feb 2018 21:46:00 +0100

Hi François,

They come from IEEE 802.11-2016, section p.899, section , 9.4.2.29 EDCA Parameter Set element, Table 9-138—Default EDCA parameter set for STA operation if dot11OCBActivated is true

BR,

Jérôme

From: François Simon [mailto:[email-masked]] 
Sent: Monday 26 February 2018 21:39
To: 'Jérôme Härri'; 'Alexandre Petrescu'; [email-masked]
Cc: [email-masked]
Subject: RE: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Monday, February 26, 2018 6:39 AM
To: 'Alexandre Petrescu' <[email-masked]>; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Hi Alex, All,

BR,

Jérôme

-----Original Message-----

From: its [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Jérôme Härri

To: 'Alexandre Petrescu';  <mailto:[email-masked]> [email-masked]

Hi Alex,

AC_VO: AIFN=2, CW=8

AC_VI: AIFN=2, CW=16

AC_BE: AIFN=3, CW=32

AC_BK: AIFN=7, CW=32

Cheers,

Jérôme

its mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/its> https://www.ietf.org/mailman/listinfo/its

its mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/its> https://www.ietf.org/mailman/listinfo/its

---

From: John Kenney <[email-masked]>
Date: Mon, 26 Feb 2018 19:09:05 -0800

Hi All:

Jérôme has made a very important point.  Choosing to send IP traffic over
DCF (i.e. non-QoS data frames) can be quite harmful to other DSRC services
using EDCA. *It should not be done, period.*

Some specific points:
1) WAVE standards explicitly require use of EDCA (IEEE 1609.4-2016, clause
4.1)

2) DCF is not really non-QoS. It is best thought of as "alternate" QoS, and
in fact as "high QoS".  In 802.11 the notion of QoS is manifested as
channel access priority. As pointed out by others, this comes down to AIFSN
and CWmin.  DCF uses the equivalent of (AIFSN=2, CWmin = 15). Under
moderate-to-heavy channel load, when QoS is important, AIFSN is the
dominant factor. As Jérôme and Francois note, this puts DCF traffic at, or
just below, the very highest priority EDCA traffic.  So, this is quite
different from Diffserv where "non-Diffserv" defaults to Best Effort.  Here
"non-EDCA" defaults to high channel access priority.  This can be very
harmful to very important DSRC/ITS G5 traffic, especially traffic using
AC_VI and below.

3) I totally agree with the comments that caution not to be confused by the
Voice/Video/Best Effort/Background labels. Those are historical and meant
to be illustrative. In the ITS context it is simpler to think of
Highest/High/Medium/Low channel access priority. Those are the terms used
in SAE J2945/0 (clause 4.1.2.3), which makes recommendations for mapping
application classes to 802.11 access categories.  I believe the channel
access priority will generally be independent of the L3 protocol [My
personal opinion is if there is correlation in the DSRC case I expect we
would see higher priority associated more often with WSMP (or ETSI
equivalent) than with IPv6].  Therefore, not only should IP-over-OCB use
EDCA, it should allow the actual user priority to come from higher layers.

4) EDCA parameters establish priority within a given channel. It is
generally not possible (or necessary) to compare priority of packets sent
on different channels. So, the EDCA parameter set may well vary by channel.
This is exactly the case for the US DSRC band where SAE J2945/1 defines a
non-default EDCA parameter set for Channel 172.

Best Regards,
John

On Mon, Feb 26, 2018 at 8:41 AM, Jérôme Härri <[email-masked]>
wrote:

> Hi Alex,
>
> Well, from the IP layer, what you see is a 7 bit User Priority, nothing
> else..feel free to label the 7 UP as you want....how it is translated is L2
> business (and naming..)..so we should not care much about the names.
>
> Now, you raised an issue (that was also identified by other OCB people
> reading the thread..and will probably also provide feedback soon) is the
> coexistence between traffic.
>
> CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI. Event-based BSM
> uses AC_VI and non-even-based BSM uses AC_BE (I think)...so, if you send
> IPv6 traffic with DCF (where DIFS = 2, same as AC_VI), then you will
> compete directly with  DENM and event-based BSM, which is * very*
> problematic...thus my suggestion to keep QoSData so that we at least have
> an option to avoid interfering with CAM/DENM.
>
> Now, if you want to transmit CAM with IPv6-over-OCB, then you 'clearly'
> needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE CAM/BSM have the
> same L2 'priority' in accessing the channel, otherwise you risk creating
> harmful interference and packet collisions.
>
> BR,
>
> Jérôme
>
>
>
>

-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Tony Li <[email-masked]>
Date: Mon, 26 Feb 2018 19:20:39 -0800

> Therefore, not only should IP-over-OCB use EDCA, it should allow the actual user priority to come from higher layers.

Please recall that there is no security over the IPv6 header and that users have full access to the priority field. The networks that actually do try to implement some form of QoS are forced to explicitly reclassify all traffic entering their networks, either from their immediate customers or from peer networks.

Any IP stack not under the complete control of a network operator should be assumed to be compromised and the diffserv code points should not be trusted.

Now, are we sure we want to make use of this?

I’ll also remind folks that IP is running in the application channels and so is not going to be interfering with mission critical uses. 

Trying to control QoS between multiple applications, some of which are under nefarious control is likely to be a recipe for simply hurting those that are trying to be compliant.  If we simply treat everything uniformly, we give everyone less incentive to game the system.  And we have no way of stopping them from gaming the system.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 07:29:32 +0100

Do they say what means VO in AC_VO.

Maybe they will need an AC_VE to stand for Vehicular.

Alex

Le 26/02/2018 à 21:46, Jérôme Härri a écrit :
> Hi François,
> 
> They come from IEEE 802.11-2016, section p.899, section , 9.4.2.29 EDCA 
> Parameter Set element, Table 9-138—Default EDCA parameter set for STA 
> operation if dot11OCBActivated is true
> 
> BR,
> 
> Jérôme
> 
> *From:*François Simon [mailto:[email-masked]]
> *Sent:* Monday 26 February 2018 21:39
> *To:* 'Jérôme Härri'; 'Alexandre Petrescu'; [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [ipwave] 802.11 Data vs 802.11 QoS Data in 
> IPv6-over-802.11-OCB
> 
> /QoS Data combinations for OCB:/
> 
> /AC_VO: AIFN=2, CWmin=4 CWmax=8/
> 
> /AC_VI: AIFN=3, CWmin=8 CWmax=16/
> 
> /AC_BE: AIFN=6, CWmin=16 CWmax=1024/
> 
> /AC_BK: AIFN=9, CWmin=16 CWmax=1024/
> 
> AIFSN: The values assigned for each AC are the***DEFAULT*values. Those 
> values may not fit all applications. This attribute specifies the number 
> of slots, after a SIFS, that the STA,
> 
> for a particular AC, senses the medium idle either before transmitting 
> or executing a backoff.  The value is (*2..15*);
> 
> CWmin: The minimum contention window size is defined by the aCWmin 
> value. This attribute specifies the value of the minimum size of the 
> window that is used by a STA for a particular AC for generating a random 
> number for the backoff. It is calculated by 2^x – 1 where x is an 
> integer. aCWmin is***0..255*
> 
> CWmax: The maximum contention window size is defined by aCWmax. The 
> aCWmax is ***0..65535*
> 
> The defaults for CWmin and CWmax are specified in IEEE 802.11-2016, 
> Clause 9.4.2.29 EDCA Parameter Set element.
> 
> To: 'Alexandre Petrescu' <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Yet, I still suggest to keep QoS for IPv6, again as even if it does not 
> bring much 'now' for IPv6, it does not cost much either...and we should 
> not forgot that we might interact with EDCA transmissions (QoS) and as 
> such could create harmful interference on the DSRC/ITS-G5 channels.
> 
> BR,
> 
> Jérôme
> 
> Categories (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the 
> QoS Control filed of IEE 802.11p to send CAM/BSM with higher priority 
> (from a MAC perspective)...When looking at the EDCA 'naming' you should 
> not care much of the 'name'...this was done at the time internet was 
> only composed of voice, video etc..you should look at the underlying 
> values of each AC.
> 
> So, it does not matter the name (Voice, video)..what matters is that in 
> implementation (BSM for instance), AIFN=2 so that it takes the fastest 
> access (deterministic) and as such has the highest priority. This is 
> also what you found: CAM on Priority field 6, so AC_VI so AIFN=2. BSM 
> uses the same strategy.
> 
> priority: AC_BE, as it uses DP2. The reason behind this is the CAR2CAR 
> provides a 'strict' prioritization between DENMs and CAMs. Emergency 
> DENMs uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other 
> traffic AC_BK.
> 
> field as they use EDCA. If you found an implementation that does not use 
> the QoS, it is wrong according to the standard.
> 
> 802.11-2016 OCB) uses EDCA not DCF...as this is L2 layer, I do not think 
> anything is required from IETF...just follow the IEEE 802.11-2016 specs 
> and do whatever is allows above it...I will double check again on the 
> IEEE 802.11-2016, but if what I think is confirmed, the whole discussion 
> does not make any sense..., as it is my understanding that the OCB 
> requires EDCA, so QoS_Data...so, you cannot change that at IP level.
> 
> Yes, and this is why is the prototype we use, we actually have an parser 
> for CAM to be supported by Wireshark...it does not come by default. But 
> I am surprised..what kind of problem would wireshark face with the QoS 
> Data?
> 
> Sorry, it will not. In C-V2X (the widely known name...LTE-V2X is again a 
> bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 
> (ad-hoc mode..currently chosen by all vendors (except maybe Huawei, but 
> might have changed), there is two options for protocol stack: IPv6 
> (again, only IPv6) and non-IP (L2)...you can use non-IP packets and it 
> is so mentioned that BSM and CAM will use the non-IP option, as it is 
> also required to use the ETSI/WAVE security provisions to secure the 
> C-V2X mode 4 (as no SIM= no security), as the ETSI/WAVE security 
> provisions works for non-IP packets (geonet or WSM)...
> 
> discussion we had with ITS-G5/DSRC...for safety communication, IP is not 
> required...you can do everything without and faster. And considering 
> that IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=no SEC) DO NOT have 
> any form of security mechanism embedded, they must use the those 
> specified by ETSI/WAVE for accessing CCH.
> 
> cellular techno. It does not provide QoS (at all), as it channel access 
> is contention-based (a bit like CSMA)...so collisions will occur (unlike 
> 4G and 5G operated, where you are either dropped or you pass). And as 
> such, IP is also not required, even if all 4G and 5G use IP.
> 
> Disagree: you need to be compatible with them...so, whatever IETF will 
> do shall not break anything that has been done on ETSI or WAVE. This is 
> one of the requirement for accessing the ITS-G5 spectrum in EU, and I 
> believe the same in the US.
> 
> believe it is the work of IPWAVE and it is not completed yet...).
> 
> The mistake ETSI did is to try to be nice with IETF and help them to 
> different path: 'not my problem', which then explain why ETSI officially 
> does not endorse IPWAVE (unfortunately, despite my many discussions with 
> them)...from an ETSI perspective, using IPv6 over ITS-G5 is 
> solved...(might be ugly, but it is solved).
> 
> Yes, correct...but these are configurable fields, which may or may not 
> be integrated...recent studies even showed that even the standard CAM 
> size is not clear anymore..you have a 'range' of size, and that is a 
> problem for wireless optimization...especially if you need to do 
> Well, of course, this is a waste...but one reason for such existence is 
> from the possibility to relay a packet (agnostic from the upper 
> messages, unfortunately, we cannot use a Zero-NET for CAM as it is pure 
> 1-hop TSB)...
> 
> Yet, today we start seeing even BSM investigating ways to do multi-hop 
> 'position' based relaying to reach longer distance.
> 
> And if you think about it, one day, your IPv6-over-OCB might need to use 
> a multi-hop networking protocol (e.g. MANET)..but doing the MANET way is 
> highly mobile environment will not be that efficient...position-based 
> mechanisms will be required (proven in various previous studies)...now, 
> your L3 will not be able to inspect the GPS position of your 
> CAM-over-IP...so, you will need to have GPS (or so) position at IP/L3, 
> which will end up being similar than now...
> 
> If you do not want to do this, then the IRTF people might come with ICN, 
> but then would this be done above L3 or at L3...if still at L3, you 
> still will have a contextual L3 packet that might be redundant with 
> application/service layer messages...(the cost of using OSI)
> 
> only look at CAM, indeed we can have twice the GPS position (but wait: 
> not the same granularity and you do not have elevation in geonet). But 
> if you look at  the bigger picture: doing CAM-over-geonet only required 
> a single CAM, that's it. For IPv6-over-OCB, you need all the IPv6 
> address autoconfiguration..that requires additional IPv6 packets to be

---

From: John Kenney <[email-masked]>
Date: Mon, 26 Feb 2018 22:57:15 -0800

Hi Tony,

If priority settings passing through IPv6 can’t be trusted then I agree to
treat all the IP traffic uniformly. In that case it is probably best to map
it all to the AC_BK so it will not interfere with critical DSRC traffic.
For the reasons previously stated, it can’t be DCF.

BTW in the US band plan there are no non-critical channels or "application"
channels. All channels are expected to carry critical traffic. See SAE
J2945/0 (Table 4) for the recommended channel usage plan. You’ll see that
IPv6 traffic is expected to share channels with I2V safety and mobility,
with V2P safety, with automated driving support, etc.  Table 3 shows
recommended priority settings, and I note that SCMS communication, which is
expected to use IPv6, is recommended to use AC_BK.

In Europe it is similar, except that the lowest two channels are explicitly
designated only for non-safety applications, though I would caution that
non-safety does not mean “lacking performance requirements “.

Best Regards,
John

On Mon, Feb 26, 2018 at 7:23 PM Tony Li <[email-masked]> wrote:

>
> Therefore, not only should IP-over-OCB use EDCA, it should allow the
> actual user priority to come from higher layers.
>
>
>
> Please recall that there is no security over the IPv6 header and that
> users have full access to the priority field. The networks that actually do
> try to implement some form of QoS are forced to explicitly reclassify all
> traffic entering their networks, either from their immediate customers or
> from peer networks.
>
> Any IP stack not under the complete control of a network operator should
> be assumed to be compromised and the diffserv code points should not be
> trusted.
>
> I’ll also remind folks that IP is running in the application channels and
> so is not going to be interfering with mission critical uses.
>
> Trying to control QoS between multiple applications, some of which are
> under nefarious control is likely to be a recipe for simply hurting those
> that are trying to be compliant.  If we simply treat everything uniformly,
> we give everyone less incentive to game the system.  And we have no way of
> stopping them from gaming the system.
>
> Tony
>
>

---

From: John Kenney <[email-masked]>
Date: Mon, 26 Feb 2018 23:23:16 -0800

Hi Alex,
As I mentioned in another email, these labels VO/VI/BE/BK are historical
(going back to the 2005 802.11e amendment) and merely illustrative of four
application classes in a generic WLAN. AC_VO was never intended to be
limited only to voice flows.  802.11 QoS is inherently relative, so you
don't just create more access categories when new applications come along.
There are only four access categories in standard EDCA. The labels don't
mean much. What matters are the set of EDCA parameters associated with each
AC. These could be from the default set or (as in the case of Ch. 172)
something different. We wouldn't use AC_VE to mean vehicular because we use
all four ACs in vehicular communication (OCB). The whole band is restricted
to vehicular communication, and we need to prioritize within that universe.

John

On Mon, Feb 26, 2018 at 10:29 PM, Alexandre Petrescu <
[email-masked]> wrote:

>> values may not fit all applications. This attribute specifies the number of
>> slots, after a SIFS, that the STA,
>>
>> for a particular AC, senses the medium idle either before transmitting or
>> executing a backoff.  The value is (*2..15*);
>>
>> CWmin: The minimum contention window size is defined by the aCWmin value.
>> This attribute specifies the value of the minimum size of the window that
>> is used by a STA for a particular AC for generating a random number for the
>> backoff. It is calculated by 2^x – 1 where x is an integer. aCWmin
>> is***0..255*
>>
>> To: 'Alexandre Petrescu' <[email-masked] <mailto:
>> [email-masked]>>; [email-masked] <mailto:[email-masked]>
>> bring much 'now' for IPv6, it does not cost much either...and we should not
>> forgot that we might interact with EDCA transmissions (QoS) and as such
>> could create harmful interference on the DSRC/ITS-G5 channels.
>>
>> BR,
>>
>> Jérôme
>>
>>> Priority field to 6, which means Voice.  So they transmit CAM as Voice even
>>> though it is not voice.
>>>
>>
>>
>>>
>> Of course there is....the QoS fields actually means the Access Categories
>> (AC) for WLAN, so EDCA. Both in ETSI and in WAVE they use the QoS Control
>> filed of IEE 802.11p to send CAM/BSM with higher priority (from a MAC
>> perspective)...When looking at the EDCA 'naming' you should not care much
>> of the 'name'...this was done at the time internet was only composed of
>> voice, video etc..you should look at the underlying values of each AC.
>>
>> access (deterministic) and as such has the highest priority. This is also
>> what you found: CAM on Priority field 6, so AC_VI so AIFN=2. BSM uses the
>> same strategy.
>>
>> provides a 'strict' prioritization between DENMs and CAMs. Emergency DENMs
>> uses AC_VI, normal DENM uses AC_VO, CAM uses AC_BE and any other traffic
>> AC_BK.
>>
>> anything is required from IETF...just follow the IEEE 802.11-2016 specs and
>> do whatever is allows above it...I will double check again on the IEEE
>> 802.11-2016, but if what I think is confirmed, the whole discussion does
>> not make any sense..., as it is my understanding that the OCB requires
>> EDCA, so QoS_Data...so, you cannot change that at IP level.
>>
>>> messages.  Many receivers of QoS Data dont know what to do with the fields
>>> because they are not agreed.
>>>
>>
>> for CAM to be supported by Wireshark...it does not come by default. But I
>> am surprised..what kind of problem would wireshark face with the QoS Data?
>>
>> bit like 802.11p...'LTE Prose for V2X' is the real name...), mode 4 (ad-hoc
>> mode..currently chosen by all vendors (except maybe Huawei, but might have
>> changed), there is two options for protocol stack: IPv6 (again, only IPv6)
>> and non-IP (L2)...you can use non-IP packets and it is so mentioned that
>> BSM and CAM will use the non-IP option, as it is also required to use the
>> ETSI/WAVE security provisions to secure the C-V2X mode 4 (as no SIM= no
>> security), as the ETSI/WAVE security provisions works for non-IP packets
>> (geonet or WSM)...
>>
>> required...you can do everything without and faster. And considering that
>> IEEE 802.11p (ok, OCB) and C-V2X mode 4 (no SIM=no SEC) DO NOT have any
>> form of security mechanism embedded, they must use the those specified by
>> ETSI/WAVE for accessing CCH.
>>
>> cellular techno. It does not provide QoS (at all), as it channel access is
>> contention-based (a bit like CSMA)...so collisions will occur (unlike 4G
>> and 5G operated, where you are either dropped or you pass). And as such, IP
>> is also not required, even if all 4G and 5G use IP.
>>
>> Disagree: you need to be compatible with them...so, whatever IETF will do
>> shall not break anything that has been done on ETSI or WAVE. This is one of
>> the requirement for accessing the ITS-G5 spectrum in EU, and I believe the
>> same in the US.
>>
>> Disagree: we need to integrate security mechanisms specified by ETSI even
>> if we use IPv6. Today, we do not have any security specification providing
>> 'trust', privacy and authentication for using 802.11-OCB (I believe it is
>> the work of IPWAVE and it is not completed yet...).
>>
>> them)...from an ETSI perspective, using IPv6 over ITS-G5 is solved...(might
>> be ugly, but it is solved).
>>
>> Yes, correct...but these are configurable fields, which may or may not be
>> integrated...recent studies even showed that even the standard CAM size is
>> not clear anymore..you have a 'range' of size, and that is a problem for
>> wireless optimization...especially if you need to do wireless congestion
>> control.
>>
>>> the CAM itself and in the GeoNetworking header.  That >is an issue they
>>> should address first.
>>>
>>
>> from the possibility to relay a packet (agnostic from the upper messages,
>> unfortunately, we cannot use a Zero-NET for CAM as it is pure 1-hop TSB)...
>>
>> but then would this be done above L3 or at L3...if still at L3, you still
>> will have a contextual L3 packet that might be redundant with
>> only look at CAM, indeed we can have twice the GPS position (but wait: not
>> the same granularity and you do not have elevation in geonet). But if you
>> look at  the bigger picture: doing CAM-over-geonet only required a single
>> CAM, that's it. For IPv6-over-OCB, you need all the IPv6 address

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 11:30:45 +0100

Le 27/02/2018 à 04:09, John Kenney a écrit :
> Hi All:
> 
> Jérôme has made a very important point.  Choosing to send IP traffic 
> over DCF (i.e. non-QoS data frames) can be quite harmful to other DSRC 
> services using EDCA. _It should not be done, period._

Hi John,

Thank you for the remark.

I think that that potential harm can be avoided by IEEE in the first
place; I think IEEE could specify - if deemed necessary - that OCB must
only use QoS Data, and not Data. Currently IEEE allows both.

There is no open source available, as far as I know, that transmits ITS
messages as QoS Data. The implementations I have seen that send CAM as
QoS Data are closed source. They come from Unex, on ThreadX operating
system, Autotalks chipset. There may be others.

There is a lot of cheap open source available that transmits ITS
messages, and IP, as Data. They are available on github.com, are called
'rendits', 'vanetza', 'driveits', 'btpsap' and others.

Given that situation of software availability and IEEE situation, I do
not know how the recommendation above could be implemented.

Alex

> Some specific points:
> 1) WAVE standards explicitly require use of EDCA (IEEE 1609.4-2016, 
> clause 4.1)
> 
> 2) DCF is not really non-QoS. It is best thought of as "alternate" QoS, 
> and in fact as "high QoS".  In 802.11 the notion of QoS is manifested as 
> channel access priority. As pointed out by others, this comes down to 
> AIFSN and CWmin.  DCF uses the equivalent of (AIFSN=2, CWmin = 15). 
> Under moderate-to-heavy channel load, when QoS is important, AIFSN is 
> the dominant factor. As Jérôme and Francois note, this puts DCF traffic 
> at, or just below, the very highest priority EDCA traffic.  So, this is 
> quite different from Diffserv where "non-Diffserv" defaults to Best 
> Effort.  Here "non-EDCA" defaults to high channel access priority.  This 
> can be very harmful to very important DSRC/ITS G5 traffic, especially 
> traffic using AC_VI and below.
> 
> 3) I totally agree with the comments that caution not to be confused by 
> the Voice/Video/Best Effort/Background labels. Those are historical and 
> meant to be illustrative. In the ITS context it is simpler to think of 
> Highest/High/Medium/Low channel access priority. Those are the terms 
> used in SAE J2945/0 (clause 4.1.2.3), which makes recommendations for 
> mapping application classes to 802.11 access categories.  I believe the 
> channel access priority will generally be independent of the L3 protocol 
> [My personal opinion is if there is correlation in the DSRC case I 
> expect we would see higher priority associated more often with WSMP (or 
> ETSI equivalent) than with IPv6].  Therefore, not only should 
> IP-over-OCB use EDCA, it should allow the actual user priority to come 
> from higher layers.
> 
> generally not possible (or necessary) to compare priority of packets 
> sent on different channels. So, the EDCA parameter set may well vary by 
> channel. This is exactly the case for the US DSRC band where SAE J2945/1 
> defines a non-default EDCA parameter set for Channel 172.
> 
> Best Regards,
> John
> 
> 
> 
> On Mon, Feb 26, 2018 at 8:41 AM, Jérôme Härri <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Alex,
> 
>     Well, from the IP layer, what you see is a 7 bit User Priority,
>     nothing else..feel free to label the 7 UP as you want....how it is
>     translated is L2 business (and naming..)..so we should not care much
>     about the names.
> 
>     Now, you raised an issue (that was also identified by other OCB
>     people reading the thread..and will probably also provide feedback
>     soon) is the coexistence between traffic.
> 
>     CAM uses AC_BE in ETSI, DENM uses AC_VI and AC_VO in ETSI.
>     Event-based BSM uses AC_VI and non-even-based BSM uses AC_BE (I
>     think)...so, if you send IPv6 traffic with DCF (where DIFS = 2, same
>     as AC_VI), then you will compete directly with  DENM and event-based
>     BSM, which is * very* problematic...thus my suggestion to keep
>     QoSData so that we at least have an option to avoid interfering with
>     CAM/DENM.
> 
>     Now, if you want to transmit CAM with IPv6-over-OCB, then you
>     'clearly' needs QoSData so that the pure IP CAM/BSN and ETSI/WAVE
>     CAM/BSM have the same L2 'priority' in accessing the channel,
>     otherwise you risk creating harmful interference and packet collisions.
> 
>     BR,
> 
>     Jérôme
> 
> 
> 
> 
>     From: its [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Alexandre Petrescu
>      > AC_VO (voice) is only a label indicating the highest priority;
>     nothing
>      > more is implied.
> 
>     YEs, sure, but imagine someone sends real voice; that will compete
>     with CAM 'voice' - we dont want that either :-)
> 
>      > *From:*its [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Dr.
>      > Hans-Joachim Fischer
>      > *To:* Abdussalam Baryun <[email-masked]
>     <mailto:[email-masked]>>; Alexandre
>      > Petrescu <[email-masked]
>     <mailto:[email-masked]>>
>      > *Cc:* Tony Li <[email-masked]
>     <mailto:[email-masked]>>; its <[email-masked]
>     <mailto:[email-masked]>>
>      >     <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >     wrote:
>      >
>      >
>      >
>      >                 In OCB mode, IPv6 packets MAY be transmitted
>     either as
>      >             "IEEE 802.11
>      >                 In OCB mode, it is RECOMMENDED to transmit IPv6
>     packets
>      >             as "IEEE
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >
>     <https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf>
>      >
>      >
>      > +49 (7344) 175340 <tel:%2B49%20%287344%29%20175340> (Direct line
>     Dr. Fischer)
>      >
>      > +49 (7344) 919188 <tel:%2B49%20%287344%29%20919188> (Central office)
>      >
>      > +49 (7344) 919123 <tel:%2B49%20%287344%29%20919123> (Fax)
>      >
>     <http://fischer-tech.eu/Feeds/esf.rss>
>      >
>     <http://its-standards.info/Feeds/cits.rss>
>      >
>     <http://fischer-tech.de/Feeds/esfD.rss>
>      >
>      >

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 11:32:41 +0100

Le 27/02/2018 à 07:57, John Kenney a écrit :
> Hi Tony,
> 
> If priority settings passing through IPv6 can’t be trusted then I agree 
> to treat all the IP traffic uniformly. In that case it is probably best 
> to map it all to the AC_BK so it will not interfere with critical DSRC 
> traffic. For the reasons previously stated, it can’t be DCF.

Why BK and not BE ('Best Effort')?

Alex

> BTW in the US band plan there are no non-critical channels or 
> "application" channels. All channels are expected to carry critical 
> traffic. See SAE J2945/0 (Table 4) for the recommended channel usage 
> plan. You’ll see that IPv6 traffic is expected to share channels with 
> I2V safety and mobility, with V2P safety, with automated driving 
> support, etc.  Table 3 shows recommended priority settings, and I note 
> that SCMS communication, which is expected to use IPv6, is recommended 
> to use AC_BK.
> 
> In Europe it is similar, except that the lowest two channels are 
> explicitly designated only for non-safety applications, though I would 
> caution that non-safety does not mean “lacking performance requirements “.
> 
> Best Regards,
> John
> 
> On Mon, Feb 26, 2018 at 7:23 PM Tony Li <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>>     Therefore, not only should IP-over-OCB use EDCA, it should allow
>>     the actual user priority to come from higher layers.
> 
> 
>     Please recall that there is no security over the IPv6 header and
>     that users have full access to the priority field. The networks that
>     actually do try to implement some form of QoS are forced to
>     explicitly reclassify all traffic entering their networks, either
>     from their immediate customers or from peer networks.
> 
>     Any IP stack not under the complete control of a network operator
>     should be assumed to be compromised and the diffserv code points
>     should not be trusted.
> 
>     I’ll also remind folks that IP is running in the application
>     channels and so is not going to be interfering with mission critical
>     uses.
> 
>     Trying to control QoS between multiple applications, some of which
>     are under nefarious control is likely to be a recipe for simply
>     hurting those that are trying to be compliant.  If we simply treat
>     everything uniformly, we give everyone less incentive to game the
>     system.  And we have no way of stopping them from gaming the system.
> 
>     Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 11:35:46 +0100

Le 27/02/2018 à 08:23, John Kenney a écrit :
> (going back to the 2005 802.11e amendment) and merely illustrative of 
> four application classes in a generic WLAN. AC_VO was never intended to 
> be limited only to voice flows.  802.11 QoS is inherently relative, so 
> you don't just create more access categories when new applications come 
> along. There are only four access categories in standard EDCA. The 
> labels don't mean much. What matters are the set of EDCA parameters 
> associated with each AC. These could be from the default set or (as in 
> the case of Ch. 172) something different. We wouldn't use AC_VE to mean 
> vehicular because we use all four ACs in vehicular communication (OCB). 
> The whole band is restricted to vehicular communication, and we need to 
> prioritize within that universe.

I can agree to stay within a given universe.

When a new draft is written about mapping 802.11 ACs (Access Classes?) 
into IPv6 Traffic Classes, maybe we will clarify the terminology at that 
time.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 11:38:43 +0100

Le 27/02/2018 à 11:35, Alexandre Petrescu a écrit :
>> As I mentioned in another email, these labels VO/VI/BE/BK are 
>> historical (going back to the 2005 802.11e amendment) and merely 
>> illustrative of four application classes in a generic WLAN. AC_VO was 
>> never intended to be limited only to voice flows.  802.11 QoS is 
>> inherently relative, so you don't just create more access categories 
>> when new applications come along. There are only four access 
>> categories in standard EDCA. The labels don't mean much. What matters 
>> are the set of EDCA parameters associated with each AC. These could be 
>> from the default set or (as in the case of Ch. 172) something 
>> different. We wouldn't use AC_VE to mean vehicular because we use all 
>> four ACs in vehicular communication (OCB). The whole band is 
>> restricted to vehicular communication, and we need to prioritize 
>> within that universe.
> 

Sorry to answer my own email.

By 'access classes' I meant to say: Access Categories (AC): background 
(BK), best effort (BE), video (VI) and voice (VO).  (copied from a poster).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 11:43:44 +0100

I propose the following modifications towards resolution of this QoS issue.

Do you disagree?

Remove this entire OLD text:
> +--------------------+-------------+-------------+---------+-----------+
> | 802.11 Data Header | LLC Header  | IPv6 Header | Payload |.11 Trailer|
> +--------------------+-------------+-------------+---------+-----------+
> 
> or
> 
> +--------------------+-------------+-------------+---------+-----------+
> | 802.11 QoS Data Hdr| LLC Header  | IPv6 Header | Payload |.11 Trailer|
> +--------------------+-------------+-------------+---------+-----------+
> 
>           Figure 2: 802.11 Data Header or 802.11 QoS Data Header
> 

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 27 Feb 2018 11:44:48 +0100

Hi Alex,

Because AC_BE is used by BSM, which is a critical DSRC traffic. 

BR,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Tuesday 27 February 2018 11:33
To: John Kenney; Tony Li
Cc: Abdussalam Baryun; Dr. Hans-Joachim Fischer; François Simon; Jérôme Härri; its
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Le 27/02/2018 à 07:57, John Kenney a écrit :
> Hi Tony,
> 
> If priority settings passing through IPv6 can’t be trusted then I 
> agree to treat all the IP traffic uniformly. In that case it is 
> probably best to map it all to the AC_BK so it will not interfere with 
> critical DSRC traffic. For the reasons previously stated, it can’t be DCF.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 11:50:04 +0100

> Because AC_BE is used by BSM, which is a critical DSRC traffic.

This use of the term 'Best Effort' strikes so different than 'Best 
Effort' on the Internet which is something like in RFC5290, i.e. that is 
not covered by QoS.

Terminology... as usual :-)

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 27 Feb 2018 13:15:17 +0100

Hi Alex,

>I think that that potential harm can be avoided by IEEE in the first place; I think IEEE could specify - if deemed necessary - that OCB must only use QoS Data, and not Data. Currently IEEE allows both.
>
>There is no open source available, as far as I know, that transmits ITS messages as QoS Data. The implementations I have seen that send CAM as QoS Data are closed source. They come from Unex, on ThreadX operating system, Autotalks chipset. There may be others.
>
>There is a lot of cheap open source available that transmits ITS messages, and IP, as Data. They are available on github.com, are called 'rendits', 'vanetza', 'driveits', 'btpsap' and others.
>
>Given that situation of software availability and IEEE situation, I do not know how the recommendation above could be implemented.
>
>Alex

Well IEEE 802.11-2016 OCB is agnostic to the criticality of the traffic...(and I think it should remain so...). It is WAVE and ETSI, which defined critical safety traffic and thus imposed QoSData, as it is critically required for their implementations and congestion control. Now, using IPv6-over-OCB on the ITS-G5 bands follows the same challenges as both BRAN (WLAN) and C-V2X...if it is used for safety-related traffic, they should not create harmful interferences with the current technology (DSRC/ITS-G5), which suggests (I am not a lawyer) that IPWAVE must use QoSData (at least) and differentiate traffic to have access priority equivalent to those defined by SAE/ETSI....

As mentioned, what does it cost to IPWAVE to recommend using QoSData for IPv6-over-OCB? 

Now, I am also a bit surprised: I have not been long enough in IETF I guess, but since when would IETF recommend a mechanism not because it is good, but because it is the only open-source code available?? 

If QoSData implementations are not available, let's make one...by using QoSData instead of Data for IPWAVE, you will save a lot of discussions about spectrum neutrality and non-harmful interference, which might even block implementations using this very RFC. 

BR,

Jérôme

> 2) DCF is not really non-QoS. It is best thought of as "alternate" 
> QoS, and in fact as "high QoS".  In 802.11 the notion of QoS is 
> manifested as channel access priority. As pointed out by others, this 
> comes down to AIFSN and CWmin.  DCF uses the equivalent of (AIFSN=2, CWmin = 15).
> the dominant factor. As Jérôme and Francois note, this puts DCF 
> traffic at, or just below, the very highest priority EDCA traffic.  
> So, this is quite different from Diffserv where "non-Diffserv" 
> defaults to Best Effort.  Here "non-EDCA" defaults to high channel 
> access priority.  This can be very harmful to very important DSRC/ITS 
> G5 traffic, especially traffic using AC_VI and below.
> 
> 3) I totally agree with the comments that caution not to be confused 
> by the Voice/Video/Best Effort/Background labels. Those are historical 
> and meant to be illustrative. In the ITS context it is simpler to 
> think of Highest/High/Medium/Low channel access priority. Those are 
> the terms used in SAE J2945/0 (clause 4.1.2.3), which makes 
> recommendations for mapping application classes to 802.11 access 
> categories.  I believe the channel access priority will generally be 
> independent of the L3 protocol [My personal opinion is if there is 
> correlation in the DSRC case I expect we would see higher priority 
> associated more often with WSMP (or ETSI equivalent) than with IPv6].  
> sent on different channels. So, the EDCA parameter set may well vary 
> by channel. This is exactly the case for the US DSRC band where SAE 
> J2945/1 defines a non-default EDCA parameter set for Channel 172.
> 
> Best Regards,
> John
> 
> 
> 
> On Mon, Feb 26, 2018 at 8:41 AM, Jérôme Härri 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Alex,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 14:18:35 +0100

Le 27/02/2018 à 13:15, Jérôme Härri a écrit :
>> I think that that potential harm can be avoided by IEEE in the 
>> first place; I think IEEE could specify - if deemed necessary - 
>> that OCB must only use QoS Data, and not Data. Currently IEEE 
>> allows both.
>> 
>> There is no open source available, as far as I know, that transmits
>> ITS messages as QoS Data. The implementations I have seen that send
>> CAM as QoS Data are closed source. They come from Unex, on ThreadX
>> operating system, Autotalks chipset. There may be others.
>> 
>> messages, and IP, as Data. They are available on github.com, are 
>> called 'rendits', 'vanetza', 'driveits', 'btpsap' and others.
>> 
>> Given that situation of software availability and IEEE situation, I
>> do not know how the recommendation above could be implemented.
>> 
>> Alex
> 
> Well IEEE 802.11-2016 OCB is agnostic to the criticality of the 
> traffic...(and I think it should remain so...).

I agree.

> It is WAVE and ETSI, which defined critical safety traffic and thus 
> imposed QoSData, as it is critically required for their 
> implementations and congestion control.

I did not know that.

> Now, using IPv6-over-OCB on the ITS-G5 bands follows the same 
> challenges as both BRAN (WLAN) and C-V2X...if it is used for 
> safety-related traffic, they should not create harmful interferences
>  with the current technology (DSRC/ITS-G5),

I agree with the principle to not create harmful interference.

One of the tools to avoid interference is the use of a distinct
EtherType for IP than for GeoNetworking (ETSI) and than for WSMP (WAVE).
  This draft does use 0x86DD distinct than the others.

Other tools could be: QoSData vs Data, and Access Category1 vs Category2.

If IP uses Data, and ETSI and WAVE use QoSData, then I suppose we are 
fine - there is no interference.

> which suggests (I am not a lawyer) that IPWAVE must use QoSData (at 
> least) and differentiate traffic to have access priority equivalent 
> to those defined by SAE/ETSI....

I can agree.  But it is impossible to impose the use of QoSData for IP
in these circumstances: there is no widely available source code for it.
  One may also question the IPR and the licensing scheme of that IP and
QoSData (since you say law).

> As mentioned, what does it cost to IPWAVE to recommend using QoSData

The text that allows IP to be transported as QoSData costs nothing.  You 
and I can write it.

But:
- is there running code for that text?
- will that text propagate existing, or create new, interoperability
   problems?

By interoperability problems I mean the following:
- whenever we use the word MAY, the later implementer will not know what
   to do.  E.g. "IPv6 MAY be transported as Data, or MAY be transported
   as QoSData" is a huge difficulty for implementer.  Which one to
   implement?
- the current interoperability problems: some stacks send CAM as QoSData
   and receivers expect it as Data.
- wireshark red packets: because dont know how to transform a QoSData
   packet into a EthernetII packet.

> Now, I am also a bit surprised: I have not been long enough in IETF I
> guess, but since when would IETF recommend a mechanism not because it
> is good, but because it is the only open-source code available??

Well, there is the mantra of 'rough consensus and running code'.  We are
in the 'running code' part.

To make running code I use open source.  That is IP transported on OCB
with 802.11 Data headers.

If someone else uses closed source, and have an implementation of IP 
over 802.11 OCB transported as QoSData, please speak up.

> If QoSData implementations are not available, let's make one...by 
> using QoSData instead of Data for IPWAVE,

I agree, but who is 'us' in 'let's make one'?  On my side I can not make
one.

I know unex/autotalks/threadx make one, because I can hear their CAM 
packets on QoSData.  But they dont say anything on this list, so I take 
that silence as absence.

In this situation, maybe there is somebody else that writes code to 
transport IP as QoSData?

> you will save a lot of discussions about spectrum neutrality and
> non-harmful interference, which might even block implementations
> using this very RFC.

Well, I agree the discussions can be long, and I would like to avoid at 
this time.

My speculation, is that with the RECOMMENDATION to transport IP only as 
Data (silence about QoSData), this draft can be pursued.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 27 Feb 2018 14:39:27 +0100

Hi Alex, 

A quick answer to the first part..

When I mention interference, I mean channel interference. The interference is even before you decode the packet and you know it is not WAVE/ETSI...it is fairness in accessing channel. If the (future) RFC uses IPv6 to transmit a big packet for sensor data on DIFS (so AIFN=2, so equivalent to AC_VI), it will access the channel at the same time as a DENM/event-BSM and thus will create a collision. As there is no spec (so far) in IETF on how to handle wireless congestion control (e.g. DCC), then the collision will reappear through IP retransmit...this is what I call harmful interference...

As for the second part, I agree that it would be good to have code...have you tried the open code from R. Lisov ́y at CTU Prague? "IEEE 802.11p Linux Kernel Implementation"...they integrated EDCA in the 802.11 part (but did not check how the kernel 'handles' QoSData...)

BR,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Tuesday 27 February 2018 14:19
To: Jérôme Härri; 'John Kenney'
Cc: 'François Simon'; 'Dr. Hans-Joachim Fischer'; 'Abdussalam Baryun'; 'Tony Li'; 'its'
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB

Le 27/02/2018 à 13:15, Jérôme Härri a écrit :
>> place; I think IEEE could specify - if deemed necessary - that OCB 
>> must only use QoS Data, and not Data. Currently IEEE allows both.
>> 

I agree.

I did not know that.

One of the tools to avoid interference is the use of a distinct EtherType for IP than for GeoNetworking (ETSI) and than for WSMP (WAVE).
  This draft does use 0x86DD distinct than the others.

If IP uses Data, and ETSI and WAVE use QoSData, then I suppose we are fine - there is no interference.

> least) and differentiate traffic to have access priority equivalent to 
> those defined by SAE/ETSI....

I can agree.  But it is impossible to impose the use of QoSData for IP in these circumstances: there is no widely available source code for it.
  One may also question the IPR and the licensing scheme of that IP and QoSData (since you say law).

> As mentioned, what does it cost to IPWAVE to recommend using QoSData  

The text that allows IP to be transported as QoSData costs nothing.  You and I can write it.

But:

> is good, but because it is the only open-source code available??

Well, there is the mantra of 'rough consensus and running code'.  We are in the 'running code' part.

To make running code I use open source.  That is IP transported on OCB with 802.11 Data headers.

If someone else uses closed source, and have an implementation of IP over 802.11 OCB transported as QoSData, please speak up.

> using QoSData instead of Data for IPWAVE,

I agree, but who is 'us' in 'let's make one'?  On my side I can not make one.

I know unex/autotalks/threadx make one, because I can hear their CAM packets on QoSData.  But they dont say anything on this list, so I take that silence as absence.

In this situation, maybe there is somebody else that writes code to transport IP as QoSData?

> non-harmful interference, which might even block implementations using 
> this very RFC.

Well, I agree the discussions can be long, and I would like to avoid at this time.

My speculation, is that with the RECOMMENDATION to transport IP only as Data (silence about QoSData), this draft can be pursued.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 15:53:59 +0100

Le 27/02/2018 à 14:39, Jérôme Härri a écrit :
> When I mention interference, I mean channel interference. The 
> interference is even before you decode the packet and you know it is 
> not WAVE/ETSI...it is fairness in accessing channel. If the (future) 
> RFC uses IPv6 to transmit a big packet for sensor data on DIFS (so 
> AIFN=2, so equivalent to AC_VI), it will access the channel at the 
> same time as a DENM/event-BSM and thus will create a collision. As 
> there is no spec (so far) in IETF on how to handle wireless 
> congestion control (e.g. DCC), then the collision will reappear 
> through IP retransmit...this is what I call harmful interference...
> 
> 
> As for the second part, I agree that it would be good to have 
> code...have you tried the open code from R. Lisov ́y at CTU Prague? 
> "IEEE 802.11p Linux Kernel Implementation"...

That paper refers to a 2014 OCB submission to the kernel.  Since then 
OCB was integrated in the mainline.  And yes, we do use that OCB.

> they integrated EDCA in the 802.11 part

How to use that EDCA?

There is no kernel option called 'EDCA' nor 'DCF'.

There is no option 'EDCA' or 'DCF' for the iw tool.

> (but did not check how the
> kernel 'handles' QoSData...)

I checked the 'rendits' software at github.com that generates CAM and 
Co. messages and none of them is transported as QoSData.  They are 
transported as Data.

Do you know how to make that work?

Alex

> 
> 
> BR,
> 
> Jérôme
> 
> -----Original Message----- From: Alexandre Petrescu 
> [mailto:[email-masked]] Sent: Tuesday 27 February 2018 
> 14:19 To: Jérôme Härri; 'John Kenney' Cc: 'François Simon'; 'Dr. 
> Hans-Joachim Fischer'; 'Abdussalam Baryun'; 'Tony Li'; 'its'
>>> There is no open source available, as far as I know, that 
>>> transmits ITS messages as QoS Data. The implementations I have 
>>> seen that send CAM as QoS Data are closed source. They come from 
>>> Unex, on ThreadX operating system, Autotalks chipset. There may 
>>> be others.
>>> 
>>> Given that situation of software availability and IEEE
>>> situation, I do not know how the recommendation above could be
>>> implemented.
>>> 
>>> Alex
>> 
>> safety-related traffic, they should not create harmful 
>> interferences with the current technology (DSRC/ITS-G5),
> 
> EtherType for IP than for GeoNetworking (ETSI) and than for WSMP 
> (WAVE). This draft does use 0x86DD distinct than the others.
> 
> I can agree.  But it is impossible to impose the use of QoSData for 
> IP in these circumstances: there is no widely available source code 
> for it. One may also question the IPR and the licensing scheme of 
> that IP and QoSData (since you say law).
> 
> But: - is there running code for that text? - will that text 
> propagate existing, or create new, interoperability problems?
> 
> By interoperability problems I mean the following: - whenever we use 
> the word MAY, the later implementer will not know what to do.  E.g. 
> "IPv6 MAY be transported as Data, or MAY be transported as QoSData" 
> is a huge difficulty for implementer.  Which one to implement? - the 
> current interoperability problems: some stacks send CAM as QoSData 
> and receivers expect it as Data. - wireshark red packets: because 
> dont know how to transform a QoSData packet into a EthernetII 
> packet.
> 
>> Now, I am also a bit surprised: I have not been long enough in
>> IETF I guess, but since when would IETF recommend a mechanism not 
>> because it is good, but because it is the only open-source code 
>> available??
> 
> packets on QoSData.  But they dont say anything on this list, so I 
> take that silence as absence.
> 
> My speculation, is that with the RECOMMENDATION to transport IP only 
> as Data (silence about QoSData), this draft can be pursued.
> 
> Alex
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Feb 2018 16:57:40 +0100

Le 27/02/2018 à 14:39, Jérôme Härri a écrit :
> "IEEE 802.11p Linux Kernel Implementation"...they integrated EDCA in
> the 802.11 part (but did not check how the kernel 'handles'
> QoSData...)

FYI, we also tried to ping -Q which does set a proper DSCP in the IPv4 
headers, yet there is no QoS Data header.

If someone knows how to generate a QoSData transported IP packet with 
linux open source then I am all ears.

Alex

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 27 Feb 2018 17:13:00 +0100

Hi,

> Is there a mapping between the Access Categories and IPv6 Traffic Class

Yes, since Traffic Class is currently used for the DSCP and ECN, see
rfc8325.

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 27 Feb 2018 17:26:15 +0100

Hi Alex,

see inline.

> a DSCP value is possible, unless some compression algorithm is used.

RFC 8325 provides DSCP-to-UP mapping recommendations, so it's at least a
suggestion for a default mapping. DSCPs can be chosen freely by DiffServ
providers, so a custom DSCP configuration needs also a customized
mapping then...

> number of inconsistencies and potential conflicts.

It is actually a DSCP 6-bit value to a 3-bit UP value, which is then
mapped to one of the four AC values.

> That is why I thik RFC8325 could be a good starting point, but there

Then you should clearly state what is actually missing there...

Regards
 Roland

---

From: Tony Li <[email-masked]>
Date: Tue, 27 Feb 2018 08:50:15 -0800

> If someone knows how to generate a QoSData transported IP packet with linux open source then I am all ears.

This is just a Small Matter Of Programming for anyone with a bit of kernel hacking experience and driver sources.

Tony

---

From: John Kenney <[email-masked]>
Date: Tue, 27 Feb 2018 18:29:33 -0800

Yes, I disagree.

I suggest:
NEW:
>  In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 QoS
Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) MUST be
set equal to binary 0001, corresponding to UP = 1.

Apologies if I don't have the IETF normative syntax right.

Note that UP = 1 maps to AC_BK.

Best Regards,
John

---

From: Tony Li <[email-masked]>
Date: Tue, 27 Feb 2018 18:34:58 -0800

> I suggest:
> NEW:
> >  In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11 QoS Data" frame. In the QoS Control Field, the TID subfield (Bits 0-3) MUST be set equal to binary 0001, corresponding to UP = 1. 
> 

The normative syntax looks fine to me. As long as you capitalize your MUSTs and it’s clear, it’s usually just fine.

Why is this somehow better than just sending it as data?  It’s worse, in that it’s more bits in the ether.  What are we getting for the cost?

Tony

---

From: Katrin Sjöberg <[email-masked]>
Date: Wed, 28 Feb 2018 07:08:24 +0100

Hi All,

I have followed the discussion in this thread from a helicopter perspective
and I might have missed emails and details but I would like to make a
comment regarding transmitting IPv6 over DCF.

In Europe, an IEEE 802.11p STA must use EDCA when transmitting data on the
5.9 GHz band (see Clause 4.6 in ETSI EN 302 663, standardizing layer 1 and
layer 2 of the OSI model for the 5.9 GHz band). This implies that the
current IETF proposal of using IPv6 over DCF would be impossible to use in
Europe.

If all IPv6 trafffic has to use a common EDCA access category, I would
support John's suggestion from an earlier email to fix IPv6 traffic to
AC_BK. As Jêróme pointed out, we use AC_BE for CAMs, and I know the US uses
AC_BE for some of their safety messages as well.

Best regards,
Katrin Sjöberg

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 07:47:17 +0100

> Then you should clearly state what is actually missing there...

I clearly state that what is missing is implementation.

We need this to work: ping -Q to issue 802.11 QoSData (instead of 802.11
Data) at 5.9GHz in OCB mode.

We tried to make it work but to no avail:
- OCB mode at 5.9GHz works fine with mainline linux kernel, driver
ath9k.
- ping -Q works fine, it generates the proper DSCP fields in the IP
header.
- the diffserv DSCP options are checked in the kernel.
- there is DSCP in the IP header but there is no 802.11 QoSData header
(there is 802.11 Data header).

Have you seen RFC8325 working?

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 28 Feb 2018 07:56:43 +0100

Hi Tony,

If you count every bits, then I would seriously argue why do we need the heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would do it without (I called heavy machinery the ND, DAD, etc…). 

Now, what we get is plain simple: coexistence…there is nothing without this.

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Wednesday 28 February 2018 03:35
To: John Kenney
Cc: Alexandre Petrescu; its
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution

I suggest:

 

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 08:07:44 +0100

Thank you for the message.

Le 28/02/2018 à 07:08, Katrin Sjöberg a écrit :
[...]
> This implies that the current IETF proposal of using IPv6 over DCF 
> would be impossible to use in Europe.

Unless, of course, we suggest modify the ETSI specification to allow for
802.11 Data headers as well as 802.11 QoS Data headers.

(there are many reasons to ponder over a major rehaul of ETSI ITS
specifications, starting at the CAM itself, that I could explain
separately).

> If all IPv6 trafffic has to use a common EDCA access category, I 
> would support John's suggestion from an earlier email to fix IPv6 
> traffic to AC_BK.

This could be done.  On my side I would need to see running code for it,
and then there is need of consensus (could be obvious from your standpoint).

> As Jêróme pointed out, we use AC_BE for CAMs,

Thank you for this message.  I understand you have an implementation of
CAM sent with IEEE 802.11 QoSData header.  Is it the one from Unex with
Autotalks chipset?

(the CAM implementations I use are from github.com and ath9k driver;
they dont generate 802.11 QoSData header, but use 802.11 Data header,
hence no AC_BE).

> and I know the US uses AC_BE for some of their safety messages as
> well.

I think me too, I have seen BSM messages carried with 802.11 QoSData
headers, field Priority value 2 Spare (Background); I guess that stands
for AC_BK.  But I could not figure out what was the software that
implemented it.

Alex

> 
> Best regards, Katrin Sjöberg
> 
> 
> 
> 2018-02-27 17:50 GMT+01:00 Tony Li <[email-masked] 
> <mailto:[email-masked]>>:
> 
> 
>> If someone knows how to generate a QoSData transported IP packet 
>> with linux open source then I am all ears.
> 
> 
> This is just a Small Matter Of Programming for anyone with a bit of 
> kernel hacking experience and driver sources.
> 
> Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 08:13:20 +0100

Jérôme,

Please count the bits.

The IPv6 header is 40bytes.

How long are the BTP and GeoNetworking headers?

I do not understand what do you mean more precisely by 'heavy machinery' 
and ND and DAD?  ND is just a request/reply, and DAD is optional in some 
cases.

Alex

Le 28/02/2018 à 07:56, Jérôme Härri a écrit :
> Hi Tony,
> 
> If you count every bits, then I would seriously argue why do we need the 
> heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would do it 
> without (I called heavy machinery the ND, DAD, etc…).
> 
> *Sent:* Wednesday 28 February 2018 03:35
> *To:* John Kenney
> *Cc:* Alexandre Petrescu; its
> IPv6-over-802.11-OCB - text modifications towards resolution
> 
> 
> 
> I suggest:
> 
> NEW:
> The normative syntax looks fine to me. As long as you capitalize your 
> MUSTs and it’s clear, it’s usually just fine.
> 
> Why is this somehow better than just sending it as data?  It’s worse, in 
> that it’s more bits in the ether.  What are we getting for the cost?
> 
> Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 08:39:13 +0100

John,

Obviously, we disagree.

If I had access to code that implements what you suggest then I would
not hesitate to write that text as you suggest ("MUST QoS Data, Qos
Control Field and TID 0001 and UP==1").

Until then, I ponder over removal altogher of the section Ethernet
Adaptation Layer from this draft, and move these QoS aspects in another
document. Maybe Carlos questioning of this EAL was right in the end.

Alex

Le 28/02/2018 à 03:29, John Kenney a écrit :
> Yes, I disagree.
> 
> I suggest: NEW:
>> In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE 802.11
>> QoS Data" frame. In the QoS Control Field, the TID subfield (Bits
> 0-3) MUST be set equal to binary 0001, corresponding to UP = 1.
> 
> Best Regards, John
> On Tue, Feb 27, 2018 at 2:43 AM, Alexandre Petrescu 
| 802.11 Data Header | LLC Header  | IPv6 Header | Payload |.11
> Trailer| 
| 802.11 QoS Data Hdr| LLC Header  | IPv6 Header | Payload |.11
> Trailer| 
> -- John Kenney Director and Principal Researcher Toyota
> InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA
> 94043 Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 28 Feb 2018 08:53:53 +0100

Hi Alex,

Sure, it is indeed 'just a request/reply', but these are bits as well and counts in the total IPv6' overhead. Btw, if you add BTP, then you need to add UDPv6/TCPv6 headers for IPv6 (ok, UDP to remain fair) as well, so 8 bytes.. 

Now, BTP is 4 bytes only (so we already save half from UDP), then Geonet common header is 35bytes, which is more or less all if you use Geonet for SHB...now of course, you need to add security trailers, which will be there for IPv6 as well...

And if you use geonet with geobroadcast, indeed the header is indeed increased by an extra 48 bytes...but you will need this on top of IP as well  if you need to do multi-hop routing anyways...so, when comparing geonet with pure IPv6, we should define it on a similar task: 1-hop broadcast (no routing)..if you need to do routing, in particular geonet routing, then things get messy in both cases (let's look at MANET headers then...).
 
For ETSI, beside the 'indeed' unfortunate double position in geonet and CAM, there is no extra overhead, no need for request/reply, no need for DAD under any circumstance....We get our address directly and the neighbors are obtained through the Geonet header of CAM/DENN (CAM compulsory at 2Hz minimum in EU, so largely enough for NET routing)...

I yet already mentioned that indeed, using IPv6 over Geonet then creates overhead (kind of double), as you still have the IPv6 machinery and you encapsulate IPv6 in geonet (so, triple header)...that is my initial reason for working on IPWAVE...so, for use cases clearly requiring IPv6, it could be worth going directly with OCB rather than Geonet...but my assumption here is that what I need to transmit cannot be transmitted efficiently with pure Geonet/WAVE...

BR,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Wednesday 28 February 2018 08:13
To: Jérôme Härri; 'Tony Li'; 'John Kenney'
Cc: 'its'; 'Katrin Sjöberg'
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards resolution

Jérôme,

Please count the bits.

I do not understand what do you mean more precisely by 'heavy machinery' 
and ND and DAD?  ND is just a request/reply, and DAD is optional in some cases.

Alex

Le 28/02/2018 à 07:56, Jérôme Härri a écrit :
> Hi Tony,
> 
> If you count every bits, then I would seriously argue why do we need 
> the heavy IPv6 machinery to transmit over OCB, when WSN/Geonet would 
> do it without (I called heavy machinery the ND, DAD, etc…).
> 
> Why is this somehow better than just sending it as data?  It’s worse, 
> in that it’s more bits in the ether.  What are we getting for the cost?
> 
> Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 09:19:24 +0100

Le 28/02/2018 à 08:53, Jérôme Härri a écrit :
> Hi Alex,
> 
> Sure, it is indeed 'just a request/reply', but these are bits as well
> and counts in the total IPv6' overhead. Btw, if you add BTP, then you
> need to add UDPv6/TCPv6 headers for IPv6 (ok, UDP to remain fair) as
> well, so 8 bytes..
> 
> Now, BTP is 4 bytes only (so we already save half from UDP), then
> Geonet common header is 35bytes,

Ah, so 39 bytes of Geonet-plus-BTP is smaller than 40 bytes of IPv6 header.

> which is more or less all if you use Geonet for SHB...now of course,
> you need to add security trailers, which will be there for IPv6 as
> well...
> 
> And if you use geonet with geobroadcast, indeed the header is indeed
> increased by an extra 48 bytes...but you will need this on top of IP
> as well  if you need to do multi-hop routing anyways...so, when
> comparing geonet with pure IPv6, we should define it on a similar
> task: 1-hop broadcast (no routing)..if you need to do routing, in
> particular geonet routing, then things get messy in both cases (let's
> look at MANET headers then...).
> 
> For ETSI, beside the 'indeed' unfortunate double position in geonet
> and CAM, there is no extra overhead, no need for request/reply, no
> need for DAD under any circumstance....

(IPv6 can also work that way: send the CAM as IPv6 payload, as 
multicast.  There is no need of ND nor DAD for that to work.)

> We get our address directly
> and the neighbors are obtained through the Geonet header of CAM/DENN
> (CAM compulsory at 2Hz minimum in EU, so largely enough for NET
> routing)...
> 
> I yet already mentioned that indeed, using IPv6 over Geonet then
> creates overhead (kind of double), as you still have the IPv6
> machinery and you encapsulate IPv6 in geonet (so, triple
> header)...that is my initial reason for working on IPWAVE...so, for
> use cases clearly requiring IPv6, it could be worth going directly
> with OCB rather than Geonet...but my assumption here is that what I
> need to transmit cannot be transmitted efficiently with pure
> Geonet/WAVE...

I agree.

Let me go back to the cost comparison request of Tony.

An 802.11 QoS Data Header is longer than a 802.11 Data Header by two 
bytes.  This 2-byte 'QoS Control' field is only present in the QoS Data 
header, but absent from the Data header.  Is its presence worth?

Alex

> [mailto:[email-masked]] Sent: Wednesday 28 February
> 2018 08:13 To: Jérôme Härri; 'Tony Li'; 'John Kenney' Cc: 'its';
> 'Katrin Sjöberg' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data
> in IPv6-over-802.11-OCB - text modifications towards resolution
> 
> Jérôme,
> 
> Please count the bits.
> 
> I do not understand what do you mean more precisely by 'heavy
> machinery' and ND and DAD?  ND is just a request/reply, and DAD is
> optional in some cases.
> 
> Alex
> 
>> If you count every bits, then I would seriously argue why do we
>> need the heavy IPv6 machinery to transmit over OCB, when WSN/Geonet
>> would do it without (I called heavy machinery the ND, DAD, etc…).
>> 
>> *Sent:* Wednesday 28 February 2018 03:35 *To:* John Kenney *Cc:*
>> Alexandre Petrescu; its *Subject:* Re: [ipwave] 802.11 Data vs
>> 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications
>> towards resolution
>> 
>> 
>> 
>> I suggest:
>> 
>> NEW:
>>> In OCB mode, an IPv6 packet MUST be transmitted as an "IEEE
>>> 802.11 QoS Data" frame. In the QoS Control Field, the TID
>>> subfield (Bits 0-3) MUST be set equal to binary 0001,
>>> corresponding to UP = 1.
>> 
>> 
>> 
>> The normative syntax looks fine to me. As long as you capitalize
>> your MUSTs and it’s clear, it’s usually just fine.
>> 
>> Why is this somehow better than just sending it as data?  It’s
>> worse, in that it’s more bits in the ether.  What are we getting
>> for the cost?
>> 
>> Tony
>> 
> 
>

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 28 Feb 2018 09:42:57 +0100

Hi Alex,

>An 802.11 QoS Data Header is longer than a 802.11 Data Header by two bytes.  This 2-byte 'QoS Control' field is only present in the QoS Data header, but absent from the Data header.  Is its presence worth?

>From my perspective, it does...two bytes is not much if it avoids issues with other technologies...let's call it coexistence cost :-) 

BR,

Jérôme

>> 802.11 QoS Data in IPv6-over-802.11-OCB - text modifications towards 
>> resolution
>> 
>> 
>> 
>> I suggest:
>> 
>> NEW:
>>> 802.11 QoS Data" frame. In the QoS Control Field, the TID subfield 
>>> (Bits 0-3) MUST be set equal to binary 0001, corresponding to UP = 
>>> 1.
>> 
>> 
>>

---

From: Michelle Wetterwald <[email-masked]>
Date: Wed, 28 Feb 2018 09:58:00 +0100

Hi Alex,

I fully agree with Katrin and was about to send a similar post, as the EDCA
queues are used also by ITS-G5 for the DCC, which is mandated by the new EU
regulation.

Unless you want to rewrite all ETSI standards and related European norms in
a couple of  weeks, I would suggest to keep the old text and guarantee
openness for using the IEEE 802.16-16 standard while complying to local
regulations.

I would also suggest to bring this topic, as well as the handling of QoS
for IPWAVE, which is an interesting topic, to the re-chartering discussion
that was proposed by Carlos-Jesus a few weeks ago. The same as we did for
ND or this nice multicast address that would be reserved for IPWAVE
services.

BTW, you really plan to send CAMs directly over IPv6, without any transport
layer? I thought you would use UDP, which has a "large" header as well.
BTP and GeoNetworking.

Michelle

2018-02-28 8:07 GMT+01:00 Alexandre Petrescu <[email-masked]>:

>> This implies that the current IETF proposal of using IPv6 over DCF would
>> be impossible to use in Europe.
>>
>
>> 2018-02-27 17:50 GMT+01:00 Tony Li <[email-masked] <mailto:
>> [email-masked]>>:
>>
>>
>> [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/l
>> istinfo/its <https://www.ietf.org/mailman/listinfo/its>
>>
>>
>>

-- 
Michelle Wetterwald
[email-masked]

---

From: Michelle Wetterwald <[email-masked]>
Date: Wed, 28 Feb 2018 10:02:27 +0100

I meant IEEE 802.11-2016, of course...

2018-02-28 9:58 GMT+01:00 Michelle Wetterwald <[email-masked]>:

> Hi Alex,
>
> I fully agree with Katrin and was about to send a similar post, as the
> EDCA queues are used also by ITS-G5 for the DCC, which is mandated by the
> new EU regulation.
>
> Unless you want to rewrite all ETSI standards and related European norms
> in a couple of  weeks, I would suggest to keep the old text and guarantee
> BTW, you really plan to send CAMs directly over IPv6, without any
> transport layer? I thought you would use UDP, which has a "large" header as
> well.
> 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu <[email-masked]
> >:
>

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 28 Feb 2018 10:03:02 +0100

Hi,

> Have you seen RFC8325 working?

Thanks for the clarification. IMHO this is a pure implementation
problem, not a conceptual problem with the standards.
RFC8325 is pretty new, but I expect that some recent APs from
a larger vendor will support this, since they did the proposal.

Regards
 Roland

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 10:27:31 +0100

Le 28/02/2018 à 09:50, Mie Eur a écrit :
> Hi Alex,
> 
> I fully agree with Katrin and was about to send a similar post, as 
> the EDCA queues are used also by ITS-G5 for the DCC, which is 
> mandated by the new EU regulation.

I would really be surprised that EU mandates something that depends
on closed source, potentially favoring a competitive edge to a
particular private interest.  But I am optimistic: given all the
stimulation of open source in EU projects I believe EU regulators
understand the implications related to cost, licensing, and
interoperability.

> Unless you want to rewrite all ETSI standards and related European 
> norms in a couple of  weeks,

In one of these days I will post a critique of the CAM specification.

> I would suggest to keep the old text and guarantee openness for using
> the IEEE 802.11-16 standard while complying to local regulations.

YEs, we need that.

But the old text says:
> "In OCB mode, IPv6 packets MAY be transmitted either as "IEEE 802.11
>  Data" or alternatively as "IEEE 802.11 QoS Data"

I implement only the 802.11 Data and my partner(s) use equipment bought
from Unex that only implements QoS Data.  I want our software to
interoperate.

If the text said just 'Data', then I could direct my partners to the
open source on the Internet.  But in current situation my partners
direct me to Unex, which is expensive - it has a cost.

I do not agree to continue this situation.

Either the QoSData supporters direct me to an open source implementation
of QoSData now, or we relegate the QoS discussion for later.

> I would also suggest to bring this topic, as well as the handling of
>  QoS for IPWAVE, which is an interesting topic, to the re-chartering
>  discussion that was proposed by Carlos-Jesus a few weeks ago. The 
> same as we did for ND or this nice multicast address that would be 
> reserved for IPWAVE services.

I agree.

> transport layer? I thought you would use UDP, which has a "large" 
> header as well. (found in an "old" post dated back from 4 days ago. 
> )

At this time, with partners, we ponder the idea of a different CAM if
you wish (not sure whether UDP, or just IP, or 802.11 Data, or 802.11
QoS Data).  This different CAM is interoperable and cheap to produce.

CAM over UDP over IPv6 was already produced by others in other project.
  I think they didnt bother to standardise it, but it worked for them.  I
am tempted to copy from them.

Alex

> :
>>> CAM transported in IP may be a smaller packet than CAM 
>>> transported
> in BTP and GeoNetworking.
> 
> 
> <mailto:[email-masked]>>:
> 
> Le 28/02/2018 à 07:08, Katrin Sjöberg a écrit : [...]
> 
> Unless, of course, we suggest modify the ETSI specification to allow
>  for 802.11 Data headers as well as 802.11 QoS Data headers.
> 
> This could be done.  On my side I would need to see running code for
>  it, and then there is need of consensus (could be obvious from your
>  standpoint).
> 
> Thank you for this message.  I understand you have an implementation
>  of CAM sent with IEEE 802.11 QoSData header.  Is it the one from
> Unex with Autotalks chipset?
> 
> (the CAM implementations I use are from github.com 
> <http://github.com> and ath9k driver; they dont generate 802.11 
> QoSData header, but use 802.11 Data header, hence no AC_BE).
> 
> headers, field Priority value 2 Spare (Background); I guess that 
> stands for AC_BK.  But I could not figure out what was the software 
> that implemented it.
> 
> Alex
> 
> 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>:
> 
> 
> <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/its 
> <https://www.ietf.org/mailman/listinfo/its 
> <https://www.ietf.org/mailman/listinfo/its>>
> 
> 
> 
> -- Michelle WETTERWALD

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 10:41:19 +0100

> problem, not a conceptual problem with the standards.

Right, it is not a conceptual problem with the standards - it's just a 
mapping.  It can work.  It _can_.

When do we want to submit a draft to IESG to consider to become an RFC: 
when the implementation exists already?  or before?

Because some drafts get submitted, some become RFCs, and some never get 
the success one expects them to (read: no implementation).

> a larger vendor will support this, since they did the proposal.

Thanks for the clarification.

Since RFC8325 is on the Standards Track, I believe there should be more 
than just one vendor supporting it (otherwise it were EXPERIMENTAL or 
INFORMATIONAL).  Maybe that vendor proposed an implementation as open 
source, and agreed somehow by some non-that-vendor implementers.

If the vendor tells us what is the implementation of RFC8325, we can 
tell them how to use it on an additional kind of Access Points: an IP 
Road-Side Unit to connect cars.

Alex

---

From: Katrin Sjöberg <[email-masked]>
Date: Wed, 28 Feb 2018 10:47:49 +0100

Hi Alexandre, All,

We are mixing apples and pears in this discussion and it is very
frustrating. On one hand, the discussion is about detailed open source
software implementations that do not support QoS data with how the EU
mandate will look like.

First of all, the QoS data is handled by the chipset covering MAC+PHY on
top of this LLC resides. IPv6 is on top of LLC. And suddenly the CAM
specification, which is residing in the facilities layer is discussed. What
is the problem with making EDCA mandatory in this standard? The amendment
IEEE 802.11e, which introduced the concept of EDCA, was approved in 2005
and it was a unique selling point for WiFi APs in the beginning. EDCA has
been around for 13 years and this standard developed in 2018 for supporting
IPv6 in VANETs when using IEEE 802.11p wants to use DCF due to some
existing implementation... For me this is like being thrown back to the
stone age.

I am working for an OEM and I cannot accept that this standard will allow
IPv6 traffic over IEEE 802.11p using DCF since it might adventure road
traffic safety applications that are under development. We want to reduce
the number of accidents and the impact of the same by using IEEE 802.11p
with EDCA and suddenly messages such as CAMs might be starved out because
someone is transmitting IPv6 traffic using DCF. This is not acceptable and
once again I want to emphasize that EN 302 663 in Europe requires EDCA,
which would prohibit this standard to use the 5.9 GHz band.

Best regards,
Katrin

2018-02-28 10:27 GMT+01:00 Alexandre Petrescu <[email-masked]>
:

>> in a couple of  weeks,
>>  discussion that was proposed by Carlos-Jesus a few weeks ago. The same
>> as we did for ND or this nice multicast address that would be reserved for
>> IPWAVE services.
>>
>
> I agree.
>
>> well. (found in an "old" post dated back from 4 days ago. )
>>
>
>>> CAM transported in IP may be a smaller packet than CAM transported
>>>>
>> 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu <
>> [email-masked] <mailto:[email-masked]>>:
>>
>> (the CAM implementations I use are from github.com <http://github.com>
>> and ath9k driver; they dont generate 802.11 QoSData header, but use 802.11
>> Data header, hence no AC_BE).
>>
>> and I know the US uses AC_BE for some of their safety messages as well.
>>
>>
>> headers, field Priority value 2 Spare (Background); I guess that stands for
>> AC_BK.  But I could not figure out what was the software that implemented
>> it.
>>
>> Alex
>>
>>
>> [email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>:
>>
>>
>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:
>> [email-masked]>> https://www.ietf.org/mailman/listinfo/its <
>> https://www.ietf.org/mailman/listinfo/its> <https://www.ietf.org/mailman/
>> listinfo/its <https://www.ietf.org/mailman/listinfo/its>>
>>
>>
>>

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 28 Feb 2018 09:48:33 +0000

+1 Jérôme

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

On Wed, Feb 28, 2018 at 6:56 AM, Jérôme Härri <[email-masked]>
wrote:

> *From:* its [mailto:[email-masked]] *On Behalf Of *Tony Li

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 10:57:23 +0100

Le 28/02/2018 à 09:42, Jérôme Härri a écrit :
>> An 802.11 QoS Data Header is longer than a 802.11 Data Header by
>> two bytes.  This 2-byte 'QoS Control' field is only present in the
>> QoS Data header, but absent from the Data header.  Is its presence
>> worth?
> 
>> From my perspective, it does...two bytes is not much if it avoids
>> issues with other technologies...let's call it coexistence cost :-)

We need coexistence.

To achieve it, these are the costs from my perspective at this time:

- cost of proving the interoperability of at least two distinct
   implementations of QoS Data header.
- cost of writing open source code to make QoS Data header work
   or, alternatively,
- cost of acquiring a QoS Data implementation (I can quote Euro costs
   from two distinct manufacturers; it's in the range of thousand Euros
   per license, but includes many other ITS G5 functionalities)

- cost of two bytes on wire for QoS Data
- cost of two lines of text in an Internet Draft

Do you see other costs?

Alex

>> 'Katrin Sjöberg' Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS
>> Data in IPv6-over-802.11-OCB - text modifications towards
>> resolution
>> 
>> Jérôme,
>> 
>> Please count the bits.
>> 
>>> need the heavy IPv6 machinery to transmit over OCB, when
>>> WSN/Geonet would do it without (I called heavy machinery the ND,
>>> DAD, etc…).
>>>

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 28 Feb 2018 11:04:43 +0100

Hi Alexandre,

> when the implementation exists already?  or before?

Short answer:
Right now we have only two standard maturity levels left:
Proposed Standard and Internet Standard.
Normally (exception mentioned below) you don't need two
independent different interoperable implementations for publishing
a Proposed Standard.

Longer answer:
However, more detailed guidance provides https://tools.ietf.org/html/rfc7127

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   [...]

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

So for Internet Standard:

   A specification for which significant implementation and successful
   operational experience has been obtained may be elevated to the
   Internet Standard level.

> the success one expects them to (read: no implementation).

Even if you have implementations it does not mean that it is widely
used. So implementations are hardly a measure for success, but running
code is always good to have to show that it's viable. I was involved in
a WG where people had strong objections and found the protocols too
complex. This really wasn't the case as we had several implementations
done by students...however, the opponents just ignored the running code...

> source, and agreed somehow by some non-that-vendor implementers.

No, it's not how it works, see above. Proposed Standard is usually
considered to be good enough to get interoperable implementations.
Internet-Drafts with available (or even open) implementations are often
considered as being better than those without. So running code is
usually considered being a plus for I-Ds or PS documents, but it's
normally not required unless solicited by the IESG.

Regards
 Roland

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 11:09:07 +0100

Le 28/02/2018 à 10:47, Katrin Sjöberg a écrit :
> frustrating. On one hand, the discussion is about detailed open 
> source software implementations that do not support QoS data with
> how the EU mandate will look like.

EU must take great care when mandating technologies.

> First of all, the QoS data is handled by the chipset covering
> MAC+PHY on top of this LLC resides.

I agree.

We use ath9k driver and mac80211 module in the linux kernel.

> IPv6 is on top of LLC.

Yes.

> And suddenly the CAM specification, which is residing in the 
> facilities layer is discussed.

I agree.  Speaking CAM here is a stretch.  The stretch comes from my
single possible way (with BSM) to notice the existence of these QoS Data
headers.  I should have rather said "QoS Data transported message, e.g.
CAM or BSM".

When I say I have problems with CAM, and I will post a critique of it,
is with the CAM message encoding, and lack of interoperability of that
CAM.  I do not critique the fact that QoS Data transports CAM.

> What is the problem with making EDCA mandatory in this standard?

The problem is the lack of implementations.

> The amendment IEEE 802.11e, which introduced the concept of EDCA, was
> approved in 2005 and it was a unique selling point for WiFi APs in
> the beginning. EDCA has been around for 13 years and this standard
> developed in 2018 for supporting IPv6 in VANETs when using IEEE
> 802.11p wants to use DCF due to some existing implementation... For
> me this is like being thrown back to the stone age.

Sorry, not the intention to throw back to stone age.

But I need implementation.

> I am working for an OEM

Is OEM implementing QoS Data?

> and I cannot accept that this standard will 
> allow IPv6 traffic over IEEE 802.11p using DCF since it might 
> adventure road traffic safety applications that are under 
> development. We want to reduce the number of accidents and the
> impact of the same by using IEEE 802.11p with EDCA and suddenly
> messages such as CAMs might be starved out because someone is
> transmitting IPv6 traffic using DCF. This is not acceptable and once
> again I want to emphasize that EN 302 663 in Europe requires EDCA,

Hold on, hold on.  Excuse me.

Road traffic safety applications is also a huge worry for designers 
using IP packets.

But, the spectrum is for everyone to coexist and interoperate.

Alex

> 
> Best regards, Katrin
> 
> 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu 
> I implement only the 802.11 Data and my partner(s) use equipment 
> bought from Unex that only implements QoS Data.  I want our software 
> to interoperate.
> 
> Either the QoSData supporters direct me to an open source 
> implementation of QoSData now, or we relegate the QoS discussion for 
> later.
> 
> CAM over UDP over IPv6 was already produced by others in other 
> project. I think they didnt bother to standardise it, but it worked 
> for them.  I am tempted to copy from them.
> 
> Alex
> 
> :
> 
> 2018-02-28 8:07 GMT+01:00 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked]>>>:
> 
> <http://github.com> <http://github.com> and ath9k driver; they dont 
> generate 802.11 QoSData header, but use 802.11 Data header, hence no 
> AC_BE).
> 
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]>>>>:
> 
> 
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>> 
> <https://www.ietf.org/mailman/listinfo/its>>>
> 
> 
>

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 28 Feb 2018 11:36:25 +0100

Hi Alex,

The biggest cost I see is the RFC being blocked for being used both in US and EU, which means hundreds of hours of work by the IETF for nothing. This should not be underestimated...

If a standard cannot be passed because there is no open-source implementation, well nothing will work...the world is full of closed source implementation that we need to pay for it (look at 3GPP and the cellular world...)...I mean you preach to the choir, I am a strong supporter to open-source implementation, but I am not ready to block a specification because no open source exist. 

BR,

Jérôme

---

From: Michelle Wetterwald <[email-masked]>
Date: Wed, 28 Feb 2018 11:38:08 +0100

Hi Alex,

Regarding the interoperability between different implementations, it has
been fully validated during numerous plugtests events in EU and US,
gathering a large set of different implementations. For the EU ones, the
reports are freely available on the ETSI web site.

I am sorry to hear that the open source implementation that you are using
has some limitations. I remember that one of the participants to the last
PlugTest in Livorno (Nov 2016) explained to me he had extended the open
source software to use his computer to monitor the traffic exchanged on the
802.11p. So he made his Ath implementation fully interoperable with those
from the other vendors. Maybe you can apply similar upgrades to your
testing implementations?

Again, I disagree with the change you propose in the text of the draft, as
it goes against the *existing* EU regulations. Compliance with the modified
text would prevent vendors from accessing the EU market.

BR,
Michelle

2018-02-28 11:09 GMT+01:00 Alexandre Petrescu <[email-masked]>
:

>> software implementations that do not support QoS data with
> And suddenly the CAM specification, which is residing in the facilities
>> layer is discussed.
>>
>
> and I cannot accept that this standard will allow IPv6 traffic over IEEE
>> 802.11p using DCF since it might adventure road traffic safety applications
>> that are under development. We want to reduce the number of accidents and
>> the
> Road traffic safety applications is also a huge worry for designers using
> IP packets.
>
>> 2018-02-28 10:27 GMT+01:00 Alexandre Petrescu <
>> I would really be surprised that EU mandates something that depends on
>> closed source, potentially favoring a competitive edge to a particular
>> private interest.  But I am optimistic: given all the stimulation of open
>> source in EU projects I believe EU regulators understand the implications
>> related to cost, licensing, and interoperability.
>>
>> CAM over UDP over IPv6 was already produced by others in other project. I
>> think they didnt bother to standardise it, but it worked for them.  I am
>> tempted to copy from them.
>>
>> Alex
>>
>> :
>>
>> [email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]
>> >>>:
>>
>> (the CAM implementations I use are from github.com <http://github.com> <
>> http://github.com> and ath9k driver; they dont generate 802.11 QoSData
>> header, but use 802.11 Data header, hence no AC_BE).
>>
>> [email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>> [email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:
>> [email-masked] <mailto:[email-masked]>>> https://www.ietf.org/mailman/l
>> istinfo/its <https://www.ietf.org/mailman/listinfo/its> <
>> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/
>> listinfo/its>> <https://www.ietf.org/mailman/listinfo/its <
>> listinfo/its <https://www.ietf.org/mailman/listinfo/its>>>
>>
>>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 12:15:58 +0100

Le 28/02/2018 à 11:04, Bless, Roland (TM) a écrit :
[...]
>     behavior that may have significant operational impact on the

In my humble oppinion, this draft IPv6-over-OCB -19:
- has not resolved known design choices. (Data vs QoSData)
- has received significant review
- appears to enjoy community interest

I am not IESG so I dont know what to think about what IESG will request.

 From past experience in other RFCs I learned it is always good to have 
interoprable implementations before going to IESG.

> normally not required unless solicited by the IESG.

You think we dont need two different implementations to interoperate 
before going to IESG?

Alex

---

From: Alexandre PETRESCU <[email-masked]>
Date: Wed, 28 Feb 2018 12:22:52 +0100

[trimmed the CC because mailer problems]

> reports are freely available on the ETSI web site.

I am using the wireshark dissectors on the ETSI web site.

I can tell they show lack of interoperability: several CAM messages from 
several stacks are not understood by these wireshark dissectors.

The ETSI wireshark dissectors have another problem themselves: they are 
not integrated in the main wireshark software.  It's just ETSI's point 
of view.

> I am sorry to hear that the open source implementation that you are 
> using has some limitations. I remember that one of the participants to 
> the last PlugTest in Livorno (Nov 2016) explained to me he had extended 
> the open source software to use his computer to monitor the traffic 
> exchanged on the 802.11p. So he made his Ath implementation fully 
> interoperable with those from the other vendors. Maybe you can 
> apply similar upgrades to your testing implementations?

Can you tell me who is that participant so I can contact?

> Again, I disagree with the change you propose in the text of the draft, 
> as it goes against the *existing* EU regulations. Compliance with the 
> modified text would prevent vendors from accessing the EU market.

Accessing EU market is a good thing, but customer lock in may not be 
that good.

Alex

> BR,
> Michelle
> 
> 
> 2018-02-28 11:09 GMT+01:00 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>:
> 
> 
> 
>         and I cannot accept that this standard will allow IPv6 traffic
>         over IEEE 802.11p using DCF since it might adventure road
>         traffic safety applications that are under development. We want
>         to reduce the number of accidents and the
>         I fully agree with Katrin and was about to send a similar post,
>         as the EDCA queues are used also by ITS-G5 for the DCC, which is
>         I would really be surprised that EU mandates something that
>         depends on closed source, potentially favoring a competitive
>         edge to a particular private interest.  But I am optimistic:
>         given all the stimulation of open source in EU projects I
>         believe EU regulators understand the implications related to
>         cost, licensing, and interoperability.
> 
>         Unless you want to rewrite all ETSI standards and related
>         European norms in a couple of  weeks,
> 
> 
>         bought from Unex that only implements QoS Data.  I want our
>         software to interoperate.
> 
>           open source on the Internet.  But in current situation my
>         partners direct me to Unex, which is expensive - it has a cost.
> 
>         implementation of QoSData now, or we relegate the QoS discussion
>         for later.
> 
>           discussion that was proposed by Carlos-Jesus a few weeks ago.
>         The same as we did for ND or this nice multicast address that
>         would be reserved for IPWAVE services.
> 
> 
>         I agree.
> 
>         BTW, you really plan to send CAMs directly over IPv6, without
>         any transport layer? I thought you would use UDP, which has a
>         "large" header as well. (found in an "old" post dated back from
>         4 days ago. )
> 
> 
>         project. I think they didnt bother to standardise it, but it
>         worked for them.  I am tempted to copy from them.
> 
>         Alex
> 
>         :
> 
>         <mailto:[email-masked]>>>>:
> 
>         This implies that the current IETF proposal of using IPv6 over
>         DCF would be impossible to use in Europe.
> 
> 
>         (there are many reasons to ponder over a major rehaul of ETSI
>         ITS specifications, starting at the CAM itself, that I could
>         explain separately).
> 
>         would support John's suggestion from an earlier email to fix
>         IPv6 traffic to AC_BK.
> 
> 
>         <http://github.com> <http://github.com> <http://github.com> and
>         ath9k driver; they dont generate 802.11 QoSData header, but use
>         802.11 Data header, hence no AC_BE).
> 
>         I think me too, I have seen BSM messages carried with 802.11
>         QoSData headers, field Priority value 2 Spare (Background); I
>         guess that stands for AC_BK.  But I could not figure out what
>         was the software that implemented it.
> 
>         Alex
> 
> 
>         <mailto:[email-masked]>>> <mailto:[email-masked]
>         <mailto:[email-masked]>>>>>:
> 
> 
>         This is just a Small Matter Of Programming for anyone with a bit
>         of kernel hacking experience and driver sources.
> 
>         Tony
> 
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>> <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>>
>         <https://www.ietf.org/mailman/listinfo/its>>>>
> 
> 
> 
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 12:24:10 +0100

Le 28/02/2018 à 11:36, Jérôme Härri a écrit :
> Hi Alex,
> 
> The biggest cost I see is the RFC being blocked for being used both
> in US and EU, which means hundreds of hours of work by the IETF for
> nothing. This should not be underestimated...
> 
> If a standard cannot be passed because there is no open-source
> implementation, well nothing will work...the world is full of closed
> source implementation that we need to pay for it (look at 3GPP and
> the cellular world...)...I mean you preach to the choir, I am a
> strong supporter to open-source implementation, but I am not ready to
> block a specification because no open source exist.

This is why, maybe, it is just good to free away the part that disturbs 
(Ethernet Adaptation Layer with the QoS doubt).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 13:07:31 +0100

Michelle,

This is a critique of the CAM message format ETSI EN 302 637-2 V1.3.1
interpreted together with ETSI TS 102 894-2 V1.2.1 "Applications and
facilities layer common data dictionary".

(I purposefully exclude the QoSData vs Data part; it is another discussion)

Here is my critique of specification of CAM message format:

- in general, it is impossible to say, when reading the specification of
   the CAM message, what is the length of some of the fields.
   Because of this reason, it is impossible to decide what is the total
   length of a minimal CAM without optional parts.
   It is impossible to answer whether a CAM fits in the MTU of
   IPv6-over-OCB.
   Because of this, it is impossible to easily obtain interoperable
   implementations.

   Example: what is the length of the Latitude field?  The spec gives the
   value range -900000000..900000001, but  does not say on how many bits.
   That value range can fit in 31bit (upper (log_2 (1800000002))).
   Some implementations do it on 32bit.  But why 32 bit and not 31bit?

   (other fields where this doubt exists can be listed here: Acceleration
    Confidence values 0 to 102 but on how many bits, and many others).

- the encoding is not expressed as Type Length Value (TLV).  This is a
   common way of expressing message encoding when writing Internet
   Drafts.

   Because of this, a receiver of CAM has difficulty in dealing with
   options, variable lengths, etc.

- the GenerationDeltaTime field is within a given window of width 16bit
   in milliseconds, and does not represent absolute time.  It is the
   remainder of timestamp/65k.  The timestamp itself is not sent.  This
   is obviously a problem.  Ideally, one should the use 64bit timestamp
   instead, not some remainder results or modulo calculation.

- the latitude and longitude are expressed in relationship to WGS84,
   whereas an international standard would be more appropriate.  Europe?

- the latitude and longitude seems to be represented on same number of
   32 bits by some implementations, whereas the range of values is
   obviously different (-90 to +90 vs -180 to +180).  It could also be
   31bit vs 32bit.

- the confidence values are different than what GNSS chips offer as
   standard (HDOP, VDOP, HDOP).  Because of this conversion will be
   needed, add to the lack of confidence.

- when transported with a GeoNetworking header, one can find lat/long
   expressed twice: once in the CAM and once in the geonet header.

- the speed values, as specified, can not go higher than 589kmph.  But
   there are cars that go faster than that on circuit (check the record).

- there is nothing about alignment of data.  The alignment of different
   fields on boundaries (like 8bit, or other) are of utmost importance to
   implementer.  This lead to necessity of padding sometimes, and padding
   must be specified.

Alex

---

From: Michelle Wetterwald <[email-masked]>
Date: Wed, 28 Feb 2018 14:58:19 +0100

Hi Alex,

Answers inline.

> several stacks are not understood by these wireshark dissectors.

Can you give references to these stacks?

> not integrated in the main wireshark software.  It's just ETSI's point of
> view.
>

Sorry, NDA applies here. But the list of vendors is in the report.

> Accessing EU market is a good thing, but customer lock in may not be that
> good.
>

This is not customer lock-in, there are several and diverse implementations
available (BTW, this is more an L2 than an L3-IETF related topic), the only
thing is that you have to pay for getting them, which is often part of the
market rules, right? Is there a requirement that an RFC can be approved
only if several open source implementations are available?

I am not sure what to think about that. What would be the usefulness of a
standard that prevents accessing part of the main markets?
If you believe that the standard is not relevant any more, then it would be
better to state it clearly and the WG can proceed on this basis.

BR, Michelle

>
> Alex
>
> BR,
>> Michelle
>>
>>
>> 2018-02-28 11:09 GMT+01:00 Alexandre Petrescu <

---

From: Michelle Wetterwald <[email-masked]>
Date: Wed, 28 Feb 2018 14:59:56 +0100

Hi Alex,

I am not representing ETSI and I am wondering whether this is the right
place to discuss about the content of ETSI standards.
I rather encourage you to submit a contribution to that group.

BR, Michelle

---

From: Alexandre PETRESCU <[email-masked]>
Date: Wed, 28 Feb 2018 15:08:46 +0100

--
Alexandre Petrescu
[email-masked], tél 0169089223

Le 28/02/2018 à 14:58, Michelle Wetterwald a écrit :
> Hi Alex,
>
> Answers inline.
>
> 2018-02-28 12:22 GMT+01:00 Alexandre PETRESCU 
> <[email-masked] <mailto:[email-masked]>>:
>
>         Regarding the interoperability between different
>         implementations, it has been fully validated during numerous
>         plugtests events in EU and US, gathering a large set of
>         different implementations. For the EU ones, the reports are
>         freely available on the ETSI web site.
>
>
>     I can tell they show lack of interoperability: several CAM
>     messages from several stacks are not understood by these wireshark
>     dissectors.
>
>

github.com 'rendits', 'vanetza', 'driveits', 'geonetworking', 'btpsap'.

None puts a QoSData header, each puts a 'Data' header.

(but none sends CAM as IP messages either).

>
>     The ETSI wireshark dissectors have another problem themselves:
>     they are not integrated in the main wireshark software.  It's just
>     ETSI's point of view.
>
>         I am sorry to hear that the open source implementation that
>         you are using has some limitations. I remember that one of the
>         participants to the last PlugTest in Livorno (Nov 2016)
>         explained to me he had extended the open source software to
>         use his computer to monitor the traffic exchanged on the
>         802.11p. So he made his Ath implementation fully interoperable
>         with those from the other vendors. Maybe you can apply similar
>         upgrades to your testing implementations?
>
>

The reference to the report please?

>
>         Again, I disagree with the change you propose in the text of
>         the draft, as it goes against the *existing* EU
>         regulations. Compliance with the modified text would
>         prevent vendors from accessing the EU market.
>
>
>     Accessing EU market is a good thing, but customer lock in may not
>     be that good.
>
>
> This is not customer lock-in, there are several and diverse 
> implementations available (BTW, this is more an L2 than an L3-IETF 
> related topic), the only thing is that you have to pay for getting 
> them, which is often part of the market rules, right?

There are software features in limited deployment that deserve a certain 
amount of money.
But key aspects like running IP are free of charge.

For example, it is worth attaching a price tag for software in a limited 
deployment (e.g. this highway), but IP is much wider scale. You cant put 
a price tag on it.

> Is there a requirement that an RFC can be approved only if several 
> open source implementations are available?

No, there is no such requirement.

But there is requirement for interoperability.  I can test for 
interoperability because I can use some open-source stacks.  For one, 
they are not interoperable among themselves when it comes to QoSData, 
but _are_ interoperable if they use Data.

>
> I am not sure what to think about that. What would be the usefulness 
> of a standard that prevents accessing part of the main markets?

There are key core standards and extensions.   One cant put IPR and 
request paid expensive licenses for key standards.

Extensions is another thing.

May I ask you: are the markets open to entry of newcomers, or is it 
locked by this and that manufacturer?

Alex

> If you believe that the standard is not relevant any more, then it 
> would be better to state it clearly and the WG can proceed on this basis.
>
> BR, Michelle
>
>

>                 The amendment IEEE 802.11e, which introduced the
>         concept of
>                 EDCA, was
>                 I would suggest to keep the old text and guarantee
>         openness for
>                 using
>                 At this time, with partners, we ponder the idea of a
>         different
>                 CAM if
>                 you wish (not sure whether UDP, or just IP, or 802.11
>         Data, or
>                 802.11
>                 QoS Data).  This different CAM is interoperable and
>         cheap to
>                 produce.
>
>         <mailto:[email-masked]>>>>>:
>
>                   it, and then there is need of consensus (could be
>         obvious from
>                 your
>                   standpoint).
>
>         <http://github.com>
>                 and I know the US uses AC_BE for some of their safety
>         messages
>                 as well.
>
>
>         <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>>>>:
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>>>
>         <https://www.ietf.org/mailman/listinfo/its>>>>>
>
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>
>
>
>
> -- 
> Michelle Wetterwald

---

From: William Whyte <[email-masked]>
Date: Wed, 28 Feb 2018 09:11:19 -0500

Hi Alex -- I'm with Michelle that this isn't the forum for that discussion,
but just to note, the CAM specification is in ASN.1. ASN.1 identifies the
information fields to be included in a data structure, and a given data
structure can then be encoded with one of a number of standardized encoding
rules. For CAM, the encoding rules are the Unaligned Packed Encoding Rules.
These are all well defined, and the encoding of CAM is unambiguous.

Cheers,

William

On Wed, Feb 28, 2018 at 8:59 AM, Michelle Wetterwald <[email-masked]

> 2018-02-28 13:07 GMT+01:00 Alexandre Petrescu <
> [email-masked]>:
>
>> Michelle,
>>

-- 

PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 15:14:10 +0100

> I rather encourage you to submit a contribution to that group.

Me and my organisation are no longer members of ETSI.  I dont think 
we'll become again, but exploring.

Alex

> 
> BR, Michelle
> 
> 2018-02-28 13:07 GMT+01:00 Alexandre Petrescu

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 15:21:31 +0100

Le 28/02/2018 à 15:11, William Whyte a écrit :
> Hi Alex -- I'm with Michelle that this isn't the forum for that 
> discussion, but just to note, the CAM specification is in ASN.1. ASN.1 
> identifies the information fields to be included in a data structure, 
> and a given data structure can then be encoded with one of a number of 
> standardized encoding rules. For CAM, the encoding rules are the 
> Unaligned Packed Encoding Rules. These are all well defined, and the 
> encoding of CAM is unambiguous.

I will not debug that here.  I posted my critique.

Alex

> 
> Cheers,
> 
> William
> 
> On Wed, Feb 28, 2018 at 8:59 AM, Michelle Wetterwald 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Alex,
> 
>     I am not representing ETSI and I am wondering whether this is the
>     right place to discuss about the content of ETSI standards.
> [email-masked] <mailto:[email-masked]>

---

From: Scott Cadzow <[email-masked]>
Date: Wed, 28 Feb 2018 14:23:51 +0000

Latest versions of the CAM specs have moved on apace. TS 102 894-2 is now at v1.2.10; EN 302 637-2 is at V1.3.2 now. As noted by William these use ASN.1 for data description and packed encoding rules so ought to be unambiguous. If there are issues, again as noted by Michelle, you ought to inform ETSI as indicated on the front material of the published standard.

Scott Cadzow

On 28/02/2018, 14:14, "its on behalf of Alexandre Petrescu" <[email-masked] on behalf of [email-masked]> wrote:

    TS 102 894-2

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 15:25:37 +0100

Le 28/02/2018 à 15:23, Scott Cadzow a écrit :
> Latest versions of the CAM specs have moved on apace. TS 102 894-2 is
> now at v1.2.10; EN 302 637-2 is at V1.3.2 now. As noted by William
> these use ASN.1 for data description and packed encoding rules so
> ought to be unambiguous. If there are issues, again as noted by
> Michelle, you ought to inform ETSI as indicated on the front material
> of the published standard.

... or agree with my partners to write our own CAM.

I dont understand why have to go through ETSI.

Alex

> 
> Scott Cadzow
> 
> 
> On 28/02/2018, 14:14, "its on behalf of Alexandre Petrescu"
> <[email-masked] on behalf of [email-masked]>
> wrote:
> 
> TS 102 894-2
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 12:21:11 +0100

> modified text would prevent vendors from accessing the EU market.

Accessing EU market is a good thing, but customer lock in is not that good.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 28 Feb 2018 17:39:10 +0100

Hi Alex,

I do not know how we could get drifted so far away from the RFC discussions and now discuss redoing CAMs.

But as a quick answer, to the best of my knowledge, you can't. ETSI has the mandate from the EC to 1) access the ITS-G5 spectrum 2) specify the C-ITS services (notably safety) for interoperability (cross-border, EU-wide, even enforcing interop with BSM, etc..)...

Even the C-V2X people, not the strongest supporters of ETSI C-ITS, are currently applying changes to ETSI and planning to use CAMs and DENMs...

BR,

Jérôme  

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday 28 February 2018 15:26
To: Scott Cadzow; Michelle Wetterwald
Cc: its
Subject: Re: [ipwave] Critique of CAM message format

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Feb 2018 18:51:54 +0100

Le 28/02/2018 à 17:39, Jérôme Härri a écrit :
> ETSI
> has the mandate from the EC to 1) access the ITS-G5 spectrum

I manage an RSU sending IPv6 RAs over 802.11OCB on CCH at 5.9GHz at
25dBm in OCB mode with IEEE 802.11 Data headers, on the street in front
of my desk. Wants EC me to stop it?

Alex

> 
> Even the C-V2X people, not the strongest supporters of ETSI C-ITS,
> are currently applying changes to ETSI and planning to use CAMs and
> DENMs...
> 
> BR,
> 
> Jérôme
> 
> Behalf Of Alexandre Petrescu Sent: Wednesday 28 February 2018 15:26 
> To: Scott Cadzow; Michelle Wetterwald Cc: its Subject: Re: [ipwave]
> Critique of CAM message format
> 
> 
> 
>> Latest versions of the CAM specs have moved on apace. TS 102 894-2
>> is now at v1.2.10; EN 302 637-2 is at V1.3.2 now. As noted by
>> William these use ASN.1 for data description and packed encoding
>> rules so ought to be unambiguous. If there are issues, again as
>> noted by Michelle, you ought to inform ETSI as indicated on the
>> front material of the published standard.
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Feb 2018 13:41:19 -0500

I cannot see how the discussion of Cooperative Awareness Message (CAM) is helping us complete the WG Last Call on the IPv6-over-802.11-OCB document.  Please focus on our deliverable.

Russ

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 1 Mar 2018 00:48:23 +0200

> - has not resolved known design choices. (Data vs QoSData)

we need to work on this, by using the ieee802.11ocb procedures/requirements

> I am not IESG so I dont know what to think about what IESG will request.

we should not worry about it.

> interoprable implementations before going to IESG.

My experience seen some standards with no open-implementations, I don't
think we should worry about this. I will change the word good in your
sentence to the word 'excellent', if available. Many companies close
implementations for different good purposes. Yes we need to make sure of
interoperability, but how can we know to test while the draft still does
not say what is the way to transmit voice packets or video packets. Let us
say first in the draft/proposal then test.

>>> source, and agreed somehow by some non-that-vendor implementers.
my understanding is usually implementations happen after standardization
specially when doing L2 or L1, it is better that all interested-industry
agree on standard then they implement. for above layers like L3-L7, we can
do both ways, but best way to implement then standardization.

For this draft we are doing IPv6 over L2 protocol, so it is different
situation, because both layers are implemented, so IMHO we have
implementations within companies but we need to recommend the standard for
best practices.

> You think we dont need two different implementations to interoperate

ieee802.11ocb protocol is already implemented/tested and it is
interoperable, but what is the problem, sorry maybe I did not follow the
discussion well,

AB