Subject: [ipwave] Mirja Kühlewind's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 09 Jul 2019 09:43:18 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ipwave-ipv6-over-80211ocb-49: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

One point on this sentence, which I believe was also commented in the TSV-ART
review (Thanks Jörg!):

sec 4.2: "The mapping to the 802.11 data service MUST use a
   'priority' value of 1, which specifies the use of QoS with a
   'Background' user priority."
I don't think this should be a MUST requirement. I assume the assumption here
is that IP traffic is always some "random" data that is less important than
other V2V communication. However, this is a generic mapping document and should
therefore probably not make such an assumption (or at least it would need to be
spelled out).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One editorial high level comment: I seams like all text that was somehow deemed
as out fo scope for the main body of this document got stuffed into the
appendix. Please consider removing what is really not needed in this document
as these pages also take review and RFC Editor time, especially as they seem to
have received less review and therefore have more nits.

nit: sec 4.5.2 s/in OCB mode.A  A future improvement/in OCB mode. A future
improvement/

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 9 Jul 2019 22:29:34 +0100

Hi Mirja,

Thank you for your review and comments.

You raised a very important point that was discussed extensively on the ML
and then we asked the IEEE 802.11 members (thanks to Dorothy Stanly) to
provide us with a review to help us clarify this point.

Here is what we got from them:

.  *Suggest to simply state that the data is transmitted with “User
Priority” of Background (numerically 1 or 2)*, and leave the internal
details of how this is accomplished to the 802.11 specification.

User Priority is typically described as a simple integer (not a binary
value), and the mapping of this User Priority to TID header value is
another 802.11 detail, best left to the 802.11 specification.  For example:
in the 802.11 specification the TID field is specified to be *4 bits* in
the header.  The use of these 4 bits to carry the User Priority information
is an internal specification of 802.11 and potentially subject to change.

Suggest using terminology from the MAC SAP in IEEE Std 802.11-2016 Clause
5.2.  This clause intentionally abstracts the exact details of 802.11’s
internal operation, while describing specifically the behavior required by
the user.  For example, the following text:

“In the 802.11 header, the value of the Subtype sub-field in the Frame
Control field 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').”

*could be replaced by:*

“*The mapping to the 802.11 data service MUST use a ‘priority’ value of 1,
which specifies the use of QoS with a “Background” user priority*.”

Thanks again.

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Jul 2019 09:32:49 +0200

Le 09/07/2019 à 23:29, Nabil Benamar a écrit :
> You raised a very important point that was discussed extensively on the 
> ML and then we asked the IEEE 802.11 members (thanks to Dorothy Stanly) 
> to provide us with a review to help us clarify this point.
> 
> another 802.11 detail, best left to the 802.11 specification. For 
> example: in the 802.11 specification the TID field is specified to be *4 
> bits* in the header.  The use of these 4 bits to carry the User Priority 
> information is an internal specification of 802.11 and potentially 
> subject to change.
> 
> Suggest using terminology from the MAC SAP in IEEE Std 802.11-2016 
> Clause 5.2.  This clause intentionally abstracts the exact details of 
> 802.11’s internal operation, while describing specifically the behavior 
> required by the user. For example, the following text:
> 
> Control field 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').”

On my side I do not agree with it.

Only the expensive non open source implementations implement 802.11 QoS 
Data headers, including the QoS fields you suggest (background user 
priority).

The cheap open source implementations, including the ones during 
HAckathon, do not exhibit QoS headers in wireshark packet dumps in 
monitor mode.

I think I will have to write another draft called IPv6-over-OCB-without 
QoS : that is what is implemented in open source and cheap implementations.

There is however interoperability: an RA sent by an IP-RSU with QoS 
header is understood well by an IP-OBU who does not understand QoS 
headers; vice-versa as well.

The fact that QoS headers are there in the specificatioin of IP over OCB 
comes from implementers that do not share the code publicly.  It is for 
implementations that are much more expensive and that try to suggest a 
higher quality is present.  However, I strongly doubt the quality 
improvements.

Quality here comes from many people doing something and the best to be 
elected naturally; it does not come from commercial interest.

Alex
> 
> _could be replaced by:_
> 
> “*The mapping to the 802.11 data service MUST use a ‘priority’ value of 
> 1, which specifies the use of QoS with a “Background” user priority*.”
> 
> 
> Thanks again.
> 
> 
> On Tue, Jul 9, 2019 at 5:43 PM Mirja Kühlewind via Datatracker 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 10 Jul 2019 09:44:16 +0200

Hi Nabil,

I think my point was slightly different. Dorothy mainly advised you _how_ to specify the priority. However my question is rather _if_ that is needed and if it is really appropriate to use a MUST here. Can you further explain why that is seen as a mandatory requirement?

Mirja

> On 9. Jul 2019, at 23:29, Nabil Benamar <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> You raised a very important point that was discussed extensively on the ML and then we asked the IEEE 802.11 members (thanks to Dorothy Stanly) to provide us with a review to help us clarify this point.
> 
> .  Suggest to simply state that the data is transmitted with “User Priority” of Background (numerically 1 or 2), and leave the internal details of how this is accomplished to the 802.11 specification.
> 
> User Priority is typically described as a simple integer (not a binary value), and the mapping of this User Priority to TID header value is another 802.11 detail, best left to the 802.11 specification.  For example: in the 802.11 specification the TID field is specified to be 4 bits in the header.  The use of these 4 bits to carry the User Priority information is an internal specification of 802.11 and potentially subject to change. 
> 
> Suggest using terminology from the MAC SAP in IEEE Std 802.11-2016 Clause 5.2.  This clause intentionally abstracts the exact details of 802.11’s internal operation, while describing specifically the behavior required by the user.  For example, the following text:
> 
> “In the 802.11 header, the value of the Subtype sub-field in the Frame Control field 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').” 
> 
> could be replaced by:
> 
> 
> “The mapping to the 802.11 data service MUST use a ‘priority’ value of 1, which specifies the use of QoS with a “Background” user priority.” 
> 
> 
> 
> Thanks again.
> 
> 
> On Tue, Jul 9, 2019 at 5:43 PM Mirja Kühlewind via Datatracker <[email-masked]> wrote:

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 10 Jul 2019 12:39:44 +0100

Hi Mirja,

Actually, the text was written some time ago and different views were
shared in the group. I think we need to remove this text to avoid confusion.

On Wed, Jul 10, 2019 at 8:44 AM Mirja Kuehlewind <[email-masked]>
wrote:

> Hi Nabil,
>
> I think my point was slightly different. Dorothy mainly advised you _how_
> to specify the priority. However my question is rather _if_ that is needed
> and if it is really appropriate to use a MUST here. Can you further explain
> why that is seen as a mandatory requirement?
>
> Mirja
>
>
>
> ML and then we asked the IEEE 802.11 members (thanks to Dorothy Stanly) to
> > .  Suggest to simply state that the data is transmitted with “User
> Priority” of Background (numerically 1 or 2), and leave the internal
> in the 802.11 specification the TID field is specified to be 4 bits in the
> header.  The use of these 4 bits to carry the User Priority information is
> an internal specification of 802.11 and potentially subject to change.
> >
> > “The mapping to the 802.11 data service MUST use a ‘priority’ value of
> 1, which specifies the use of QoS with a “Background” user priority.”
> >
> >
> >
> > Thanks again.
> >
> >

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 10 Jul 2019 15:18:26 +0200

Thanks. Removing this text entirely is a good option.

Mirja

> On 10. Jul 2019, at 13:39, Nabil Benamar <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> Actually, the text was written some time ago and different views were shared in the group. I think we need to remove this text to avoid confusion.
> 
> On Wed, Jul 10, 2019 at 8:44 AM Mirja Kuehlewind <[email-masked]> wrote:
> Hi Nabil,
> 
> > User Priority is typically described as a simple integer (not a binary value), and the mapping of this User Priority to TID header value is another 802.11 detail, best left to the 802.11 specification.  For example: in the 802.11 specification the TID field is specified to be 4 bits in the header.  The use of these 4 bits to carry the User Priority information is an internal specification of 802.11 and potentially subject to change.. 
> > 
> > Suggest using terminology from the MAC SAP in IEEE Std 802.11-2016 Clause 5.2.  This clause intentionally abstracts the exact details of 802..11’s internal operation, while describing specifically the behavior required by the user.  For example, the following text:
> >

---

From: John Kenney <[email-masked]>
Date: Wed, 10 Jul 2019 16:40:13 -0700

Hi All:

I have no desire to re-litigate the QoS issue. However, it's important to
remember that IP-over-OCB will typically share public regulated spectrum
with non-IP safety-of-life communications. In the US, FCC regulations
require that such safety communications have access priority over other
communications [47 CFR § 90.377(d)] .  I would be cautious about removing
the current language unless you are convinced that doing so will not
adversely affect non-IP safety communications.

Best Regards,
John

On Wed, Jul 10, 2019 at 6:18 AM Mirja Kuehlewind <[email-masked]>
wrote:

> > I think my point was slightly different. Dorothy mainly advised you
> _how_ to specify the priority. However my question is rather _if_ that is
> needed and if it is really appropriate to use a MUST here. Can you further
> explain why that is seen as a mandatory requirement?
> >
> > Mirja
> >
> >
> >
> > > You raised a very important point that was discussed extensively on
> the ML and then we asked the IEEE 802.11 members (thanks to Dorothy Stanly)
> an internal specification of 802.11 and potentially subject to change..
> > >
> 802..11’s internal operation, while describing specifically the behavior

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Jul 2019 11:51:24 -0400

I suggest that the MUST statement remain, but that a bit of rationale be provided:

   The IPv6 packet transmitted on 802.11-OCB are immediately preceded by
   a Logical Link Control (LLC) header and an 802.11 header.  In the LLC
   header, and in accordance with the EtherType Protocol Discrimination
   (EPD, see Appendix D), the value of the Type field MUST be set to
   0x86DD (IPv6).  The mapping to the 802.11 data service MUST use a
   'priority' value of 1 (QoS with a 'Background' user priority), reserving
   higher priority values for safety-critical and time-sensitive
   traffic [IEEE-1609.2].   

Russ

> On Jul 10, 2019, at 7:40 PM, John Kenney <[email-masked]> wrote:
> 
> Hi All:
> 
> I have no desire to re-litigate the QoS issue. However, it's important to remember that IP-over-OCB will typically share public regulated spectrum with non-IP safety-of-life communications. In the US, FCC regulations require that such safety communications have access priority over other communications [47 CFR § 90.377(d)] .  I would be cautious about removing the current language unless you are convinced that doing so will not adversely affect non-IP safety communications.
> 
> Best Regards,
> John
> 
> On Wed, Jul 10, 2019 at 6:18 AM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
> > On 10. Jul 2019, at 13:39, Nabil Benamar <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi Mirja,
> > 
> > On Wed, Jul 10, 2019 at 8:44 AM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
> > Hi Nabil,
> > 
> > > On 9. Jul 2019, at 23:29, Nabil Benamar <[email-masked] <mailto:[email-masked]>> wrote:
> > > 
> > > Hi Mirja,
> > > 
> > > On Tue, Jul 9, 2019 at 5:43 PM Mirja Kühlewind via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
> > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > > https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ <https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/>
> > > 
> > > 
> > > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> -- 
> John Kenney

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 11 Jul 2019 17:57:20 +0200

Hi Russ,

This would also be good and address my discuss. However, IP is not really a specific service and I could well imagine that in future there could also be a more critical service that is implemented over IP (for whatever reason). To leave this as generic as possible, which I think a mapping document should be, I would recommend to us SHOULD or no normative language at all.

Mirja

> On 11. Jul 2019, at 17:51, Russ Housley <[email-masked]> wrote:
> 
>> On Wed, Jul 10, 2019 at 6:18 AM Mirja Kuehlewind <[email-masked]> wrote:

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Jul 2019 14:32:57 +0200

hats and freedoms are valuable.

I disagree with the second MUST.  I will write a draft IPv6-over-OCB 
without QoS headers.

Alex

Le 11/07/2019 à 17:51, Russ Housley a écrit :
>> On Jul 10, 2019, at 7:40 PM, John Kenney <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi All:
>>
>> I have no desire to re-litigate the QoS issue. However, it's important 
>> to remember that IP-over-OCB will typically share public regulated 
>> spectrum with non-IP safety-of-life communications. In the US, FCC 
>> regulations require that such safety communications have access 
>> priority over other communications [47 CFR § 90.377(d)] .  I would be 
>> cautious about removing the current language unless you are convinced 
>> that doing so will not adversely affect non-IP safety communications.
>>
>> Best Regards,
>> John
>>
>>     > On 10. Jul 2019, at 13:39, Nabil Benamar
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     >
>>     > Hi Mirja,
>>     >
>>     > Actually, the text was written some time ago and different views
>>     were shared in the group. I think we need to remove this text to
>>     avoid confusion.
>>     >
>>     > On Wed, Jul 10, 2019 at 8:44 AM Mirja Kuehlewind
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     > Hi Nabil,
>>     >
>>     > I think my point was slightly different. Dorothy mainly advised
>>     you _how_ to specify the priority. However my question is rather
>>     _if_ that is needed and if it is really appropriate to use a MUST
>>     here. Can you further explain why that is seen as a mandatory
>>     requirement?
>>     >
>>     > Mirja
>>     >
>>     >
>>     >
>>     > > On 9. Jul 2019, at 23:29, Nabil Benamar
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     > >
>>     > > Hi Mirja,
>>     > >
>>     > > You raised a very important point that was discussed
>>     extensively on the ML and then we asked the IEEE 802.11 members
>>     (thanks to Dorothy Stanly) to provide us with a review to help us
>>     clarify this point.
>>     > >
>>     > > .  Suggest to simply state that the data is transmitted with
>>     “User Priority” of Background (numerically 1 or 2), and leave the
>>     internal details of how this is accomplished to the 802.11
>>     specification.
>>     > >
>>     > > User Priority is typically described as a simple integer (not
>>     a binary value), and the mapping of this User Priority to TID
>>     header value is another 802.11 detail, best left to the 802.11
>>     specification.  For example: in the 802.11 specification the TID
>>     field is specified to be 4 bits in the header.  The use of these 4
>>     bits to carry the User Priority information is an internal
>>     specification of 802.11 and potentially subject to change..
>>     > >
>>     > > Suggest using terminology from the MAC SAP in IEEE Std
>>     802.11-2016 Clause 5.2.  This clause intentionally abstracts the
>>     exact details of 802..11’s internal operation, while describing
>>     specifically the behavior required by the user.  For example, the
>>     following text:
>>     > >
>>     > > “In the 802.11 header, the value of the Subtype sub-field in
>>     the Frame Control field 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').”
>>     > >
>>     > > could be replaced by:
>>     > >
>>     > >
>>     > > “The mapping to the 802.11 data service MUST use a ‘priority’
>>     value of 1, which specifies the use of QoS with a “Background”
>>     user priority.”
>>     > >
>>     > >
>>     > >
>>     > > Thanks again.
>>     > >
>>     > >

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2019 22:53:18 -0400

Alex:

I did not add or remove any MUST statements.  I only added a phrase of rationale.

Russ

> On Jul 12, 2019, at 8:32 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> I disagree with the second MUST.  I will write a draft IPv6-over-OCB without QoS headers.
> 
> Alex
> 
>>> On Jul 10, 2019, at 7:40 PM, John Kenney <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi All:
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Jul 2019 15:32:16 +0200

> I did not add or remove any MUST statements.  I only added a phrase of rationale.

I agree that the 2nd MUST was there before, and that a phrase of 
rationale was added.

The phrase of rationale motivates the 2nd MUST.  It is logical.

I agree with the rationale but I disagree with the MUST.

(It is possible to implement the rationale without doing the MUST.  I.e. 
it is possible to guarantee time-sensitiveness and criticality of safety 
by increasing bandwidth; reserving QoS priorities is but an alternative 
to satisfy the rationale within a limited bandwidth.)

(the bandwidth available on 802.11 in OCB mode currently peaks at 
16Mbit/s theoretical within a range of approximately 1km measured.  The 
number of OCB interfaces in an OCB subnet of that physical size is less 
than hundreds, and certainly not thousands.  Within these dimensions, 
criticality and time-sensitiveness could be happening naturally.  An 
increase in theoretical bandwidth to approximately 54mbit/s would be 
even more sufficient)

(disturbing the time-sensitiveness and criticality of safety can be 
realized despite the guarantees offered by QoS priorities; radio jamming 
and IP security attacks are easy to perform and would overcome QoS 
priorities.)

Alex

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Jul 2019 10:38:56 -0400

Alex:

Of course, jamming will deny service, regardless of the values used for the QoS bits.

What would you like to see instead of the second MUST?

Russ

> On Jul 15, 2019, at 9:32 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> I agree that the 2nd MUST was there before, and that a phrase of rationale was added.
> 
> (It is possible to implement the rationale without doing the MUST.  I.e. it is possible to guarantee time-sensitiveness and criticality of safety by increasing bandwidth; reserving QoS priorities is but an alternative to satisfy the rationale within a limited bandwidth.)
> 
> (the bandwidth available on 802.11 in OCB mode currently peaks at 16Mbit/s theoretical within a range of approximately 1km measured.  The number of OCB interfaces in an OCB subnet of that physical size is less than hundreds, and certainly not thousands.  Within these dimensions, criticality and time-sensitiveness could be happening naturally.  An increase in theoretical bandwidth to approximately 54mbit/s would be even more sufficient)
> 
> (disturbing the time-sensitiveness and criticality of safety can be realized despite the guarantees offered by QoS priorities; radio jamming and IP security attacks are easy to perform and would overcome QoS priorities.)
> 
> Alex
> 
>> Russ

---

From: John Kenney <[email-masked]>
Date: Mon, 15 Jul 2019 08:33:18 -0700

Hi All:

I don’t want to be argumentative, but I believe automotive experts would
disagree with this back-of-the-envelope analysis. Channel congestion is a
real concern.  It can arise on channels carrying key safety services like
collision avoidance (BSM/CAM/DENM), personal safety (for pedestrians,
bicyclists and other vulnerable road users), platooning, cooperative
perception, and many I2V services.  SAE and ETSI have taken concrete steps
to standardize congestion control. IEEE 1609 and ETSI require use of QoS
packets, because prioritizing channel access is an important tool to
mitigate the effects of congestion on channels with mixed traffic.

The interference range will typically go well beyond 1 km (I.e. 500 m
radius).  Density studies have shown realistic densities of more than one
thousand in an interference range, and that is what we plan for.

Interested parties are invited to participate in standardization related to
scalability issues at SAE, IEEE 1609, and ETSI.

Best Regards,
John

On Mon, Jul 15, 2019 at 6:32 AM Alexandre Petrescu <
[email-masked]> wrote:

> >>>> I have no desire to re-litigate the QoS issue. However, it's
> important to remember that IP-over-OCB will typically share public
> regulated spectrum with non-IP safety-of-life communications. In the US,
> FCC regulations require that such safety communications have access
> cautious about removing the current language unless you are convinced that
> doing so will not adversely affect non-IP safety communications.
> >>>>
> >>>> Best Regards,
> >>>> John
> >>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Jul 2019 10:36:34 +0200

Russ,

> What would you like to see instead of the second MUST?

I would like to see something like this:

OLD:
>    IP packets MUST be transmitted over 802.11-OCB media as QoS Data
>    frames whose format is specified in IEEE 802.11 spec
>    [IEEE-802.11-2016].
> 
>    'Background' user priority.

NEW:
>    The IPv6 packets transmitted on 802.11-OCB are immediately preceded
>    by a Logical Link Control (LLC) header and an 802.11 header.  In
>    the LLC header, and in accordance with the EtherType Protocol
>    Discrimination (EPD, see Appendix D), the value of the Type field
>    MUST be set to 0x86DD (IPv6).
> 
>    In open systems, the 802.11 header preceding the IP header
>    transmitted over 802.11-OCB media MUST be an 802.11 Data header.
>    In such systems, receivers of IP packets over 802.11-OCB MUST
>    understand and fully parse IP packets preceded by 802.11 Data
>    headers.  Receivers SHOULD NOT drop IP packets preceded by 802.11
>    QoS Data headers.
> 
>    In closed systems, the 802.11 header preceding the IP header
>    transmitted over 802.11-OCB media SHOULD be an 802.11 QoS Data
>    header.  In such systems, receivers of IP packets over 802.11-OCB
>    MUST understand and fully parse IP packets preceded by 802.11 QoS
>    Data headers.  In such systems, it is required that the mapping to
>    the 802.11 data service MUST use a 'priority' value of 1, which
>    specifies the use of QoS with a 'Background' user priority.
> 
>    The frame format of 802.11 Data headers and QoS Data headers is
>    specifed in IEEE 802.11 spec [IEEE-802.11-2016].

Alex

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Jul 2019 12:56:50 -0400

Alex:

I am very uncomfortable with your proposed text.  IEEE 802.11-OCB uses special-purpose frequency allocation.  I think the text about open vs. closed systems is going to add confusion, not clarity.

Russ

> On Jul 16, 2019, at 4:36 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Russ,
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Jul 2019 15:41:58 -0400

Mirja:

The safety messages defined in IEEE 1902.2 do not use IP, but you are right that this document should not have to change if such a thing were to be defined in the future.

I suggest:

  0x86DD (IPv6).  The mapping to the 802.11 data service SHOULD use a

Russ

> On Jul 11, 2019, at 11:57 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 16 Jul 2019 21:52:39 +0200

Russ,

Sorry if the open-vs-closed text adds no clarity, but I do not know how
to express it better.

I think the special-purpose frequency allocation for 802.11-OCB does not
impose QoS Data headers, even though it does tell that range is for
safety applications for ITS.  I may be wrong though.

Finally, as far as I know, there are no IPv6-over-OCB implementations
with QoS Data headers, even if there are many implementations of CAM
and BSM over 802.11-OCB with such headers.  But I will be happy to stand
corrected if this were the case: is there an implementation of
IPv6-over-OCB with QoS Data headers?

Alex

Le 16/07/2019 à 18:56, Russ Housley a écrit :
> Alex:
> 
> I am very uncomfortable with your proposed text.  IEEE 802.11-OCB 
> uses special-purpose frequency allocation.  I think the text about 
> open vs. closed systems is going to add confusion, not clarity.
> 
> Russ
> 
> 
>>> Alex: Of course, jamming will deny service, regardless of the 
>>> values used for the QoS bits. What would you like to see instead
>>>  of the second MUST? Russ
>> 
>>> [IEEE-802.11-2016]. The IPv6 packet transmitted on 802.11-OCB are
>>> immediately preceded by a Logical Link Control (LLC) header and
>>> an 802.11 header.  In the LLC header, and in accordance with the
>>> EtherType Protocol Discrimination (EPD, see Appendix D), the 
>>> value of the Type field MUST be set to 0x86DD (IPv6).  The 
>>> mapping to the 802.11 data service MUST use a 'priority' value of
>>> 1, which specifies the use of QoS with a 'Background' user 
>>> priority.
>> 
>> NEW:
>>> The IPv6 packets transmitted on 802.11-OCB are immediately 
>>> preceded by a Logical Link Control (LLC) header and an 802.11 
>>> header.  In the LLC header, and in accordance with the EtherType
>>>  Protocol Discrimination (EPD, see Appendix D), the value of the
>>>  Type field MUST be set to 0x86DD (IPv6). In open systems, the 
>>> 802.11 header preceding the IP header transmitted over 802.11-OCB
>>> media MUST be an 802.11 Data header. In such systems, receivers
>>> of IP packets over 802.11-OCB MUST understand and fully parse IP
>>> packets preceded by 802.11 Data headers.  Receivers SHOULD NOT
>>> drop IP packets preceded by 802.11 QoS Data headers. In closed
>>> systems, the 802.11 header preceding the IP header transmitted
>>> over 802.11-OCB media SHOULD be an 802.11 QoS Data header.  In
>>> such systems, receivers of IP packets over 802.11-OCB MUST
>>> understand and fully parse IP packets preceded by 802.11 QoS Data
>>> headers.  In such systems, it is required that the mapping to the
>>> 802.11 data service MUST use a 'priority' value of 1, which
>>> specifies the use of QoS with a 'Background' user priority. The
>>> frame format of 802.11 Data headers and QoS Data headers is 
>>>>> Alex: I did not add or remove any MUST statements.  I only 
>>>>> added a phrase of rationale.
>>>> 
>>>> (It is possible to implement the rationale without doing the 
>>>> MUST.  I.e. it is possible to guarantee time-sensitiveness and
>>>>  criticality of safety by increasing bandwidth; reserving QoS 
>>>> priorities is but an alternative to satisfy the rationale 
>>>> within a limited bandwidth.)
>>>> 
>>>> (the bandwidth available on 802.11 in OCB mode currently peaks
>>>>  at 16Mbit/s theoretical within a range of approximately 1km 
>>>> measured.  The number of OCB interfaces in an OCB subnet of 
>>>> that physical size is less than hundreds, and certainly not 
>>>> thousands.  Within these dimensions, criticality and 
>>>> time-sensitiveness could be happening naturally.  An increase 
>>>> in theoretical bandwidth to approximately 54mbit/s would be 
>>>> even more sufficient)
>>>> 
>>>> (disturbing the time-sensitiveness and criticality of safety 
>>>> can be realized despite the guarantees offered by QoS 
>>>> priorities; radio jamming and IP security attacks are easy to 
>>>> perform and would overcome QoS priorities.)
>>>> 
>>>> Alex
>>>> 
>>>>> Russ
>>>>>>> I suggest that the MUST statement remain, but that a bit
>>>>>>>  of rationale be provided: The IPv6 packet transmitted on
>>>>>>>  802.11-OCB are immediately preceded by a Logical Link 
>>>>>>> Control (LLC) header and an 802.11 header.  In the LLC 
>>>>>>> header, and in accordance with the EtherType Protocol 
>>>>>>> Discrimination (EPD, see Appendix D), the value of the 
>>>>>>> Type field MUST be set to 0x86DD (IPv6).  The mapping to
>>>>>>>  the 802.11 data service MUST use a 'priority' value of 1
>>>>>>>  (QoS with a 'Background' user priority), reserving 
>>>>>>> higher priority values for safety-critical and 
>>>>>>> time-sensitive traffic [IEEE-1609.2]. Russ
>>>>>>>> I have no desire to re-litigate the QoS issue. However,
>>>>>>>> it's important to remember that IP-over-OCB will
>>>>>>>> typically share public regulated spectrum with non-IP
>>>>>>>> safety-of-life communications. In the US, FCC 
>>>>>>>> regulations require that such safety communications 
>>>>>>>> have access priority over other communications [47 CFR
>>>>>>>>  § 90.377(d)] .  I would be cautious about removing the
>>>>>>>>  current language unless you are convinced that doing 
>>>>>>>> so will not adversely affect non-IP safety 
>>>>>>>> communications.
>>>>>>>> 
>>>>>>>> Best Regards, John
>>>>>>>> 
>>>>>>>> On Wed, Jul 10, 2019 at 6:18 AM Mirja Kuehlewind 
>>>>>>>> were shared in the group. I think we need to remove 
>>>>>>>> this text to avoid confusion.
>>>>>>>>> 
>>>>>>>> you _how_ to specify the priority. However my question
>>>>>>>>  is rather _if_ that is needed and if it is really 
>>>>>>>> appropriate to use a MUST here. Can you further explain
>>>>>>>> extensively on the ML and then we asked the IEEE 802.11
>>>>>>>> members (thanks to Dorothy Stanly) to provide us with a
>>>>>>>> review to help us clarify this point.
>>>>>>>>>> 
>>>>>>>> “User Priority” of Background (numerically 1 or 2), and
>>>>>>>> leave the internal details of how this is accomplished
>>>>>>>> to the 802.11 specification.
>>>>>>>>>> 
>>>>>>>> a binary value), and the mapping of this User Priority
>>>>>>>>  to TID header value is another 802.11 detail, best 
>>>>>>>> left to the 802.11 specification.  For example: in the
>>>>>>>>  802.11 specification the TID field is specified to be 
>>>>>>>> 4 bits in the header.  The use of these 4 bits to carry
>>>>>>>> the User Priority information is an internal 
>>>>>>>> 802.11-2016 Clause 5.2.  This clause intentionally 
>>>>>>>> abstracts the exact details of 802..11’s internal 
>>>>>>>> operation, while describing specifically the behavior 
>>>>>>>> the Frame Control field 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 
>>>>>>>> value of 1, which specifies the use of QoS with a 
>>>>>>>> “Background” user priority.”
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thanks again.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> When responding, please keep the subject line 
>>>>>>>>>> intact and reply
>>>>>>>> to all
>>>>>>>>>> email addresses included in the To and CC lines. 
>>>>>>>>>> (Feel free to
>>>>>>>> cut this
>>>>>>>>>> The document, along with other ballot positions, 
>>>>>>>>>> can be found
>>>>>>>> here:
>>>>>>>>>> 
>>>>>>>>>> One point on this sentence, which I believe was 
>>>>>>>>>> also commented
>>>>>>>> in the TSV-ART
>>>>>>>>>> review (Thanks Jörg!):
>>>>>>>>>> 
>>>>>>>>>> sec 4.2: "The mapping to the 802.11 data service 
>>>>>>>>>> MUST use a 'priority' value of 1, which specifies 
>>>>>>>>>> the use of QoS with a 'Background' user priority." 
>>>>>>>>>> I don't think this should be a MUST requirement. I
>>>>>>>>>> assume the
>>>>>>>> assumption here
>>>>>>>>>> is that IP traffic is always some "random" data 
>>>>>>>>>> that is less
>>>>>>>> important than
>>>>>>>>>> other V2V communication. However, this is a generic
>>>>>>>>>> mapping
>>>>>>>> document and should
>>>>>>>>>> therefore probably not make such an assumption (or
>>>>>>>>>>  at least it
>>>>>>>> would need to be
>>>>>>>>>> spelled out).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> One editorial high level comment: I seams like all
>>>>>>>>>>  text that
>>>>>>>> was somehow deemed
>>>>>>>>>> as out fo scope for the main body of this document
>>>>>>>>>>  got stuffed
>>>>>>>> into the
>>>>>>>>>> appendix. Please consider removing what is really 
>>>>>>>>>> not needed
>>>>>>>> in this document
>>>>>>>>>> as these pages also take review and RFC Editor 
>>>>>>>>>> time,
>>>>>>>> especially as they seem to
>>>>>>>>>> nit: sec 4.5.2 s/in OCB mode.A  A future 
>>>>>>>>>> improvement/in OCB
>>>>>>>> mode. A future
>>>>>>>>>> improvement/
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> 
>>>>>>>>>> Best Regards
>>>>>>>>>> 
>>>>>>>>>> Nabil Benamar Associate Professor Department of 
>>>>>>>>>> Computer Sciences School of Technology Moulay 
>>>>>>>>>> Ismail University Meknes. Morocco
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 
>>>>>>>>> Best Regards
>>>>>>>>> 
>>>>>>>>> Nabil Benamar Associate Professor Department of 
>>>>>>>>> Computer Sciences School of Technology Moulay Ismail
>>>>>>>>>  University Meknes. Morocco
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________ its 
>>>>>>>> mailing list [email-masked] <mailto:[email-masked]> 
>>>>>>>> -- John Kenney Director and Sr. Principal Researcher 
>>>>>>>> Toyota InfoTech Labs 465 Bernardo Avenue Mountain View,
>>>>>>>> CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644
>>>>>>> _______________________________________________ its 
>>>>>>> mailing list [email-masked] 
>>>> _______________________________________________ its mailing 
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>> 
>> _______________________________________________ its mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
> 
>

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 16 Jul 2019 21:07:27 +0100

Hi Russ, Mirja,

I'm fine with this text.

Mirja, please let me know if it is OK for you so that I include this change
in the next version of the draft.

On Tue, Jul 16, 2019 at 8:42 PM Russ Housley <[email-masked]> wrote:

> Mirja:
>
> The safety messages defined in IEEE 1902.2 do not use IP, but you are
> right that this document should not have to change if such a thing were to
> be defined in the future.
>
> I suggest:
>
> > This would also be good and address my discuss. However, IP is not
> really a specific service and I could well imagine that in future there
> could also be a more critical service that is implemented over IP (for
> whatever reason). To leave this as generic as possible, which I think a
> mapping document should be, I would recommend to us SHOULD or no normative
> language at all.
> >
> > Mirja
> >
> >
> >
> to remember that IP-over-OCB will typically share public regulated spectrum
> >>>>> User Priority is typically described as a simple integer (not a
> binary value), and the mapping of this User Priority to TID header value is
> >>>>> “In the 802.11 header, the value of the Subtype sub-field in the
> Frame Control field 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').”
> >>>>>
> >>>>> could be replaced by:
> >>>>>
> >>>>>
> >>>>> “The mapping to the 802.11 data service MUST use a ‘priority’ value
> of 1, which specifies the use of QoS with a “Background” user priority.”
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks again.
> >>>>>
> >>>>>

-- 

Best Regards

Nabil Benamar
Associate Professor

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 16 Jul 2019 22:20:54 +0200

Hi everybody,

Yes, this text would work for me.

Thanks!
Mirja

> On 16. Jul 2019, at 22:07, Nabil Benamar <[email-masked]> wrote:
> 
> Hi Russ, Mirja,
> 
> 
> I'm fine with this text.
> 
> Mirja, please let me know if it is OK for you so that I include this change in the next version of the draft.
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Jul 2019 10:35:02 -0400

Mirja:

Rick Roy suggested that the  [IEEE-1609.2] reference was probably not the best one.  I suggest:

 traffic, including the ones listed in [ETSI-sec-archi].

Russ

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 17 Jul 2019 16:40:29 +0200

That is okay for me as well. As actually can judge the references here, so I’ll trust in your expertise. Thanks!

> On 17. Jul 2019, at 16:35, Russ Housley <[email-masked]> wrote:
> 
> 
> Mirja:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Jul 2019 16:49:23 +0200

>   traffic, including the ones listed in [ETSI-sec-archi].

Does this mean that my IP-RSU putting IPv6 on 802.11 Data headers (not 
QoS Data headers, no 'Background' user priority) is non conformant to 
this spec?

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Sat, 20 Jul 2019 13:56:04 +0200

Dear Alex, All,

I guess that on this aspect, we will need to agree that we disagree :-)

As accessing the ITS-G5 spectrum (so far) is still restricted by using the ETSI stack, and as the ETSI stack uses QoS mapping to the QoSheaders (the DCC and media-dependant Geonet specifications), then QoSheader are required to access the ITS-G5 spectrum in EU...I shall also mention (again..) that at that stage, accessing the ITS-G5 spectrum with 'pure' IP over OCB is not allowed for commercial usage, as for this to happen, two major aspects must be enforced:

1) a security framework is required 

2) a mechanism to enforce IP-over-OCB to respect the duty cycle 

Both of these are not available so far for IP-over-OCB…but I am not sure (and I guess other might have different perspective on this, in order to make this draft move on), is that such restrictions are ‘spectrum’ specific…, which is outside the scope of the IETF (as I understand it)…so, I would not see such lack of specification blocking the current draft, considering the fact that it includes a mention that regional/national restrictions could apply, which would need an additional specifications (at a later stage…).

So, to my perspective, it is not what is 'available' but what is 'required'…and this is pretty clear (and came straight from the ETSI ITS chairs...)..

Yet, I also think that from a global perspective, IP-over-OCB should not enforce using QoSHeaders, considering 

1) IP would provide the required priorization of channel access

2) the draft would indicate that this possibility is subject to national/regional regulations that could say it differently.

And one last thing: if you access ITS-G5 with nonQoSheader and other stations have QoS headers, then you will systematically loose !! That is just due to the fact that nonQoSheaders can access the channel only after an IDLE DIFS time...while nonQoSheader uses IDLE AIFS times, which for 3 queues out of 4 are shorter than the DIFS...(not mentioning the CW, which is also significantly shorter) So, I would say that using nonQoSHeader will lead to performance drop when competing with other ITS-G5/DSRC traffic on a same channel...(as most ITS-G5/DSRC traffic is broadcast, their CW will never increase (while yours might) and always be smaller than your NonQoSHeader profile).

My two cents,

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Tuesday 16 July 2019 21:53
To: Russ Housley
Cc: Nabil Benamar; Mirja Kuehlewind; IESG; its
Subject: Re: [ipwave] Mirja Kühlewind's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

Russ,

to express it better.

Alex

>> On Jul 16, 2019, at 4:36 AM, Alexandre Petrescu 

>> <[email-masked]> wrote:

>>>> On Jul 15, 2019, at 9:32 AM, Alexandre Petrescu 

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

>>>> I agree that the 2nd MUST was there before, and that a phrase 

>>>> of rationale was added.

>>>> The phrase of rationale motivates the 2nd MUST.  It is 

>>>> logical.

>>>>>> On Jul 12, 2019, at 8:32 AM, Alexandre Petrescu 

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

>>>>>> I disagree with the second MUST.  I will write a draft 

>>>>>> IPv6-over-OCB without QoS headers.

>>>>>>>> On Jul 10, 2019, at 7:40 PM, John Kenney 

>>>>>>>> <[email-masked] 

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

>>>>>>>> <[email-masked] 

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

>>>>>>>>> Actually, the text was written some time ago and 

>>>>>>>>> different views

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

>>>>>>>>> I think my point was slightly different. Dorothy 

>>>>>>>>> mainly advised

>>>>>>>> <[email-masked] 

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

>>>>>>>>>> You raised a very important point that was 

>>>>>>>>>> discussed

>>>>>>>>>> .  Suggest to simply state that the data is 

>>>>>>>>>> transmitted with

>>>>>>>>>> User Priority is typically described as a simple 

>>>>>>>>>> integer (not

>>>>>>>> specification of 802.11 and potentially subject to 

>>>>>>>> change..

>>>>>>>>>> Suggest using terminology from the MAC SAP in IEEE

>>>>>>>>>>  Std

>>>>>>>> required by the user.  For example, the following 

>>>>>>>> text:

>>>>>>>>>> “In the 802.11 header, the value of the Subtype 

>>>>>>>>>> sub-field in

>>>>>>>>>> “The mapping to the 802.11 data service MUST use a

>>>>>>>>>>  ‘priority’

>>>>>>>>>> On Tue, Jul 9, 2019 at 5:43 PM Mirja Kühlewind via

>>>>>>>>>>  Datatracker

>>>>>>>>>> Mirja Kühlewind has entered the following ballot 

>>>>>>>>>> position for 

>>>>>>>>>> have received less review and therefore have more 

>>>>>>>>>> nits.

its mailing list

[email-masked]

---

From: Jérôme Härri <[email-masked]>
Date: Sat, 20 Jul 2019 14:06:23 +0200

Dear All,

Sorry misspelling…

(…) That is just due to the fact that nonQoSheaders can access the channel only after an IDLE DIFS time...while QoSheader uses IDLE AIFS times, which for 3 queues out of 4 are shorter than the DIFS...(not mentioning the CW, which is also significantly shorter) So, I would say that using nonQoSHeader will lead to performance drop when competing with other ITS-G5/DSRC traffic on a same channel...(as most ITS-G5/DSRC traffic is broadcast, their CW will never increase (while yours might) and always be smaller than your NonQoSHeader profile).

Best Regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Tuesday 16 July 2019 21:53
To: Russ Housley
Cc: Nabil Benamar; Mirja Kuehlewind; IESG; its
Subject: Re: [ipwave] Mirja Kühlewind's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

Russ,

to express it better.

Alex

its mailing list

[email-masked]

---

From: Jérôme Härri <[email-masked]>
Date: Sat, 20 Jul 2019 14:24:39 +0200

Dear All,

I support John’s comment and would like to add three additional points:

1)      The ETSI (at least that I am aware) enforces a given duty cycle (a given % of channel access time) that a station SHALL not exceed. That is there to avoid starving competitions by one or more stations…and to give equal chances of different stations to access the channel…simply increasing the Mbps on the ITS spectrum is not a straightforward strategy as it could lead to exceed the duty cycle and such not be compliant to the requirements specified by the ECC (not even ETSI only).

2)      The target Mbps that is used by ITS-G5/OCB in automotive applications is a trade-off between capacity and reliability. As it has been recently showed in a paper by Sepulcre et al. Why 6 Mbps is Not (Always) the Optimum Data Rate for Beaconing in Vehicular Networks , https://ieeexplore.ieee.org/abstract/document/7906621), there is a strong link between increasing the data rate and the tx range and reliability. Again, via a series of simulation AND experimentations, indeed you can gain a bit up to maybe 18Mbps considering you would increase the Tx power accordingly, but moving to 54Mbps is not reachable in practice…(unless you use unicast and you are more or less the only one transmitting and you are in a (very) short distance with a perfect channel)..

3)      Finally, if there were no congestions, then people would not be seeking capacity in additional channels…(off-loading of CPM/MCM content in adjacent channels).. so, empirically speaking, it indicates that people expect a clear and present congestion in ITS-G5/DSRC (not even mentioning C-V2X competing maybe…) with all current and future applications and as such, a congestion control mechanism is critical J 

BR,

Jérôme   

From: its [mailto:[email-masked]] On Behalf Of John Kenney
Sent: Monday 15 July 2019 17:33
To: Alexandre Petrescu
Cc: Nabil Benamar; Russ Housley; Mirja Kuehlewind; IESG; its
Subject: Re: [ipwave] Mirja Kühlewind's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

Hi All:

I don’t want to be argumentative, but I believe automotive experts would disagree with this back-of-the-envelope analysis. Channel congestion is a real concern.  It can arise on channels carrying key safety services like collision avoidance (BSM/CAM/DENM), personal safety (for pedestrians, bicyclists and other vulnerable road users), platooning, cooperative perception, and many I2V services.  SAE and ETSI have taken concrete steps to standardize congestion control. IEEE 1609 and ETSI require use of QoS packets, because prioritizing channel access is an important tool to mitigate the effects of congestion on channels with mixed traffic. 

The interference range will typically go well beyond 1 km (I.e. 500 m radius).  Density studies have shown realistic densities of more than one thousand in an interference range, and that is what we plan for.

Interested parties are invited to participate in standardization related to scalability issues at SAE, IEEE 1609, and ETSI.

Best Regards,

John

On Mon, Jul 15, 2019 at 6:32 AM Alexandre Petrescu <[email-masked]> wrote:

Alex

>>>     0x86DD (IPv6).  The mapping to the 802..11 data service MUST use a
>>>>     <[email-masked] <mailto:[email-masked]..ac.ma>  <mailto:[email-masked]>> wrote:
>>>>     >
>>>>     > Hi Mirja,
>>>>     >
>>>>     <[email-masked] <mailto:[email-masked]..ac.ma>  <mailto:[email-masked]>> wrote:
>>>>     > >
>>>>     > > Hi Mirja,
>>>>     > >

-- 

John Kenney

Toyota InfoTech Labs

465 Bernardo Avenue

Mountain View, CA 94043

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Jul 2019 14:45:11 +0200

Le 20/07/2019 à 13:56, Jérôme Härri a écrit :
> As accessing the ITS-G5 spectrum (so far) is still restricted by using 
> the ETSI stack, and as the ETSI stack uses QoS mapping to the QoSheaders 
> (the DCC and media-dependant Geonet specifications), then QoSheader are 
> required to access the ITS-G5 spectrum in EU...I shall also mention 
> (again..) that at that stage, accessing the ITS-G5 spectrum with 'pure' 
> IP over OCB is not allowed for _commercial usage_, as for this to 
> happen, two major aspects must be enforced:
> 
> Both of these are not available so far for IP-over-OCB…but I am not sure 
> (and I guess other might have different perspective on this, in order to 
> make this draft move on), is that such restrictions are ‘spectrum’ 
> specific…, which is outside the scope of the IETF (as I understand 
> it)…so, I would not see such lack of specification blocking the current 
> draft, considering the fact that it includes a mention that 
> regional/national restrictions could apply, which would need an 
> additional specifications (at a later stage…).
> 
> So, to my perspective, it is not what is 'available' but what is 
> 'required'…and this is pretty clear (and came straight from the ETSI ITS 
> chairs...)..
> 
> 2) the draft would indicate that this possibility is subject to 
> national/regional regulations that could say it differently.
> 
> And one last thing: if you access ITS-G5 with nonQoSheader and other 
> stations have QoS headers, then you will systematically loose !! That is 
> just due to the fact that nonQoSheaders can access the channel only 
> after an IDLE DIFS time...while nonQoSheader uses IDLE AIFS times, which 
> for 3 queues out of 4 are shorter than the DIFS...(not mentioning the 
> CW, which is also significantly shorter) So, I would say that using 
> nonQoSHeader will lead to performance drop when competing with other 
> ITS-G5/DSRC traffic on a same channel...(as most ITS-G5/DSRC traffic is 
> broadcast, their CW will never increase (while yours might) and always 
> be smaller than your NonQoSHeader profile).
> 
> My two cents,
> 
> 
> BR,
> 
> Jérôme

Jérôme,

You express very well the points of view of the SDOs that make 
requirements.  I tend to agree with them, and as such, with you.

I have no doubt that these requirements are made for the best of all of 
us as road users, and for the best of interoperability of communication 
systems.

Alex

> Subject: Re: [ipwave] Mirja Kühlewind's Discuss on 
> draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)
> 
> Russ,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Jul 2019 15:03:46 +0200

Jérôme,

Here are some additional thoughts...

> 1) a security framework is required

The security framework may indeed be required.

But is it feasible?

Many of dployed RSUs I have been listening to dont implement it.  Only a 
minority does (one or two out of 20).

There are many CAMs, DENMs and SPAT-EMs on the road that are unsecured.
> 2) a mechanism to enforce IP-over-OCB to respect the duty cycle

One can try to implement QoS Data headers with IP.  And then, one should 
prove somehow that the QoS Data headers for IP do bring in some benefit 
compared to just Data headers.

I think there is no implementation and no preliminary prototype of 
implementation of IP with QoS Data headers on OCB.

> additional specifications (at a later stage…).

I am trying to understand what you say.

You say that security framework and duty cycle are not available for 
IP-over-OCB.  I agree with you.

Then you say that lack of spec - presumably spec of security and duty 
cycling - should not block the advancement of IP-over-OCB.  I also agree 
with you.

But this is not what I meant.

I meant this: there is no implementation of IPV6-over-OCB with QoS Data 
headers.  As such the advancement of the IP-over-OCB spec SHOULD NOT be 
pursued in this direction.

> 1) IP would provide the required priorization of channel access

Agreed.

> national/regional regulations that could say it differently.

No.

The national/regional regulations may stumble very hard when it comes to 
Internet.  Witness how GDPR makes that access to some website is simply 
blocked.

> be smaller than your NonQoSHeader profile).

I agree with you.  However, I do not fear the situation of 
systematically losing.

I trust more in the growth of channel capacity that will accomodate more 
as time goes by.  And so in an area whose size is defined by restricted 
power levels there would be enough space for all these IP and safety 
messages.

I fear more that QoS Data headers are put there below IP as a pretext, 
without demonstrating something guaranteed for the safety messages.

How would the benefits of an implementation of QoS Data headers below IP 
be demonstrated?  We tried with the tc command (that is in the IP 
fields, not in the 802.11 QoS Data fields), and iperf, and we could not 
demonstrate benefits of QoS: packets get lost despite QoS guarantees. 
Certainly, that is not 802.11 headers, but it is something to give an idea.

Alex