Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - implementations

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 15:20:05 +0100

Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :
[...]
> 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,

It is a QoS problem.  I think we can set it aside.  I will propose again 
separate text.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 15:32:41 +0100

I received some feedback from programmer.

> interoperable, but what is the problem, sorry maybe I did not follow the 

Here is the QoS problem for IP over 802.11 OCB in implementations.

In short, in open source on linux, we dont know how to send IP packets 
transported as 802.11 QoSData, all IP packets are transported as 802.11 
Data instead.

- if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get
   set properly in IP headers of Echorequest, but there is no .11 QoSData
   headers in packets.  Normally, one expects the QoSData headers to be
   present there when the DSCP (an IP field) is set.

- if you want to modify kernel, and force always to use QoSData headers
   on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file
   with a flag called wme_sta that you could set to true.  But take care
   that the C comments there say that it's not normal to use QoSData
   headers in OCB mode, because a terminal sending QoSData has no
   guarantee that receivers also use QoSData (the negotiation of QoS
   capabilities are absent in OCB).

As you can see, this can be long to try and fix.

Until then I will propose to set QoS aside from IP-over-OCB at this time.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 15:48:14 +0100

Hi,

I propose this new resolution: say "802.11 headers" instead of "Data 
Headers" and of "QoS Data Headers".  Which header to use is left outside 
the scope of this document.

OLD:
> At reception, this layer takes as input the IEEE 802.11 Data Header
> and the Logical-Link Layer Control Header and produces an Ethernet II
> Header.

NEW:
> At reception, this layer takes as input the IEEE 802.11 header and the
> Logical-Link Layer Control Header and produces an Ethernet II Header.

OLD:
> The Receiver and Transmitter Address fields in the 802.11 Data Header MUST
> contain the same values as the Destination and the Source Address
> fields in the Ethernet II Header, respectively.

NEW:
> The Receiver and Transmitter Address fields in the 802.11 header MUST
> contain the same values as the Destination and the Source Address
> fields in the Ethernet II Header, respectively.

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.
[...]
>    [I-D.ietf-tsvwg-ieee-802-11], although it is not specific to OCB
>    mode.

NEW:
> The specification of the 802.11 header used to transmit IP packets is
> outside the scope of this document.

I hope you dont disagree.

Alex

Le 28/02/2018 à 08:39, Alexandre Petrescu a écrit :
> John,
> 
> Thank you for the message.
> 
> 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.
>> 
>> Apologies if I don't have the IETF normative syntax right.
>> 
>> Note that UP = 1 maps to AC_BK.
>> 
>> Best Regards, John
>> 
>> 
>> On Tue, Feb 27, 2018 at 2:43 AM, Alexandre Petrescu 
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>> 
>> I propose the following modifications towards resolution of this
>> QoS issue.
>> 
>> Do you disagree?
>> 
>> 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).
>> 
>> Remove this entire OLD text:
>> 
>> 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.
>> 
>> +--------------------+-------------+-------------+---------+-----------+
>>
>>
>
>> 
| 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
>> 
>> 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.
>> 
>> 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.
>> 
>> 
>> Alex
>> 
>> 
>> Le 25/02/2018 à 18:58, Alexandre Petrescu a écrit :
>> 
>> 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
>> 
>> 
>> _______________________________________________ its mailing list 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/its 
>> <https://www.ietf.org/mailman/listinfo/its>
>> 
>> 
>> 
>> 
>> -- 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
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 16:47:47 +0100

In a private discussion, this question came up:

Is there a packet dump showing an IP packet transported with .11 QoSData 
headers in OCB mode at 5.9GHz.

(there are some packet dumps with IP packets transported with .11 Data 
headers in OCB mode at 5.9GHz, e.g. attached).

Alex

Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit :
>> interoperable, but what is the problem, sorry maybe I did not follow 
>> the discussion well,
> 
> [email-masked]

---

From: William Whyte <[email-masked]>
Date: Thu, 1 Mar 2018 10:50:21 -0500

My understanding is OCB mode requires QoSData, so those packets aren’t conformant to the standard.

Cheers,

William

Sent from Mail for Windows 10

From: Alexandre Petrescu
Sent: Thursday, March 1, 2018 10:48 AM
To: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 16:54:24 +0100

> conformant to the standard.

I propose we rename 'OCB' into 'IP-OCB' in the draft.

'IP-OCB' is an OCB mode that can be transport IP packets with .11 Data 
headers or with .11 QoS Data headers.

Alex

> 
> Cheers,
> 
> William
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
> 
> *From: *Alexandre Petrescu <mailto:[email-masked]>
> *Sent: *Thursday, March 1, 2018 10:48 AM
> *To: [email-masked] <mailto:[email-masked]>
> *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in 
> IPv6-over-802.11-OCB -implementations
> 
>  > _______________________________________________
> 
>  > its mailing list
> 
>  > [email-masked]
>

---

From: William Whyte <[email-masked]>
Date: Thu, 1 Mar 2018 10:59:49 -0500

> headers or with .11 QoS Data headers.

If it’s over OCB, then it needs to use QoSData. If you’re doing Data, you’re not conformant to OCB. There can’t be an OCB mode that transports packets with .11 Data, because OCB by definition uses QoSData. If the draft implies that you can do non-conformant OCB, that’s a serious defect in the draft.

Some implementations may not yet have implemented this, but that’s on those developers.

Cheers,

William

From: Alexandre Petrescu
Sent: Thursday, March 1, 2018 10:54 AM
To: William Whyte; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 17:05:14 +0100

William,

Le 01/03/2018 à 16:59, William Whyte a écrit :
> If it’s over OCB, then it needs to use QoSData. If you’re doing Data, 
> you’re not conformant to OCB. There can’t be an OCB mode that transports 
> packets with .11 Data, because OCB by definition uses QoSData. If the 
> draft implies that you can do non-conformant OCB, that’s a serious 
> defect in the draft.
> 

For one second, allow me the benefit of the doubt about specifications 
that may not be implemented.

I would like to know whether there is an implementation of IP over OCB 
with QoSData headers?  Packet dump is sufficient, or any other kind of 
statement.

I agree with you that many times it is good to write specification first 
and implementation after.

Alex

> *Sent: *Thursday, March 1, 2018 10:54 AM
> *To: *William Whyte <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> IPv6-over-802.11-OCB-implementations
> 
>  >  >> (there are some packet dumps with IP packets transported with .11 
> Data
> 
>  >
> 
>  > My understanding is OCB mode requires QoSData, so those packets aren’t
> 
>  > conformant to the standard.
> 
>  >  > I received some feedback from programmer.
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :
> 
>  >
> 
>  >  > [...]
> 
>  >
> 
>  >  >> 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,
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > Here is the QoS problem for IP over 802.11 OCB in implementations.
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > In short, in open source on linux, we dont know how to send IP packets
> 
>  >
> 
>  >  > transported as 802.11 QoSData, all IP packets are transported as 
> 802.11
> 
>  >
> 
>  >  > Data instead.
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get
> 
>  >
> 
>  >  >    set properly in IP headers of Echorequest, but there is no .11 
> QoSData
> 
>  >
> 
>  >  >    headers in packets.  Normally, one expects the QoSData headers 
> to be
> 
>  >
> 
>  >  >    present there when the DSCP (an IP field) is set.
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > - if you want to modify kernel, and force always to use QoSData 
> headers
> 
>  >
> 
>  >  >    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c file
> 
>  >
> 
>  >  >    with a flag called wme_sta that you could set to true.  But 
> take care
> 
>  >
> 
>  >  >    that the C comments there say that it's not normal to use QoSData
> 
>  >
> 
>  >  >    headers in OCB mode, because a terminal sending QoSData has no
> 
>  >
> 
>  >  >    guarantee that receivers also use QoSData (the negotiation of QoS
> 
>  >
> 
>  >  >    capabilities are absent in OCB).
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > As you can see, this can be long to try and fix.
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > Until then I will propose to set QoS aside from IP-over-OCB at 
> this time.
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > Alex
> 
>  >
> 
>  >  >
> 
>  >
> 
>  >  > _______________________________________________
> 
>  >
> 
>  >  > its mailing list
> 
>  >
> 
>  >  > [email-masked]
> 
>  >
> 
>  >  > https://www.ietf.org/mailman/listinfo/its
> 
>  >
>

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Thu, 1 Mar 2018 16:26:24 +0000

William,

(inline)

From: its [mailto:[email-masked]] On Behalf Of William Whyte
Sent: donderdag 1 maart 2018 16:50
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

Not true, per 802.11-2016, clause 11.21 .

Thanks,
Ronald

Cheers,

William

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Alexandre Petrescu<mailto:[email-masked]>
Sent: Thursday, March 1, 2018 10:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

Alex

Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit :
> [email-masked]<mailto:[email-masked]>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Dorothy Stanley <[email-masked]>
Date: Thu, 1 Mar 2018 08:28:20 -0800

Data frames are allowed, see IEEE Std 802.11-2016, clause 11.21, list item
c:

When dot11OCBActivated is true in a STA:
<snip>
The STA may send Data frames of subtype Data, Null, QoS Data, and QoS Null
<snip>

----------------------
Dorothy Stanley
Hewlett Packard Enterprise
[email-masked] <[email-masked]>
[email-masked]
<[email-masked]>+1 630-363-1389 <630-363-1389>

On Thu, Mar 1, 2018 at 7:50 AM, William Whyte <[email-masked]>
wrote:

> *From: *Alexandre Petrescu <[email-masked]>
> *To: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 17:28:38 +0100

Le 01/03/2018 à 17:22, Dick Roy a écrit :
> Actually I believe the QoSData restriction is in J2945/1 having only to 
> do with operation in the US in 5.9GHz.  Data and QoSData are permitted 
> according to 802.11 (and 1609.x).  This is not to say I believe this 
> discussion is relevant to the task of the ITS group, but … :^)))

Dick, it is very relevant.

The current text in the IP-over-OCB draft says that "OCB mode requires 
transmission of QoS data frames".  I cant remember why we wrote it so.
Do you think we should modify this text?

OLD:
>    802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB
>    attribute dot11OCBActivited is true.  The OCB mode requires
>    transmission of QoS data frames (IEEE Std 802.11e), half-clocked
>    operation (IEEE Std 802.11j), and use of 5.9 GHz frequency band.
>    Nota: any implementation should comply with standards and regulations
>    set in the different countries for using that frequency band.

Alex

> 
> Cheers,
> 
> RR
> 
> ------------------------------------------------------------------------
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *William Whyte
> *Sent:* Thursday, March 1, 2018 7:50 AM
> *To:* Alexandre Petrescu; [email-masked]
> *Subject:* Re: [ipwave] 802.11 Data vs 802.11 QoS Data in

---

From: William Whyte <[email-masked]>
Date: Thu, 1 Mar 2018 11:29:01 -0500

If that's the case, I don't have an issue with the draft allowing Data and
QoSData, though I'd note that the definition of OCB in the Terminology
section of the draft states that QoSData is required and should be changed
if it's wrong.

On the question of implementations: I don't have pcaps to hand, but the
USDOT RSU spec, available from
https://transportationops.org/publications/dedicated-short-range-communications-roadside-unit-specifications,
requires QoSData, and OmniAir has been testing conformance to that spec, so
it's safe to assume that it's been implemented.

Cheers,

William

On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy <[email-masked]> wrote:

> Actually I believe the QoSData restriction is in J2945/1 having only to do
> with operation in the US in 5.9GHz.  Data and QoSData are permitted
> ------------------------------
>
> *From:* its [mailto:[email-masked]] *On Behalf Of *William Whyte

-- 

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 17:32:13 +0100

William,

Le 01/03/2018 à 17:29, William Whyte a écrit :
> If that's the case, I don't have an issue with the draft allowing Data 
> and QoSData, though I'd note that the definition of OCB in the 
> Terminology section of the draft states that QoSData is required and 
> should be changed if it's wrong.

I agree.

> requires QoSData, and OmniAir has been testing conformance to that spec, 
> so it's safe to assume that it's been implemented.

Thanks for the pointer.

I hope their RSU uses IPv6 on the air (not on the Ethernet plug).  Can 
this be confirmed.

Alex

> 
> Cheers,
> 
> William
> 
> On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     __ __
> 
>     Actually I believe the QoSData restriction is in J2945/1 having only
>     to do with operation in the ____US____ in 5.9GHz.  Data and QoSData
>     are permitted according to 802.11 (and 1609.x).  This is not to say
>     I believe this discussion is relevant to the task of the ITS group,
>     but … :^)))____
> 
>     __ __
> 
>     Cheers,____
> 
>     __ __
> 
>     RR____
> 
>     *From:*its [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *William Whyte
>     *To:* Alexandre Petrescu; [email-masked] <mailto:[email-masked]>
> 
> 
>     ____
>     __ __
>     >>  (there are some packet dumps with IP packets transported with .11
>     Data ____
> 
>     headers in OCB mode at 5.9GHz, e.g. attached).____
> 
>     __ __
> 
>     My understanding is OCB mode requires QoSData, so those packets
>     aren’t conformant to the standard.____
> 
>     __ __
> 
>     Cheers,____
> 
>     __ __
> 
>     William____
> 
>     __ __
> 
>     Windows 10____
>     __ __
>     IPv6-over-802.11-OCB -implementations____
> 
>     __ __
> 
>     In a private discussion, this question came up:____
> 
>     __ __
> 
>     Is there a packet dump showing an IP packet transported with .11
>     QoSData ____
> 
>     headers in OCB mode at 5.9GHz.____
> 
>     __ __
> 
>     (there are some packet dumps with IP packets transported with .11
>     Data ____
> 
>     headers in OCB mode at 5.9GHz, e.g. attached).____
> 
>     __ __
> 
>     Alex____
> 
>     __ __
> 
>     Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit :____
> 
>     >  I received some feedback from programmer.____
> 
>     >  ____
> 
>     >  Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :____
> 
>     >  [...]____
> 
>     >>  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,____
> 
>     >  ____
> 
>     >  Here is the QoS problem for IP over 802.11 OCB in implementations.____
> 
>     >  ____
> 
>     >  In short, in open source on linux, we dont know how to send IP
>     packets ____
> 
>     >  transported as 802.11 QoSData, all IP packets are transported as
>     802.11 ____
> 
>     >  Data instead.____
> 
>     >  ____
> 
>     >  - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get____
> 
>     >    set properly in IP headers of Echorequest, but there is no .11
>     QoSData____
> 
>     >    headers in packets.  Normally, one expects the QoSData headers to
>     be____
> 
>     >    present there when the DSCP (an IP field) is set.____
> 
>     >  ____
> 
>     >  - if you want to modify kernel, and force always to use QoSData
>     headers____
> 
>     >    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c
>     file____
> 
>     >    with a flag called wme_sta that you could set to true.  But take
>     care____
> 
>     >    that the C comments there say that it's not normal to use QoSData____
> 
>     >    headers in OCB mode, because a terminal sending QoSData has no____
> 
>     >    guarantee that receivers also use QoSData (the negotiation of QoS____
> 
>     >    capabilities are absent in OCB).____
> 
>     >  ____
> 
>     >  As you can see, this can be long to try and fix.____
> 
>     >  ____
> 
>     >  Until then I will propose to set QoS aside from IP-over-OCB at
>     this time.____
> 
>     >  ____
> 
>     >  Alex____
> 
>     >  ____
> 
>     >  ___________________________________________________
> 
>     >  its mailing list____
> 
>     >  [email-masked] <mailto:[email-masked]>____
> 
>     <https://www.ietf.org/mailman/listinfo/its>____
> 
>     __ __
> 
> 
> 
> 
> -- 
> 
> 
> [email-masked] <mailto:[email-masked]>

---

From: William Whyte <[email-masked]>
Date: Thu, 1 Mar 2018 11:38:00 -0500

Hi Alex,

> I hope their RSU uses IPv6 on the air (not on the Ethernet plug).  Can 

Section 2.2 of the RSU spec says:

IPv6 Access
The RSU provides DSRC-equipped mobile devices with access to Back Office services by way of IPv6.

… and (as you’d expect) there are references to providing IPv6 service throughout the document.

Cheers,

William

From: Alexandre Petrescu
Sent: Thursday, March 1, 2018 11:32 AM
To: William Whyte; Dick Roy
Cc: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB-implementations

William,

I agree.

Thanks for the pointer.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 17:39:58 +0100

In the Terminology section, I propose this resolution.

OLD:
> Nota: any implementation should comply with standards and
> regulations set in the different countries for using that frequency
> band.
NEW:
> attribute dot11OCBActivited is true.  The OCB mode permits the
> transmission of 802.11 Data frames, of 802.11 QoS Data frames (IEEE
> Std 802.11e), half-clocked operation (IEEE Std 802.11j), and use of
> 5.9 GHz frequency band.  Nota: any implementation should comply with
> standards and regulations set in the different countries for using
> that frequency band.

I hope you dont disagree with this proposal.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 17:45:57 +0100

Le 01/03/2018 à 17:38, William Whyte a écrit :
> /IPv6 Access///

It's very good to know.

The IPv6-over-OCB document allows the use of IPv6 over the air interface 
of an RSU (even though it calls it an IP-RSU instead :-)

Let us hope for the best for the FHWA&ITS "Dedicated Short-Range 
Communications Roadside Unit Specifications".

Alex

> *Sent: *Thursday, March 1, 2018 11:32 AM
> *To: *William Whyte <mailto:[email-masked]>; Dick Roy 
> <mailto:[email-masked]>
> *Cc: [email-masked] <mailto:[email-masked]>
>  >     >  I received some feedback from programmer.____
> 
>  >
> 
>  >     >  ____
> 
>  >
> 
>  >     >  Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :____
> 
>  >
> 
>  >     >  [...]____
> 
>  >
> 
>  >     >>  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,____
> 
>  >
> 
>  >     >  ____
> 
>  >
> 
>  >     >  Here is the QoS problem for IP over 802.11 OCB in 
> implementations.____
> 
>  >
> 
>  >     >  ____
> 
>  >
> 
>  >     >  In short, in open source on linux, we dont know how to send IP
> 
>  >     packets ____
> 
>  >
> 
>  >     >  Data instead.____
>  >     >  ____
>  >     >  - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields do get____
> 
>  >
> 
>  >     >    headers in packets.  Normally, one expects the QoSData 
> headers to
> 
>  >     be____
> 
>  >
> 
>  >     >    present there when the DSCP (an IP field) is set.____
> 
>  >
> 
>  >     >  ____
> 
>  >
> 
>  >     >    on WiFi, including OCB at 5.9GHz, there is a net/mac80211/tx.c
> 
>  >     file____
> 
>  >
> 
>  >     >    with a flag called wme_sta that you could set to true.  But take
> 
>  >     care____
> 
>  >
> 
>  >     >    that the C comments there say that it's not normal to use 
> QoSData____
> 
>  >
> 
>  >     >    headers in OCB mode, because a terminal sending QoSData has 
> no____
> 
>  >
> 
>  >     >    guarantee that receivers also use QoSData (the negotiation 
> of QoS____
> 
>  >
> 
>  >     >    capabilities are absent in OCB).____
> 
>  >
> 
>  >     >  ____
> 
>  >
> 
>  >     >  As you can see, this can be long to try and fix.____
> 
>  >
> 
>  >     >  ____
> 
>  >
> 
>  >     >  ____
>  >     >  Alex____
>  >     >  ____
>  >     >  ___________________________________________________
> 
>  >
> 
>  >     >  its mailing list____
> 
>  >
> 
>  >     >  [email-masked] <mailto:[email-masked]>____
> 
>  >
>

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 1 Mar 2018 18:05:42 +0100

Dear All,

With the risk of repeating information already sent in the thread, the issue has never been if Data or QoSData is allowed for OCB. It is clear it is. 

BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media dependent functionalities, both specify to use QoSData to differentiate event-based BSM (very urgent) from periodic BMS (normal) / DENM (very urgent) from CAM (normal) using QoSData with AC_VI (DENM/event-based BSM) and AC_BE (CAM/periodic BSM), we have a ‘coexistence issue’ .

Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot + SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 slot + SIFS. And CAM/periodic BSM use *6* slot + SIFS.

In short, any IP-over-OCB will access the channel before CAM/BSM at best and generate collisions with ITS-G5 and DSRC. This can be seem as ‘harmful’ interferences with an existing system, which must be avoided. 

That is the reason I am suggesting to use QoSData for IP-over-OCB, so that depending on your traffic (e.g. if you transmit CAM-over-IP, or video feeds) you can tweak the right AC_ and not interfere with DSRC/ITS-G5..much. That would avoid a lot of issues…and it does not cost much (ok some extra bits, but come on…we are not doing ROLL here, so is it that dramatic? 

Even though not the task of IETF, it is important to make sure that any specification will not interfere with an existing system. So, Alex’s suggestion to remove any explicit mention to QoSData or Data is probably a good trade-off, and leave it open to profiling as function of in which channel IP-over-OCB would be used (i.e if interference is expected or not)…

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of William Whyte
Sent: Thursday 01 March 2018 17:29
To: Dick Roy
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

If that's the case, I don't have an issue with the draft allowing Data and QoSData, though I'd note that the definition of OCB in the Terminology section of the draft states that QoSData is required and should be changed if it's wrong.

On the question of implementations: I don't have pcaps to hand, but the USDOT RSU spec, available from https://transportationops.org/publications/dedicated-short-range-communications-roadside-unit-specifications, requires QoSData, and OmniAir has been testing conformance to that spec, so it's safe to assume that it's been implemented.

Cheers,

William

Actually I believe the QoSData restriction is in J2945/1 having only to do with operation in the US in 5.9GHz.  Data and QoSData are permitted according to 802.11 (and 1609.x).  This is not to say I believe this discussion is relevant to the task of the ITS group, but … :^)))

Cheers,

RR

  _____  

From: its [mailto:[email-masked]] On Behalf Of William Whyte
Sent: Thursday, March 1, 2018 7:50 AM
To: Alexandre Petrescu; [email-masked]

Cheers,

William

Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>  for Windows 10

From: Alexandre Petrescu <mailto:[email-masked]> 
Sent: Thursday, March 1, 2018 10:48 AM
To: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

Alex

 

-- 

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

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 1 Mar 2018 18:08:36 +0100

Agreed..indeed, that was wrong :-)

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday 01 March 2018 17:40
To: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal

Alex

Le 01/03/2018 à 15:48, Alexandre Petrescu a écrit :
> Headers" and of "QoS Data Headers".  Which header to use is left 
>> At reception, this layer takes as input the IEEE 802.11 header and 
>> the Logical-Link Layer Control Header and produces an Ethernet II Header.
> 
> OLD:
>> The Receiver and Transmitter Address fields in the 802.11 Data Header 
>> MUST contain the same values as the Destination and the Source 
>> Address fields in the Ethernet II Header, respectively.
> 
> NEW:
>> in
>> 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").
>>
>>>> 802.11 QoS Data" frame. In the QoS Control Field, the TID subfield 
>>>> (Bits
>>> <[email-masked] <mailto:[email-masked]>> 
>>> wrote:
>>>
>>> I propose the following modifications towards resolution of this QoS 
>>> issue.
>>>
>>> Do you disagree?
>>>
>>> OLD:
>>> 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.
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 18:16:30 +0100

Jérôme,
Thank you for the explanation.

Le 01/03/2018 à 18:05, Jérôme Härri a écrit :
[...]
> That is the reason I am suggesting to use QoSData for IP-over-OCB, so 
> that depending on your traffic (e.g. if you transmit CAM-over-IP, or 
> video feeds) you can tweak the right AC_ and not interfere with 
> DSRC/ITS-G5..much. That would avoid a lot of issues…and it does not cost 
> much (ok some extra bits, but come on…we are not doing ROLL here, so is 
> it that dramatic?

I agree with you.

Can one maybe write a separate draft for this.  I think implementation 
can be written.

I think the existing draft IP-over-OCB with the recent tweaks allows for 
such a draft.

I may ask you: what do you think could be a title of QoSData IP/OCB be?

Alex

> 
> Even though not the task of IETF, it is important to make sure that any 
> specification will not interfere with an existing system. So, Alex’s 
> suggestion to remove any explicit mention to QoSData or Data is probably 
> a good trade-off, and leave it open to profiling as function of in which 
> channel IP-over-OCB would be used (i.e if interference is expected or not)…
> 
> BR,
> 
> Jérôme
> 
> *Sent:* Thursday 01 March 2018 17:29
> *To:* Dick Roy
> *Cc:* Alexandre Petrescu; [email-masked]
> *From:*its [mailto:[email-masked] <mailto:[email-masked]>] 
> *On Behalf Of *William Whyte

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Mar 2018 19:00:20 +0100

Then how about this suggestion.

NEW:
> attribute dot11OCBActivited is true.
Alex

Le 01/03/2018 à 18:33, Dick Roy a écrit :
> Not quite right yet ... :^(((((  OCB-mode does not "permit use of 
> 5.9GHz”, OCB mode is “required” in the 5.9GHz band in the US and
> Europe according to 802.11.  Secondly, if you’re going to list the
> frames allowed, list them all.  Otherwise don’t list any.
> 
> RR
> 
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Jérôme Härri Sent: Thursday, March 1, 2018 9:09 AM To:
> 'Alexandre Petrescu'; [email-masked] Subject: Re: [ipwave] 802.11 Data
> vs 802.11 QoS Data in IPv6-over-802.11-OCB - new text proposal
> 
>> regulations
>>> illustrated
>>> would
>>>>> subfield
>>>> <mailto:[email-masked]>>
> 
>>>> wrote:
> 
>>>> 
> 
>>>>> Control
>>>> Control

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 09:59:34 +0100

Dick,

My understanding is in explanation further below. I hope I have it
right, but I never know.

Essentially, I would like to ask you: do you agree that IPv6 currently
runs on top of EthernetII (aka DIX) and not directly on top of 802.11?
(even when IPv6 packets are sent on 802.11 interfaces).

Alex

Le 01/03/2018 à 19:24, Dick Roy a écrit :
[...]
> */[RR] What “layer”? This makes little to no sense.

The 'layer' is the 802.11-to-Ethernet Adaptation Layer, in the title of
the section.

As far as I can tell IPv6 does not run directly over 802.11 layer, but 
over the Ethernet layer.  So it needs an adaptation layer.

> Why would any “layer” take as input DLL headers (MAC and LLC sublayer
> headers) and “produce” another MAC (and LLC) header???

An adaptation layer helps the IP stack adapt to various link layers, 
like 802.11 or 802.15.4.  The IP stack stays the same: always constructs
EthernetII headers.  And an adaptation layer converts that to 802.11 or
802.15.4 or oher.

In linux, the copy operations of this layer are in net/mac80211/tx.c
ether_addr_copy(amsdu_hdr->h_source, h_80211_src).  The  'amsdu' is DIX.

This adaptation layer, one day maybe, may set that AC_BK field for
IP-over-OCB-with-QoSData by copying it from the IP header.

The 802.11-to-Ethernet Adaptation Layer outputs a MAC header, but not an 
LLC header, even though in input there is an LLC header in 802.11.

> That’s the function of a bridge!

In principle yes, but it depends what you call a bridge.

In software, a bridge tool like brctl can do the function of a bridge.
The adaptation layer is not brctl.

> Why are you even mentioning Ethernet II headers in a draft concerned 
> with IEEE 802.11 MACs & PHYs!/*

Because there is no draft concerned with IP over 802.11 per se, and in
this draft we are concerned only with the OCB part of 802.11.

If you want, maybe someone can develop an IP stack that is specific to
802.11, and eliminate this adaptation layer that seems superfluos.  That
could be put in an IP-over-802.11 document.

But I am afraid there is too much software to write.

> */[RR] This seems wrong.  Where in the heck did the Ethernet II 
> header come from in the first place??

One can see the EthernetII headers in wireshark packet dumps in normal 
mode (not in monitor mode).

> Where is 802.3 in a document dealing with IPv6 and 802.11???

I agree with this questioning.

My answer is this: we need to write IPv6 over the OCB part of 802.11.
But there is no IPv6 over 802.11 in first place.  What there is is
IPv6-over-Ethernet.

> More importantly, I would also not make any specification of this 
> sort in the document.

I can try another rephrasing.

> The four address format of 802.11 may prove very useful in the
> future,

I agree.

For that you would need an IPv6-over-802.11 document, and the software.

> especially when the group does its job of simply defining new
> IPv6 functionality for rapidly varying wireless networks.  Then all
> mention of OCB mode simply dies away, as well it should! Immediately!
> And then all the good work performed can be used with any and all
> Wi-Fi (802.11) LANs and others! Which is a real good thing, because
> the probability that 5.9GHz OCB operations are actually going to be
> deployed in the forseeable future is declining to zero at a rate that
> will make your heads spin. /*

Noted.

[...]

> */[RR] Nice! And the right idea!  However it is in direct conflict 
> with the change you suggest above. Leave this statement in, and 
> REMOVE all the rest!/*

I keep that paragraph.

But the EthernetII header is always there, even when IP appears to run 
on 802.11.  I dont know how you want me to not talk about EthernetII, 
aka DIX.

Alex

[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 10:21:27 +0100

Dick,

One more thing.

I am trying to remove all text about this WiFi-to-Ethernet Adaptation 
Layer.  And what I am left with is IPv6-over-Ethernet:

>    IP packets are transmitted over 802.11-OCB as standard Ethernet
>    packets.

Do you think I can just leave it at that?

Alex

Le 01/03/2018 à 19:24, Dick Roy a écrit :
> Sent: Thursday, March 1, 2018 6:48 AM
> To: [email-masked]
> */[RR] What “layer”? This makes little to no sense. Why would any 
> “layer” take as input DLL headers (MAC and LLC sublayer headers) and 
> “produce” another MAC (and LLC) header???  That’s the function of a 
> bridge! Why are you even mentioning Ethernet II headers in a draft 
> concerned with IEEE 802.11 MACs & PHYs!/*
> 
> OLD:
> 
> */[RR] This seems wrong.  Where in the heck did the Ethernet II header 
> come from in the first place?? Where is 802.3 in a document dealing with 
> IPv6 and 802.11???  More importantly, I would also not make any 
> specification of this sort in the document.  The four address format of 
> 802.11 may prove very useful in the future, especially when the group 
> does its job of simply defining new IPv6 functionality for rapidly 
> varying wireless networks.  Then all mention of OCB mode simply dies 
> away, as well it should!  Immediately! And then all the good work 
> performed can be used with any and all Wi-Fi (802.11) LANs and others! 
> Which is a real good thing, because the probability that 5.9GHz OCB 
> operations are actually going to be deployed in the forseeable future is 
> declining to zero at a rate that will make your heads spin. /*
> 
> OLD:
> 
> */[RR] Nice! And the right idea!  However it is in direct conflict with 
> the change you suggest above. Leave this statement in, and REMOVE all 
> the rest!/*
> 
> *//*
> 
> */Cheers,/*
> 
> */
> RR/*
>

---

From: Michelle Wetterwald <[email-masked]>
Date: Fri, 2 Mar 2018 10:31:24 +0100

Hi Alex,

May I make a suggestion for that?

OLD:
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute
dot11OCBActivited is true.  The OCB mode requires transmission of QoS data
frames (IEEE Std 802.11e), half-clocked operation (IEEE Std 802.11j), and
use of 5.9 GHz frequency band. Nota: any implementation should comply with
standards and regulations set in the different countries for using that
frequency band.

NEW:
802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute
dot11OCBActivited is true. Nota: any implementation should comply with
standards and regulations set in the different countries when using the 5.9
GHz frequency band.

Best regards,
Michelle

2018-03-01 19:00 GMT+01:00 Alexandre Petrescu <[email-masked]>
:

>> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute
>> dot11OCBActivited is true.  The OCB mode requires transmission of QoS data
>> frames (IEEE Std 802.11e), half-clocked operation (IEEE Std 802.11j), and
>> use of 5.9 GHz frequency band. Nota: any implementation should comply with
>> standards and regulations
>> 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the MIB attribute
>> dot11OCBActivited is true.
>>
> Alex
>
>
>

-- 
Michelle Wetterwald
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 10:31:57 +0100

> the change you suggest above. Leave this statement in, and REMOVE all 

I will say "The specification of _which_ type or subtype of 802.11 
headers are used to transmit IP packets is left outside the scope of 
this document".

In this way, it does not conflict with previous text.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 10:32:46 +0100

Le 02/03/2018 à 10:31, Michelle Wetterwald a écrit :
> attribute dot11OCBActivited is true.  The OCB mode requires transmission 
> of QoS data frames (IEEE Std 802.11e), half-clocked operation (IEEE Std 
> 802.11j), and use of 5.9 GHz frequency band. Nota: any implementation 
> should comply with standards and regulations set in the different 
> countries for using that frequency band.
> 
> NEW:
> attribute dot11OCBActivited is true. Nota: any implementation should 
> comply with standards and regulations set in the different 
> countries when using the 5.9 GHz frequency band.

I have been asked whether 'Nota' is in language Italian?

Alex

> 
> Best regards,
> Michelle
> 
> 2018-03-01 19:00 GMT+01:00 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>:
> 
>         Not quite right yet ... :^(((((  OCB-mode does not "permit use
>         of 5.9GHz”, OCB mode is “required” in the 5.9GHz band in the US and
>         -----Original Message----- From: its
>         [mailto:[email-masked] <mailto:[email-masked]>] On
>         'Alexandre Petrescu'; [email-masked] <mailto:[email-masked]>
>         Subject: Re: [ipwave] 802.11 Data
> 
>         From: its [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Alexandre
>         Petrescu
> 
>         To: [email-masked] <mailto:[email-masked]>
> 
>                 At reception, this layer takes as input the IEEE 802.11
>                 header
>                 and
> 
> 
>                 the Logical-Link Layer Control Header and produces an
>                 Ethernet
>                 II Header.
> 
> 
> 
> 
>             OLD:
> 
> 
>                 The Receiver and Transmitter Address fields in the
>                 802.11 Data
>                 Header
> 
> 
>                 The Receiver and Transmitter Address fields in the
>                 802.11  header
>                 MUST
> 
> 
>                 [I-D.ietf-tsvwg-ieee-802-11], although it is not
>                 specific  to
>                 OCB
> 
> 
>                 mode.
> 
> 
> 
> 
>             NEW:
> 
> 
>                 not hesitate to write that text as you suggest ("MUST
>                 QoS  Data,
>                 Qos
> 
> 
>                 another document. Maybe Carlos questioning of this EAL
>                 was  right
>                 in
> 
> 
>                 the end.
> 
> 
> 
> 
>                 Alex
> 
> 
> 
> 
>                     0-3) MUST be set equal to binary 0001, corresponding
>                     to UP  =
>                     1.
> 
> 
> 
> 
>                     <mailto:[email-masked]>
>                     <mailto:[email-masked]
>                     <mailto:[email-masked]>>>
> 
> 
>                     wrote:
> 
> 
> 
> 
>                     I propose the following modifications towards
>                     resolution  of
>                     this QoS
> 
> 
>                     issue.
> 
> 
> 
> 
>                     Do you disagree?
> 
> 
> 
> 
>                     OLD:
> 
> 
>                         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
> 
> 
>                     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
> 
> 
>                     The mapping between qos-related fields in the IPv6
>                     header
>                     (e.g.
> 
> 
>                     "Traffic Class", "Flow label") and  fields in the
>                     "802.11 QoS
>                     Data
> 
> 
>                     [I-D.ietf-tsvwg-ieee-802-11], although it is not
>                     specific  to
>                     OCB
> 
> 
>                     mode.
> 
> 
> 
> 
> 
> 
>                     Alex
> 
> 
> 
> 
> 
> 
>                     In OCB mode, it is RECOMMENDED to transmit IPv6
>                     packets as
>                     "IEEE
> 
> 
>                     _______________________________________________ its 
>                     mailing
>                     list
> 
> 
>                     <mailto:[email-masked] <mailto:[email-masked]>>
> 
> 
>                     <https://www.ietf.org/mailman/listinfo/its
>                     <https://www.ietf.org/mailman/listinfo/its>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                     InfoTechnology Center, USA 465 Bernardo Avenue
>                     Mountain View,
>                     CA
> 
> 
>                     94043 Tel: 650-694-4160 <tel:650-694-4160>. Mobile:
>                     650-224-6644 <tel:650-224-6644>
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 10:44:12 +0100

I propose this:

NEW:
> attribute dot11OCBActivited is true.  Note: compliance with
> standards and regulations set in different countries when using the
> 5.9GHz frequency band is required.

Alex

Le 02/03/2018 à 10:32, Alexandre Petrescu a écrit :
>> OLD: 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the
>> MIB attribute dot11OCBActivited is true.  The OCB mode requires 
>> NEW: 802.11-OCB: mode specified in IEEE Std 802.11-2016 when the
>> MIB attribute dot11OCBActivited is true. Nota: any implementation
>> Best regards, Michelle
>> <mailto:[email-masked]>>:
>> 
>> -----Original Message----- From: its [mailto:[email-masked]
>> <mailto:[email-masked]>] On Behalf Of Jérôme Härri Sent:
>> Thursday, March 1, 2018 9:09 AM To: 'Alexandre Petrescu';
>> [email-masked] <mailto:[email-masked]> Subject: Re: [ipwave] 802.11
>> Data
>> 
>> <mailto:[email-masked]>] On Behalf Of Alexandre Petrescu
>> 
>> QoS
>> packets as "IEEE
| 802.11 Data Header | LLC Header  | IPv6 Header | Payload
>> |.11
or
| 802.11 QoS Data Hdr| LLC Header  | IPv6 Header | Payload
>> |.11
>> the
>> mailing list
>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked]>>
>> 
>> 
>> 94043 Tel: 650-694-4160 <tel:650-694-4160>. Mobile: 650-224-6644
>> <tel:650-224-6644>
>> 
>> 
>> 
>> 
>> -- Michelle Wetterwald [email-masked]
>> <mailto:[email-masked]>
>

---

From: William Whyte <[email-masked]>
Date: Fri, 2 Mar 2018 11:16:04 -0500

I've confirmed that the US implementations use QoSData, just to close that
loop.

Cheers,

William

On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu <
[email-masked]> wrote:

>> packets with .11 Data, because OCB by definition uses QoSData. If the draft
>> implies that you can do non-conformant OCB, that’s a serious defect in the
>> draft.
>>
>> follow
>> packets
>> file
>> care

--

---

From: Tony Li <[email-masked]>
Date: Fri, 2 Mar 2018 08:15:43 -0800

> I am trying to remove all text about this WiFi-to-Ethernet Adaptation Layer.  And what I am left with is IPv6-over-Ethernet:
> 

No, since that would be wildly inaccurate.  

We need to specify the appropriate headers to use. That is a fundamental requirement of this document. This part must be normative. Based on the discussion so far, we MUST use QoS Data and we must be specific about that.

While I appreciate the efforts to evade difficulty by deferring to other documents, that’s not going to work in this case.

Explaining how the adaptation layer simplifies kernel programming may be part of the document, but since it doesn’t actually appear on the wire, this part should be informational.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 17:28:03 +0100

Le 02/03/2018 à 17:16, William Whyte a écrit :
> I've confirmed that the US implementations use QoSData, just to close 
> that loop.

Thanks.  It's QoSData with IP, right?

Alex

> 
> Cheers,
> 
> William
> 
> On Thu, Mar 1, 2018 at 11:05 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     William,
> 
>           > I propose we rename 'OCB' into 'IP-OCB' in the draft.
> 
>           > 'IP-OCB' is an OCB mode that can be transport IP packets
>         with .11 Data
> 
>           > headers or with .11 QoS Data headers.
> 
>         If it’s over OCB, then it needs to use QoSData. If you’re doing
>         Data, you’re not conformant to OCB. There can’t be an OCB mode
>         that transports packets with .11 Data, because OCB by definition
>         uses QoSData. If the draft implies that you can do
>         non-conformant OCB, that’s a serious defect in the draft.
> 
>     For one second, allow me the benefit of the doubt about
>     specifications that may not be implemented.
> 
>     I would like to know whether there is an implementation of IP over
>     OCB with QoSData headers?  Packet dump is sufficient, or any other
>     kind of statement.
> 
>     I agree with you that many times it is good to write specification
>     first and implementation after.
> 
>     Alex
> 
> 
>         Cheers,
> 
>         William
> 
>         Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986
>         <https://go.microsoft.com/fwlink/?LinkId=550986>> for Windows 10
> 
>         *From: *Alexandre Petrescu <mailto:[email-masked]
>         *To: *William Whyte <mailto:[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>           >  >> (there are some packet dumps with IP packets transported
>         with .11 Data
> 
>           >
> 
>           > headers in OCB mode at 5.9GHz, e.g. attached).
> 
>           >
> 
>           > My understanding is OCB mode requires QoSData, so those
>         packets aren’t
> 
>           > conformant to the standard.
> 
>           > Cheers,
>           > William
>           > Sent from Mail
>         <https://go.microsoft.com/fwlink/?LinkId=550986
>         <https://go.microsoft.com/fwlink/?LinkId=550986>> for
> 
>           > Windows 10
> 
>           >
> 
>           > *From: *Alexandre Petrescu
>           > *Sent: *Thursday, March 1, 2018 10:48 AM
> 
>           > *To: [email-masked] <mailto:[email-masked]>
>           > *Subject: *Re: [ipwave] 802.11 Data vs 802.11 QoS Data in
> 
>           > IPv6-over-802.11-OCB -implementations
> 
>           >
> 
>           > In a private discussion, this question came up:
> 
>           >
> 
>           > Is there a packet dump showing an IP packet transported with
>         .11 QoSData
> 
>           >
> 
>           > headers in OCB mode at 5.9GHz.
> 
>           >
> 
>           > (there are some packet dumps with IP packets transported
>         with .11 Data
> 
>           >
> 
>           > headers in OCB mode at 5.9GHz, e.g. attached).
> 
>           >
> 
>           > Alex
> 
>           >
> 
>           > Le 01/03/2018 à 15:32, Alexandre Petrescu a écrit :
> 
>           >
> 
>           >  > I received some feedback from programmer.
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > Le 28/02/2018 à 23:48, Abdussalam Baryun a écrit :
> 
>           >
> 
>           >  > [...]
> 
>           >
> 
>           >  >> 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,
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > Here is the QoS problem for IP over 802.11 OCB in
>         implementations.
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > In short, in open source on linux, we dont know how to
>         send IP packets
> 
>           >
> 
>           >  > transported as 802.11 QoSData, all IP packets are
>         transported as 802.11
> 
>           >
> 
>           >  > Data instead.
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > - if you ping -Q at 5.9GHz in OCB mode, the DSCP fields
>         do get
> 
>           >
> 
>           >  >    set properly in IP headers of Echorequest, but there
>         is no .11 QoSData
> 
>           >
> 
>           >  >    headers in packets.  Normally, one expects the QoSData
>         headers to be
> 
>           >
> 
>           >  >    present there when the DSCP (an IP field) is set.
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > - if you want to modify kernel, and force always to use
>         QoSData headers
> 
>           >
> 
>           >  >    on WiFi, including OCB at 5.9GHz, there is a
>         net/mac80211/tx.c file
> 
>           >
> 
>           >  >    with a flag called wme_sta that you could set to
>         true.  But take care
> 
>           >
> 
>           >  >    that the C comments there say that it's not normal to
>         use QoSData
> 
>           >
> 
>           >  >    headers in OCB mode, because a terminal sending
>         QoSData has no
> 
>           >
> 
>           >  >    guarantee that receivers also use QoSData (the
>         negotiation of QoS
> 
>           >
> 
>           >  >    capabilities are absent in OCB).
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > As you can see, this can be long to try and fix.
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > Until then I will propose to set QoS aside from
>         IP-over-OCB at this time.
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > Alex
> 
>           >
> 
>           >  >
> 
>           >
> 
>           >  > _______________________________________________
> 
>           >
> 
>           >  > its mailing list
> 
>           >
> 
>           >  > [email-masked] <mailto:[email-masked]>
> 
>           >
> 
>           >  > https://www.ietf.org/mailman/listinfo/its

---

From: William Whyte <[email-masked]>
Date: Fri, 2 Mar 2018 12:02:24 -0500

US implementations use QoSData with everything -- although it's not
required by 802.11-OCB, as we discussed earlier, it *is* required for a
"WAVE device", which all US devices are.

Here's a Wireshark image from a contact showing the QoSData field:

Cheers,

William

On Fri, Mar 2, 2018 at 11:28 AM, Alexandre Petrescu <
[email-masked]> wrote:

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     William,
>>
>>           > Sent from Mail

--

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 18:05:38 +0100

thank you very much for this.
In this figure we see a WSMP message transported with QoSData.  This is 
very good, because security is very important.

I will not push for this, and consider this close.  Just if in any case 
later there may be some opportunity to tell the operator of the 
wireshark to also ping, it would be wonderful.  For later.

Alex

Le 02/03/2018 à 18:02, William Whyte a écrit :
> Inline image 1
> On Fri, Mar 2, 2018 at 11:28 AM, Alexandre Petrescu 
>         I've confirmed that the US implementations use QoSData, just to
>         close that loop.
> 
> 
>         <mailto:[email-masked]>>> wrote:
> 
>              William,
> 
>         <https://go.microsoft.com/fwlink/?LinkId=550986>
>         <https://go.microsoft.com/fwlink/?LinkId=550986>>> for Windows 10
> 
>         <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>>; [email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>                  'IP-OCB' is an OCB mode that can be transport IP
>         packets with
>                  .11 Data
> 
>         <https://go.microsoft.com/fwlink/?LinkId=550986>
>         <https://go.microsoft.com/fwlink/?LinkId=550986>>> for
> 
>                    > Windows 10
> 
>                    >
> 
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
> 
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
> 
> 
> 
> 
> -- 
> 
>

---

From: François Simon <[email-masked]>
Date: Fri, 2 Mar 2018 12:06:08 -0500

Aggree.

From: its <[email-masked]> On Behalf Of Jérôme Härri
Sent: Thursday, March 01, 2018 12:06 PM
To: 'William Whyte' <[email-masked]>; 'Dick Roy' <[email-masked]>
Cc: 'Alexandre Petrescu' <[email-masked]>; [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

Dear All,

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of William Whyte
Sent: Thursday 01 March 2018 17:29
To: Dick Roy
Cc: Alexandre Petrescu; [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB -implementations

Cheers,

William

On Thu, Mar 1, 2018 at 11:22 AM, Dick Roy <[email-masked] <mailto:[email-masked]> > wrote:

Cheers,

RR

  _____  

From: its [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of William Whyte
Sent: Thursday, March 1, 2018 7:50 AM
To: Alexandre Petrescu; [email-masked] <mailto:[email-masked]> 

Cheers,

William

Alex

 

-- 

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Mar 2018 18:10:31 +0100

Is there a discussion slot to discuss this in London?

I would be interested to contribute to the discussion on QoS, but 
provided we agree it is about QoS with IP, not QoS without IP.

Alex

Le 02/03/2018 à 18:06, François Simon a écrit :
> Aggree.
> 
> *From:*its <[email-masked]> *On Behalf Of *Jérôme Härri
> *Sent:* Thursday, March 01, 2018 12:06 PM
> *To:* 'William Whyte' <[email-masked]>; 'Dick Roy' 
> <[email-masked]>
> *Cc:* 'Alexandre Petrescu' <[email-masked]>; [email-masked]
> With the risk of repeating information already sent in the thread, the 
> issue has never been if Data or QoSData is allowed for OCB. It is clear 
> it is.
> 
> BUT considering that SAE 2945/1 (BSM) and ETSI geonet-media dependent 
> functionalities, both specify to use QoSData to differentiate 
> event-based BSM (very urgent) from periodic BMS (normal) / DENM (very 
> urgent) from CAM (normal) using QoSData with AC_VI (DENM/event-based 
> BSM) and AC_BE (CAM/periodic BSM), we have a ‘coexistence issue’ .
> 
> Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2 slot + 
> SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also with 2 slot 
> + SIFS. And CAM/periodic BSM use **6** slot + SIFS.
> 
> In short, any IP-over-OCB will access the channel before CAM/BSM at best 
> and generate collisions with ITS-G5 and DSRC. This can be seem as 
> ‘harmful’ interferences with an existing system, which must be avoided.
> 
> *Cc:* Alexandre Petrescu; [email-masked] <mailto:[email-masked]>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 02 Mar 2018 20:54:36 +0100

Hi Alex,

> Is there a discussion slot to discuss this in London?

You mean to discuss about QoS with IPv6 over 802.11-OCB? Are you
requesting it to present some material to foster the discussion?

We sure can allocate some time for that (I'd say that under the
"rechartering" discussion slot, as I understood that this issue is
closed for the WG doc, right?).

Do you think -20 is ready so I can review it and request our AD to send
the draft to 6man for review?

Thanks,

Carlos

> > https://transportationops.org/publications/dedicated-short-range-co
> > mmunications-roadside-unit-specifications, 
> > aren’t

---

From: Tony Li <[email-masked]>
Date: Fri, 2 Mar 2018 12:03:31 -0800

> On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> 

I’m not at all convinced that we have rough consensus on QoS yet.

If we don’t converge by London, I would propose a hum.

Tony

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 02 Mar 2018 21:18:16 +0100

Hi Tony,

OK, thanks.

Alex: can you summarize the different views in one single e-mail, so we
can take it from there?

Thanks,

Carlos

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 3 Mar 2018 14:27:37 +0100

Le 03/03/2018 à 01:33, Dick Roy a écrit :
> No, you do not have it right.  IEEE 802.11 links never have Ethernet II
> 802.3 headers; they have 802.11 headers. There is no tunneling of 802.3
> beneath/inside 802.11 to put it another way.

I agree.

> With the publication of .11ak, there is now a way to incorporate 802.11
> links in 802.1Q bridged LANs.  Prior to this, the means for getting 802.11
> streams onto 802.3 LANs was through the DS in the AP. In the DS, magically
> the headers got changed ... the DS was intentionally left to "vendor
> implementation".

I did not know that.

> I don't know where you got the idea 802.3 was tunneled inside 802.11,
> however you should abandon it.

I am not meaning any tunnel.

I think we dont understand each other.

The IP stacks dont fill 802.11 headers.  They fill Ethernet II (aka DIX) 
headers, accordidng to RFC2464 IPv6-over-Ethernet.  Then there is an 
adaptation layer that removes the EthernetII header and puts an 802.11 
header in there.

The Ethernet headers are not sent on 802.11, there is no tunneling.

(tunnelling == header in another header, or routing headers).

Alex

> 
> Hope this helps!
> 
> RR
> 
> PS. The DIX specification is only a part of 802.3; there's a bit more but
> it's a real kludge.
> 
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Friday, March 2, 2018 1:00 AM
> To: [email-masked]
> Cc: [email-masked]
>> */[RR] What "layer"? This makes little to no sense.
> 
>> Why would any "layer" take as input DLL headers (MAC and LLC sublayer
>> headers) and "produce" another MAC (and LLC) header???
> 
>> That's the function of a bridge!
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 3 Mar 2018 18:51:51 +0100

Hi Carlos,

The last version, -21, is neutral with respect to which 802.11 headers 
to use.  It says "802.11 headers" and does not say anything about which 
Subtype.  It does not say "MAY use QOSData", nor does it say "MAY use Data".

The different views on this topic are the following:

- some suggest the 802.11 Data headers is the best choice to transmit IP
   datagrams on 802.11 in OCB mode at 5.9 GHz.  The reasons invoked
   relate to: it is widely implemented this way, and there is some
   high-level doubting QoS in general across Internet.
- some suggest, on the contrary, that the best choice to transmit IP
   datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS Data
   headers instead.  The reasons invoked are: the OCB mode at 5.9GHz is
   already used to transmit very important non-IP packets (WSMP, CAM,
   etc), each using QoS Data headers; there may be a risk of loss of
   QoS guarantee if somebody else (IP) uses Data headers instead.
- the IEEE OCB standard permits the use of both QoSData headers _and_
   Data headers.  But further standards beyond that, require the use of
   QoSData headers although they dont say they require it for IP.
- a partial solution was suggested publicly, and agreed by some private
   and public emails, to use a certain QoS AC value (Access Category) to
   transport IP.
- many coexistence was required and necessary.

It is because of this difference of views that we removed the 
QoSData-vs-Data altogether from the IP-over-OCB draft.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 3 Mar 2018 19:03:31 +0100

Le 02/03/2018 à 20:54, Carlos Jesús Bernardos Cano a écrit :
> You mean to discuss about QoS with IPv6 over 802.11-OCB?

Yes.

> Are you

I asked Jérôme too, we think about this.

> closed for the WG doc, right?).

yes closed.

> the draft to 6man for review?

Yes, the -21 is ready.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 04 Mar 2018 16:39:25 +0100

Hi Alex,

Thanks for the summary.

Carlos

On Sat, 2018-03-03 at 18:51 +0100, Alexandre Petrescu wrote:
> > > > On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano <cjbc@
> > > > it.u
> > > > c3m.es> wrote:
> > > >

---

From: John Kenney <[email-masked]>
Date: Sun, 4 Mar 2018 15:20:38 -0800

Hi Alex,

Thanks for this summary.

I would like to add a couple of points, one with regard to standards and
one with regard to regulations.

* Standards: *
I was part of the IEEE 802.11 TGp task group that wrote the 802.11p
amendment.  I speak here only for myself. While we were focused on making
it work for DSRC in the 5.9 GHz band, we also recognized that this
"BSS-less" feature could be useful for others in the 802.11 community (a
kind of ad hoc Wi-Fi).  So, we tried not to over-constrain the definition
of the OCB type of communication, since we didn't know all of the use cases
to which it might be applied. We always expected to require EDCA for
vehicular communication in 5.9 GHz. We judged that that could be handled in
the IEEE 1609 standards (or in equivalent ETSI standards for Europe).  This
is why 802.11 allows DCF data frames while IEEE 1609 and EN 302 663 do
not.  To be clear, a WAVE device must use EDCA for all transmissions,
regardless of the L3 protocol.  It was never intended that DCF frames would
compete with EDCA frames for channel access in a band where safety-of-life
was at stake [To restate from earlier in the thread, in such a mix DCF
frames would have extremely high priority].  Perhaps we were too liberal
originally. Now, 8 years later, I am not aware of any other uses of the OCB
type of communication. Perhaps a future revision of 802.11 should omit the
DCF type of data frame when using OCB, to avoid any further confusion.

*Regulations:*
FCC 5.9 GHz regulations require that DSRC services provide access priority
to safety-of-life communication over all other DSRC communication.
Furthermore, a second class called public-safety communication is required
to have access priority over so-called non-priority communication. You can
find this in CFR 47 § 90.377 and  § 95.1511.  These regulatory requirements
are independent of the L3 protocol. EDCA is the only mechanism of which I
am aware to satisfy this regulation. More to the point, I believe that
non-safety-of-life packets using DCF would fail to meet the regulatory
requirement vis a vis safety-of-life packets that use EDCA.

I am not well versed in the spectrum use regulations of European countries.
I believe individual countries are permitted to regulate spectrum use based
on European Norms (ENs).  Perhaps EN 302 663's requirement to use EDCA will
be recognized in the regulations of some countries.

*Summary:*
Personally, I'm a bit surprised at the resistance to requiring EDCA in the
ipwave RFC. I think the arguments are quite compelling. I think the IPWAVE
WG should consider the applicability intended for its RFCs in this space.
If you intend implementations of this RFC to operate in the US 5.9 GHz
band, respect for the life-saving mission of DSRC (to say nothing of FCC
regulations) argues that for the common good those implementations should
follow the same priority system that all other devices use.

One could argue that it is sufficient for the RFC to be silent on the QoS
data type, as in the current draft. But, given the confusion that this
thread has exposed, I continue to think it better to explicitly require
EDCA.

Thanks,
John

On Sat, Mar 3, 2018 at 9:51 AM, Alexandre Petrescu <
[email-masked]> wrote:

> Hi Carlos,
>
> The last version, -21, is neutral with respect to which 802.11 headers to
> use.  It says "802.11 headers" and does not say anything about which

-- 
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: Sun, 4 Mar 2018 16:00:28 -0800

John,

Thank you for your comment. One note:

> One could argue that it is sufficient for the RFC to be silent on the QoS data type, as in the current draft.

Being silent will lead to multiple implementations making different interpretations of intent, resulting in non-interoperable implementations. 

Thus, silence is insufficient and we need to say something if we intend to publish a coherent spec.

Regards,
Tony

---

From: John Kenney <[email-masked]>
Date: Sun, 4 Mar 2018 17:02:14 -0800

I fully agree with Tony.

John

On Sun, Mar 4, 2018 at 4:00 PM, Tony Li <[email-masked]> wrote:

> data type, as in the current draft.
>
>
> Being silent will lead to multiple implementations making different
> interpretations of intent, resulting in non-interoperable implementations.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Mar 2018 13:58:07 +0100

just some implementations aspects worth considering when considering the 
QoSData question.

>    capabilities are absent in OCB).

In private, a partner pointed to an additional method to trigger the 
making of QoSData headers, although not sure whether it's for IP or 
non-IP.  Use setsockopt to set a distinct priority per socket (BK, BE, 
VI, VO):

>     setsockopt(Sock_VI,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_VI,sizeof(PRIORITY_VI));
>     setsockopt(Sock_VO,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_VO,sizeof(PRIORITY_VO));
>     setsockopt(Sock_BE,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_BE,sizeof(PRIORITY_BE));
>     setsockopt(Sock_BK,SOL_SOCKET ,SO_PRIORITY, &PRIORITY_BK,sizeof(PRIORITY_BK));

My analysis of it is the following: this method to generate packets with
QoSData headers seems valuable, but it seems dedicated to a particular
application. If I have an app that sends CAM messages then I setsockopt
like above in that app, and thus the CAM packets are preceded by QoSData.

On another hand, one may want _all_ apps in the computer to use QoSData
if at 5.9GHz in OCB mode, not just some application. I think setsockopt
may not be fully appropriate for that goal.

One may want some IP app to setsockopt one priority and another IP app 
to setsockopt another priority.

Alex

---

From: Tony Li <[email-masked]>
Date: Mon, 5 Mar 2018 07:41:12 -0800

> One may want some IP app to setsockopt one priority and another IP app to setsockopt another priority.

One may want many things.  As previously noted, there is very little use of QoS in the Internet. Almost no applications do this today.

Please remember that most of the IP packets that will ever pass through an OCB system will be sourced somewhere else in the Internet, off of OCB. Expecting someone on another continent to change their programming to suit our requirements is not reasonable.

Tony

---

From: François Simon <[email-masked]>
Date: Mon, 5 Mar 2018 11:50:39 -0500

One may want many things.  As previously noted, there is very little use of
QoS in the Internet. Almost no applications do this today.

Please remember that most of the IP packets that will ever pass through an
OCB system will be sourced somewhere else in the Internet, off of OCB.
Expecting someone on another continent to change their programming to suit
our requirements is not reasonable.

Tony

Sir,
While your argument may be valid, the fact is the IP application is using
OCB as a segment of the communication link (choice of IPWAVE WG).  In the US
IEEE 802.11 OCB also provide service to Safety applications which in many
instances remain local (i.e., V2V).  “Communications involving the safety of
life have access priority over all other DSRCS communications” [Ref: CFR §
95.1511]. If the IP application is not a Safety application, it will be
ranked as of lower priority. Thus, the requirement of QoSdata and EDCA.

Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Tony Li
Sent: Monday, March 05, 2018 10:41 AM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB
- implementations

> One may want some IP app to setsockopt one priority and another IP app to
setsockopt another priority.

One may want many things.  As previously noted, there is very little use of
QoS in the Internet. Almost no applications do this today.

Please remember that most of the IP packets that will ever pass through an
OCB system will be sourced somewhere else in the Internet, off of OCB.
Expecting someone on another continent to change their programming to suit
our requirements is not reasonable.

Tony

---

From: [email-masked]
Date: Mon, 5 Mar 2018 08:59:57 -0800

> While your argument may be valid, the fact is the IP application is using OCB as a segment of the communication link (choice of IPWAVE WG).  In the US IEEE 802.11 OCB also provide service to Safety applications which in many instances remain local (i.e., V2V).  “Communications involving the safety of life have access priority over all other DSRCS communications” [Ref: CFR § 95.1511]. If the IP application is not a Safety application, it will be ranked as of lower priority. Thus, the requirement of QoSdata and EDCA.

Bonjour François,

This point was (I think), already conceded and not the issue at hand.

The point that I was trying to make is that expecting IP applications to have correctly set QoS properties is overly optimistic.

Much of the IP traffic will be coming through OCB attached routers connected to the Internet, coming from servers run by people who have never, ever heard of DSRC/802.11p/OCB. And application writers even more removed.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 5 Mar 2018 21:32:05 +0200

> DCF type of data frame when using OCB, to avoid any further confusion.

+1

> find this in CFR 47 § 90.377 and  § 95.1511.  These regulatory
> requirements are independent of the L3 protocol. EDCA is the only mechanism
> of which I am aware to satisfy this regulation. More to the point, I
> believe that non-safety-of-life packets using DCF would fail to meet the
> regulatory requirement vis a vis safety-of-life packets that use EDCA.
>
> I am not well versed in the spectrum use regulations of European
> countries. I believe individual countries are permitted to regulate
> spectrum use based on European Norms (ENs).  Perhaps EN 302 663's
> requirement to use EDCA will be recognized in the regulations of some
> countries.
>
> *Summary:*
> ipwave RFC.

I agree

> I think the arguments are quite compelling. I think the IPWAVE WG should
> consider the applicability intended for its RFCs in this space. If you
> intend implementations of this RFC to operate in the US 5.9 GHz band,
> respect for the life-saving mission of DSRC (to say nothing of FCC

Accepting priority is important for this WG and within our use-cases.

AB

---

From: François Simon <[email-masked]>
Date: Mon, 5 Mar 2018 15:02:45 -0500

ABSOLUTELY !

Fygs

From: Abdussalam Baryun <[email-masked]> 
Sent: Monday, March 05, 2018 2:32 PM
To: John Kenney <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; Tony Li <[email-masked]>; its <[email-masked]>; François Simon <[email-masked]>; William Whyte <[email-masked]>; Jérôme Härri <[email-masked]>; Carlos Jesús Bernardos Cano <[email-masked]>; Dick Roy <[email-masked]>
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data - summary

On Mon, Mar 5, 2018 at 1:20 AM, John Kenney <[email-masked] <mailto:[email-masked]> > wrote:

Hi Alex,

Thanks for this summary.

I would like to add a couple of points, one with regard to standards and one with regard to regulations.

Standards: 

I was part of the IEEE 802.11 TGp task group that wrote the 802.11p amendment.  I speak here only for myself. While we were focused on making it work for DSRC in the 5.9 GHz band, we also recognized that this "BSS-less" feature could be useful for others in the 802.11 community (a kind of ad hoc Wi-Fi).  So, we tried not to over-constrain the definition of the OCB type of communication, since we didn't know all of the use cases to which it might be applied. We always expected to require EDCA for vehicular communication in 5.9 GHz. We judged that that could be handled in the IEEE 1609 standards (or in equivalent ETSI standards for Europe).  This is why 802.11 allows DCF data frames while IEEE 1609 and EN 302 663 do not.  To be clear, a WAVE device must use EDCA for all transmissions, regardless of the L3 protocol.  It was never intended that DCF frames would compete with EDCA frames for channel access in a band where safety-of-life was at stake [To restate from earlier in the thread, in such a mix DCF frames would have extremely high priority].  Perhaps we were too liberal originally. Now, 8 years later, I am not aware of any other uses of the OCB type of communication. Perhaps a future revision of 802.11 should omit the DCF type of data frame when using OCB, to avoid any further confusion.

+1 

Regulations:

FCC 5.9 GHz regulations require that DSRC services provide access priority to safety-of-life communication over all other DSRC communication. Furthermore, a second class called public-safety communication is required to have access priority over so-called non-priority communication. You can find this in CFR 47 § 90.377 and  § 95.1511.  These regulatory requirements are independent of the L3 protocol. EDCA is the only mechanism of which I am aware to satisfy this regulation. More to the point, I believe that non-safety-of-life packets using DCF would fail to meet the regulatory requirement vis a vis safety-of-life packets that use EDCA.

I am not well versed in the spectrum use regulations of European countries. I believe individual countries are permitted to regulate spectrum use based on European Norms (ENs).  Perhaps EN 302 663's requirement to use EDCA will be recognized in the regulations of some countries.

Summary:

Personally, I'm a bit surprised at the resistance to requiring EDCA in the ipwave RFC.

I agree

I think the arguments are quite compelling. I think the IPWAVE WG should consider the applicability intended for its RFCs in this space. If you intend implementations of this RFC to operate in the US 5.9 GHz band, respect for the life-saving mission of DSRC (to say nothing of FCC regulations) argues that for the common good those implementations should follow the same priority system that all other devices use.  

AB

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 05 Mar 2018 22:28:36 +0100

Hi,

OK, we will discuss this point in London and close it once for all.

As an individual, I tend to think that we should say something to make
a coherent spec.

Thanks,

Carlos

On Sun, 2018-03-04 at 17:02 -0800, John Kenney wrote:
> > > One could argue that it is sufficient for the RFC to be silent on
> > > the QoS data type, as in the current draft.
> >

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 05 Mar 2018 22:32:01 +0100

Hi Alex,

Thanks a lot for the summary. As mentioned in a previous e-mail, we
will discuss this topic during in London and take a decision.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 05 Mar 2018 22:32:59 +0100

Hi Alex,

> I asked Jérôme too, we think about this.

Please provide me with a topic title and requested time, so we can
organize the rechartering discussion.

Thanks,

Carlos

> > > > *Cc:* 'Alexandre Petrescu' <[email-masked]>; its@
> > > > ietf
> > > > .org
> > > > With the risk of repeating information already sent in the
> > > > thread,
> > > > the
> > > > issue has never been if Data or QoSData is allowed for OCB. It
> > > > is
> > > > clear
> > > > it is.
> > > > 
> > > > Indeed, 802.11 data frame use DCF, which use a DIFS equal to 2
> > > > slot
> > > > +
> > > > SIFS. Now, AC_VI (the urgent DENM/BSM) use EDCA AC_VI, also
> > > > with 2
> > > > slot
> > > > In short, any IP-over-OCB will access the channel before
> > > > CAM/BSM at
> > > > best
> > > > That is the reason I am suggesting to use QoSData for IP-over-
> > > > OCB,
> > > > so
> > > > that depending on your traffic (e.g. if you transmit CAM-over-
> > > > IP,
> > > > or
> > > > DSRC/ITS-G5..much. That would avoid a lot of issues…and it does
> > > > not
> > > > cost
> > > > much (ok some extra bits, but come on…we are not doing ROLL
> > > > here,
> > > > so is
> > > > it that dramatic?
> > > > 
> > > > Even though not the task of IETF, it is important to make sure
> > > > that
> > > > any
> > > > a good trade-off, and leave it open to profiling as function of
> > > > in
> > > > which
> > > > channel IP-over-OCB would be used (i.e if interference is
> > > > expected
> > > > or not)…
> > > > 
> > > > BR,
> > > > 
> > > > Jérôme
> > > > 
> > > > If that's the case, I don't have an issue with the draft
> > > > allowing
> > > > Data
> > > > Terminology section of the draft states that QoSData is
> > > > required
> > > > and
> > > > On the question of implementations: I don't have pcaps to hand,
> > > > but
> > > > the
> > > > requires QoSData, and OmniAir has been testing conformance to
> > > > that
> > > > spec,
> > > > -------------------------------------------------------------
> > > > ----
> > > > -------
> > > > 
> > > > *From:*its [mailto:[email-masked] <mailto:its-bounces@iet
> > > > f.or
> > > > g>]
> > > > > > (there are some packet dumps with IP packets transported
> > > > > > with
> > > > > > .11 Data
> > > > 
> > > > >      set properly in IP headers of Echorequest, but there is
> > > > > no
> > > > > .11 QoSData
> > > > >      with a flag called wme_sta that you could set to
> > > > > true.  But
> > > > > take care
> > > > >      that the C comments there say that it's not normal to
> > > > > use
> > > > > QoSData
> > > > >      headers in OCB mode, because a terminal sending QoSData
> > > > > has
> > > > > no
> > > > >      guarantee that receivers also use QoSData (the
> > > > > negotiation of
> > > > > QoS

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Mar 2018 11:24:30 +0100

Further implementation aspects tp be considered:

- expensive large Unex boards with Autotalks "802.11p" modems with the
   ThreadX OS (not linux) - do generate QoSData headers, but
   dont generate IP.

- cheap small Compex boards with Qualcomm Atheros "WiFi" modems in OCB
   mode with the linux OS - do not generate QoSData headers, but do
   generate IP (with Data headers).

Our draft is about IP and QoSData-vs-Data.

Alex

Le 05/03/2018 à 13:58, Alexandre Petrescu a écrit :
>> 802.11 Data instead.

---

From: François Simon <[email-masked]>
Date: Tue, 6 Mar 2018 06:31:55 -0500

The draft is about QoSData…..no versus.    Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Tuesday, March 06, 2018 5:25 AM
To: [email-masked]
Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB - implementations

Alex

Le 05/03/2018 à 13:58, Alexandre Petrescu a écrit :
> just some implementations aspects worth considering when considering 
> the QoSData question.
> 
>> packets transported as 802.11 QoSData, all IP packets are transported 
>> as
>> 802.11 Data instead.
>>
>> be
> My analysis of it is the following: this method to generate packets 
> with QoSData headers seems valuable, but it seems dedicated to a 
> particular application. If I have an app that sends CAM messages then 
> I setsockopt like above in that app, and thus the CAM packets are preceded by QoSData.
> 
> On another hand, one may want _all_ apps in the computer to use 
> QoSData if at 5.9GHz in OCB mode, not just some application. I think 
> setsockopt may not be fully appropriate for that goal.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Mar 2018 12:54:55 +0100

Le 06/03/2018 à 12:31, François Simon a écrit :
> /Our draft is about IP and QoSData-vs-Data.///
> 

Currently the draft does not say QoSData anymore. It just says 'headers'.

 From this implementation status, what do you think the evolution could be:

- the linux driver evolves into implementing QoSData for OCB?
- the proprietary products evolve into implementing IP for OCB?

Alex

>>>     setsockopt(Sock_VI,SOL_SOCKET ,SO_PRIORITY, 
> 
>>> &PRIORITY_VI,sizeof(PRIORITY_VI));
> 
>>>     setsockopt(Sock_VO,SOL_SOCKET ,SO_PRIORITY, 
> 
>>> &PRIORITY_VO,sizeof(PRIORITY_VO));
> 
>>>     setsockopt(Sock_BE,SOL_SOCKET ,SO_PRIORITY, 
> 
>>> &PRIORITY_BE,sizeof(PRIORITY_BE));
> 
>>>     setsockopt(Sock_BK,SOL_SOCKET ,SO_PRIORITY, 
> 
>>> &PRIORITY_BK,sizeof(PRIORITY_BK));
> 
>> 
>

---

From: Tony Li <[email-masked]>
Date: Tue, 6 Mar 2018 07:52:01 -0800

> - the proprietary products evolve into implementing IP for OCB?

Standards are supposed to drive products. Not vice versa.

While we have the utmost respect for running code, we do not create broken standards just to accommodate existing products.

Evolving the driver is easy. Probably a 1 hour hack.

For the proprietary products, that is up to their developers and management, and is not a concern of the WG.  If they choose to implement IP, they may find increased demand for their product.

Regards,
Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Mar 2018 19:54:44 +0100

Hi IPWAVErs,

Instead of an ambiguous MAY, we can use a 'knob' with a default value.

----

By default, the IPv6 packet transmitted on 802.11-OCB MUST be preceded
by an LLC header and a QoSData header; the value of the TID field is
0001 (aka UP==1, AC_BK). The value of the Traffic Class field of the IP
header MUST be x.

Each IP-OBU and IP-RSU system MUST provide a knob (SNMP, Yang, syscl,
other); the default value of the knob MUST be 'false'. When the value is
'true', the IP packet MUST be preceded by an LLC header and a Data
header, and the value of the Traffic Class field in the IPv6 header MUST
NOT be restricted. The actioning of this knob MUST be performed in
accordance with local regulation.

Alex

Le 05/03/2018 à 22:32, Carlos Jesús Bernardos Cano a écrit :
>> The last version, -21, is neutral with respect to which 802.11 
>> headers to use.  It says "802.11 headers" and does not say
>> anything about which Subtype.  It does not say "MAY use QOSData",
>> nor does it say "MAY use Data".
>> 
>> - some suggest the 802.11 Data headers is the best choice to 
>> transmit IP datagrams on 802.11 in OCB mode at 5.9 GHz.  The 
>> reasons invoked relate to: it is widely implemented this way, and 
>> there is some high-level doubting QoS in general across Internet.
>> - some suggest, on the contrary, that the best choice to transmit
>> IP datagrams on 802.11 in OCB mode at 5.9 GHz is the 802.11 QoS
>> Data headers instead.  The reasons invoked are: the OCB mode at
>> 5.9GHz is already used to transmit very important non-IP packets
>> (WSMP, CAM, etc), each using QoS Data headers; there may be a risk
>> of loss of QoS guarantee if somebody else (IP) uses Data headers
>> instead. - the IEEE OCB standard permits the use of both QoSData
>> headers _and_ Data headers.  But further standards beyond that,
>> require the use of QoSData headers although they dont say they
>> require it for IP. - a partial solution was suggested publicly, and
>> agreed by some private and public emails, to use a certain QoS AC
>> value (Access Category) to transport IP. - many coexistence was
>> required and necessary.
>> 
>>> Alex: can you summarize the different views in one single e-mail,
>>> so we can take it from there?
>>> 
>>> Thanks,
>>> 
>>> Carlos
>>> 
>>>>> On Mar 2, 2018, at 11:54 AM, Carlos Jesús Bernardos Cano 
>>>>> <cjbc@ it.u c3m.es> wrote:
>>>>> 
>>>>> You mean to discuss about QoS with IPv6 over 802.11-OCB? Are
>>>>>  you requesting it to present some material to foster the 
>>>>> discussion?
>>>>> 
>>>>> We sure can allocate some time for that (I'd say that under 
>>>>> the "rechartering" discussion slot, as I understood that
>>>>> this issue is closed for the WG doc, right?).
>>>> 
>>>>

---

From: Tony Li <[email-masked]>
Date: Wed, 07 Mar 2018 19:08:32 +0000

Hi Alex,

> 0001 (aka UP==1, AC_BK).

This part is good.  Thank you.

The value of the Traffic Class field of the IP
> header MUST be x.

Are you proposing that we rewrite a packet in flight? And if so, why?  This
doesn’t seem like the right thing to do.  I would just drop this sentence.

> accordance with local regulation.

I get that you’re trying to allow Data between consenting adults, but you
can do that by going outside of the spec anyway, so I’m not seeing this as
buying you much. Plus, implementations will probably not need this. I’d
suggest dropping this too.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Mar 2018 11:30:36 +0100

Tony,

> This part is good.  Thank you.

Noted, we can keep it.

> Are you proposing that we rewrite a packet in flight? And if so, why?

I understand you assume rewriting, because a packet arriving from the 
Internet would not have that Traffic Class set for OCB.  Certainly I 
dont propose rewriting, because communication from the Internet to a car 
should happen end-to-end, without rewriting, nor translation, nor proxying.

In the other direction - from the car to the Internet, and only for 
1-hop, the IP Traffic Class mapped to the 802.11 TID value and AC_BK, 
would make sense.

Given that rewriting is not good, but mapping IP-to-.11 fields is good 
for one hop, I dont know how to proceed.

> This doesn’t seem like the right thing to do.  I would just drop this 
> sentence.

We can drop it.  If we do, it would be very much about fields in headers 
below IP (not fields in the IP header).  It would be this:

> By default, the packet transmitted on 802.11-OCB with the value of the
> EtherType field equal to 0x86dd (IPv6) MUST be preceded by an LLC
> header and a QoSData header; the value of the TID field is 0001 (aka
> UP==1, AC_BK).

Should IETF write this before IEEE OCB does?

> I get that you’re trying to allow Data between consenting adults, but 
> you can do that by going outside of the spec anyway, so I’m not seeing 
> this as buying you much. Plus, implementations will probably not need 
> this. I’d suggest dropping this too.

There is this hackathon opportunity.  They say they dont have expensive 
cards there.  They ask which Internet Draft to test.  What would you 
tell them?

Alex

---

From: [email-masked]
Date: Thu, 8 Mar 2018 08:24:47 -0800

Alex,

> I understand you assume rewriting, because a packet arriving from the Internet would not have that Traffic Class set for OCB.  Certainly I dont propose rewriting, because communication from the Internet to a car should happen end-to-end, without rewriting, nor translation, nor proxying.
> 
> In the other direction - from the car to the Internet, and only for 1-hop, the IP Traffic Class mapped to the 802.11 TID value and AC_BK, would make sense.
> 
> Given that rewriting is not good, but mapping IP-to-.11 fields is good for one hop, I dont know how to proceed.

Once again, mapping IP to .11 fields is not good. The IP field is, with some exceptions, subject to fraud. It is not wise for us to mandate a mapping.

If this is a feature desired by some end-users, they can request it and apply it in cases where they feel that the IP traffic class is meaningful.

>> This doesn’t seem like the right thing to do.  I would just drop this sentence.
> 
> We can drop it.  If we do, it would be very much about fields in headers below IP (not fields in the IP header).  It would be this:
> 

The IEEE will never write that as it contains the word ‘IPv6’.  ;-)

If that’s the behavior that the group wants, then yes, that’s a preferable approach. I’m fine with it.

>> I get that you’re trying to allow Data between consenting adults, but you can do that by going outside of the spec anyway, so I’m not seeing this as buying you much. Plus, implementations will probably not need this. I’d suggest dropping this too.
> 
> There is this hackathon opportunity.  They say they dont have expensive cards there.  They ask which Internet Draft to test.  What would you tell them?

I don’t understand your comment and the relevance to setting a global standard for perpetuity.

If people don’t have the right kit, hardware or software, they should get it.  This is clearly evolving technology. I’m sorry that they experience inconvenience now, but we are not going to cause inconvenience for every other implementation just to save them some money.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 9 Mar 2018 14:30:54 +0100

> [email-masked] Thu, 08 March 2018 16:26 UTCShow header
[...]

I propose this text:

> The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded
> by a Logical Link Control (LLC) header and an 802.11 header; the value
> of the Subtype sub-field in the Frame Control field of the 802.11
> header MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic
> Identifier (TID) sub-field of the QoS Control field of the 802.11
> header MUST be set to binary 001 (i.e. User Priority 'Background', QoS
> Access Category 'AC_BK').

Do you agree with the values?

Alex

[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 9 Mar 2018 14:56:08 +0100

> Re: [ipwave] 802.11 Data vs 802.11 QoS Data - towards resolution
> 
>>> The value of the Traffic Class field of the IP header MUST be x. 
>> I understand you assume rewriting, because a packet arriving from
>> the Internet would not have that Traffic Class set for OCB.
>> Certainly I dont propose rewriting, because communication from the
>> Internet to a car should happen end-to-end, without rewriting, nor
>> translation, nor proxying.
>> 
>> 1-hop, the IP Traffic Class mapped to the 802.11 TID value and
>> AC_BK, would make sense.
>> 
>> Given that rewriting is not good, but mapping IP-to-.11 fields is
>> good for one hop, I dont know how to proceed.
> 
> 
> Once again, mapping IP to .11 fields is not good. The IP field is,
> with some exceptions, subject to fraud. It is not wise for us to
> mandate a mapping.
> 
> If this is a feature desired by some end-users, they can request it
> and apply it in cases where they feel that the IP traffic class is
> meaningful.

Ok, maybe later we can think of another draft that overrides that.

I am thinking that some traffic _inside_ the car, on future-Ethernet,
must respect some stringent in-car QoS requirements. I would like the
ADSystem in one car to talk to the ADSystem in the other car, over the
OCB interfaces in series with the future-Ethernet interfaces. That would
make for some need for mapping IP TC field into QoS fields of
future-Ethernet and of OCB, I think.

(it's useless to guarantee QoS _outside_ the car if it's not guaranteed
inside too; just like it cant be pretended to guarantee QoS for BSM if
IP-over-OCB does not use QoSData).

>> We can drop it.  If we do, it would be very much about fields in
>> headers below IP (not fields in the IP header).  It would be this:
>> 
>>> By default, the packet transmitted on 802.11-OCB with the value
>>> of the EtherType field equal to 0x86dd (IPv6) MUST be preceded by
>>> an LLC header and a QoSData header; the value of the TID field is
>>> 0001 (aka UP==1, AC_BK).
>> 

I understand that you think the group wants IETF to write it first.  So 
be it.

>>> Each IP-OBU and IP-RSU system MUST provide a knob (SNMP, Yang,
>>> syscl, other); the default value of the knob MUST be 'false'.
>>> When the value is 'true', the IP packet MUST be preceded by an
>>> LLC header and a Data header, and the value of the Traffic Class
>>> field in the IPv6 header MUST NOT be restricted. The actioning of
>>> this knob MUST be performed in accordance with local regulation. 
>>> I get that you’re trying to allow Data between consenting adults,
>>> but you can do that by going outside of the spec anyway, so I’m
>>> not seeing this as buying you much. Plus, implementations will
>>> probably not need this. I’d suggest dropping this too.
>> 
>> There is this hackathon opportunity.  They say they dont have
>> expensive cards there.  They ask which Internet Draft to test.
>> What would you tell them?
> 
> 
> If people don’t have the right kit, hardware or software, they should
> get it.  This is clearly evolving technology. I’m sorry that they
> experience inconvenience now, but we are not going to cause
> inconvenience for every other implementation just to save them some
> money.

It is not complex to write software to make IP packets for the expensive 
802.11-OCB QoSData-capable cards, but only the manufacturers of these 
cards have the necessary tools to do it.

It is complex to write software to make QoSData headers for the cheap 
802.11-OCB Data-capable cards that already support IP, but very many 
open-source developpers in the Internet have the necessary tools to do it.

Maybe this Internet Draft is for both manufacturers and open-source 
developpers.

Alex

---

From: [email-masked]
Date: Fri, 9 Mar 2018 08:34:57 -0800

Alex,

> Ok, maybe later we can think of another draft that overrides that.

No draft is necessary.  

What two consenting, adult implementations do within their own airspace is their own business.

> must respect some stringent in-car QoS requirements.

Vehicle interior traffic will be Ethernet for chassis mounted systems and will be Wi-Fi for passenger devices (mobile, tablet, laptop).  This much is very clear. The market has already decided.

There is no QoS there today. It’s not magically going to happen.

> IP-over-OCB does not use QoSData).

Who is going to manage the QoS inside the car? While the vehicle based systems might be well behaved, passenger devices are unregulated.

> Maybe this Internet Draft is for both manufacturers and open-source developpers.

Always.

Tony

---

From: [email-masked]
Date: Fri, 9 Mar 2018 08:36:29 -0800

Alex,

> Do you agree with the values?

I’m fine with this, thank you.

Others?  We need rough consensus….

Tony