Subject: [ipwave] about the 'MUST' in priority

From: Nabil Benamar <[email-masked]>
Date: Wed, 10 Jul 2019 09:28:41 +0100

Hi IPwavers,

The AD (Mirja Kühlewind
<https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/#mirja-kuhlewind>)
is asking why we MUST in the following sentence:

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.

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

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 10 Jul 2019 10:53:44 +0200

Hi Nabil,

Well, I do not fully remember the details, but it might depend on where the OCB is being used. 

If you use it over the 10Mhz ITS-band 5.895-5.905Ghz currently used by CAM or BSM, then IP traffic MUST be lower than any non IP traffic (unless you send a BSM or a CAM/DENM, which is highly unlikely)…

Now, this being said, as even IP does not know what type of traffic is being Tx (could indeed by a CAM/DENM…, playing the devil’s advocate), we might not need to indicate anything here…say: L3 is not the right level to do such priorization…

Now the real issue is different: in ETSI, pure IP is ‘currently’ banned on the 30Mhz between 5.875-5.905 Mhz, as it does not support the security PKI (natively on geonet) and duty cycle enforcement guaranties (in the form of a congestion control/traffic shaping, also natively done via geonet)..even LTE-V2X is forced to used it...You can use IP, but it is wrapped up in a Geonet packet.  In other bands (in particular the ITS-G5-D (RLAN) or the ITS-G5-B (5.855Ghz-5.875Ghz), it is open to IP…And in the US, if I remember well, IP is also banded on the BSM band.  

I do not want to enter this debate...again, but then assuming that pure IP OCB traffic goes on other bands, then such priority provision does not make sense anymore (why lower priority as there is only IP). And if IP is allowed in these bands (for instance, once a decent security framework will have been devised), then we also cannot enforce such low priority, as it is also fully possible that IP-OCB transmits urgent safety-related data (as shown for example by Alex on its Highly Automated Driving demonstration J)…So, such provision also does not make sense (a hard coded solution is not good in this case)..

The problem is largely bigger than IETF…as I said: if the priority being 1 (background traffic) is to put IP with the worst priority on a IP/non-IP shared band, an IETF document is not the right place to do so. It is rather ETSI/IEEE/SAE which needs to decide on the mapping between TC (IP or non IP) to the AC of the OCB devices...and this regardless of the band or protocol stack..

Would any of the other co-authors or IPWAVer have another view on this?

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Nabil Benamar
Sent: Wednesday 10 July 2019 10:29
To: [email-masked]; [email-masked]
Subject: [ipwave] about the 'MUST' in priority

Hi IPwavers,

The AD ( <https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/#mirja-kuhlewind> Mirja Kühlewind) is asking why we MUST in the following sentence:

 

Best regards

Nabil Benamar

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

نبيل بنعمرو

---

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

Le 10/07/2019 à 10:53, Jérôme Härri a écrit :
> If you use it over the 10Mhz ITS-band 5.895-5.905Ghz currently used by 
> CAM or BSM, then IP traffic MUST be lower than any non IP traffic 
> (unless you send a BSM or a CAM/DENM, which is highly unlikely)…

Why IP traffic MUST be lower?  I do not agree with that.  We send IP 
traffic on a distinct channel; we even send it on same channel as non-IP 
CAM messages: they live together well.  They are distinguished by EtherType.

Again - why IP must be lower?

Alex

> 
> Now, this being said, as even IP does not know what type of traffic is 
> being Tx (could indeed by a CAM/DENM…, playing the devil’s advocate), we 
> might not need to indicate anything here…say: L3 is not the right level 
> to do such priorization…
> 
> Now the real issue is different: in ETSI, pure IP is ‘currently’ banned 
> on the 30Mhz between 5.875-5.905 Mhz, as it does not support the 
> security PKI (natively on geonet) and duty cycle enforcement guaranties 
> (in the form of a congestion control/traffic shaping, also natively done 
> via geonet)..even LTE-V2X is forced to used it...You can use IP, but it 
> is wrapped up in a Geonet packet.  In other bands (in particular the 
> ITS-G5-D (RLAN) or the ITS-G5-B (5.855Ghz-5.875Ghz), it is open to 
> IP…And in the US, if I remember well, IP is also banded on the BSM band.
> 
> I do not want to enter this debate...again, but then assuming that pure 
> IP OCB traffic goes on other bands, then such priority provision does 
> not make sense anymore (why lower priority as there is only IP). And if 
> IP is allowed in these bands (for instance, once a decent security 
> framework will have been devised), then we also cannot enforce such low 
> priority, as it is also fully possible that IP-OCB transmits urgent 
> safety-related data (as shown for example by Alex on its Highly 
> Automated Driving demonstration J)…So, such provision also does not make 
> sense (a hard coded solution is not good in this case)..
> 
> The problem is largely bigger than IETF…as I said: if the priority being 
> 1 (background traffic) is to put IP with the worst priority on a 
> IP/non-IP shared band, an IETF document is not the right place to do so. 
> It is rather ETSI/IEEE/SAE which needs to decide on the mapping between 
> TC (IP or non IP) to the AC of the OCB devices...and this regardless of 
> the band or protocol stack..
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Nabil Benamar
> *Sent:* Wednesday 10 July 2019 10:29
> *To:* [email-masked]; [email-masked]
> *Subject:* [ipwave] about the 'MUST' in priority
> 
> Hi IPwavers,
> 
> The AD (Mirja Kühlewind 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

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

> Would any of the other co-authors or IPWAVer have another view on this?

My view on this is this: IP must be sent on any channel of the 5.9GHz band.

The only mandatory thing is the 802.11 DAta headers.  The alternative - 
it is an alternative - are the QoS Data headers.

Alex

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 10 Jul 2019 10:11:29 +0100

Thanks, Jerome, Alex

Can we make it a 'MAY' in the text?

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

On Wed, Jul 10, 2019 at 10:09 AM Alexandre Petrescu <
[email-masked]> wrote:

> > <
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/#mirja-kuhlewind>)
>

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 10 Jul 2019 11:19:57 +0200

Hi Alex,

Technology neutrality should be the norm..I agree. But at the end, rules for accessing spectrum is not the business of IETF. The ITU (and ETSI in EU) fix rules...if IP can fulfill these rules, then I fully agree with you...it should not be banned. 

However, as of today, IP does not comply with two of these rules (EU Security KPI and the duty cycle). As discussed in the past, it is the duty of IPWAVE to define an RFC that shows that these two rules can be fulfilled. I think this draft is a first step but does not provide concrete solutions..(that will be the role of other draft/RFC, as I understood)...we need to work on that...

Yet, as mentioned, I also agree that 'hard coding' the lowest priority in such OCB draft is also wrong. We should not mention anything...either it is the application fixing it, or it is the access layer fixing it...IP priority (as for non IP) should be decided by the application...not changed by IP (breach of OSI layering actually).

BR,

Jérôme 

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Wednesday 10 July 2019 11:10
To: Jérôme Härri; 'Nabil Benamar'; [email-masked]; [email-masked]
Subject: Re: [ipwave] about the 'MUST' in priority

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 10 Jul 2019 11:46:15 +0200

It is complicated….even a MAY would be wrong…why do we need to indicate  anything here? 

BR,

Jérôme 

From: Nabil Benamar [mailto:[email-masked]] 
Sent: Wednesday 10 July 2019 11:11
To: Alexandre Petrescu
Cc: Jérôme Härri; [email-masked]; [email-masked]
Subject: Re: [ipwave] about the 'MUST' in priority

Thanks, Jerome, Alex

 

Best regards

Nabil Benamar

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

نبيل بنعمرو

 

On Wed, Jul 10, 2019 at 10:09 AM Alexandre Petrescu <[email-masked]> wrote:

Alex

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 10 Jul 2019 10:52:02 +0100

Yes, it's another option!

If this is out of scope in the IETF, so maybe we need to reformulate or to
remove.

suggestions?

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

On Wed, Jul 10, 2019 at 10:46 AM Jérôme Härri <[email-masked]>
wrote:

> *From:* Nabil Benamar [mailto:[email-masked]]
> *Sent:* Wednesday 10 July 2019 11:11
> *To:* Alexandre Petrescu
> *Cc:* Jérôme Härri; [email-masked]; [email-masked]
> *Subject:* Re: [ipwave] about the 'MUST' in priority
>
>
>
> Thanks, Jerome, Alex
>
>
>
>
>

---

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

I would suggest removing this sentence since it was also raised by Pascal
in previous review round.
Avoiding this debate around priority is better.

Comments?

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 10 Jul 2019 15:03:53 +0200

there was a need expressed in the past by Pascal, asking what does this 
document do?

An IP-over-foo document looks closely at what IP fields are and what foo 
fields are.  QoS is one of them.

Le 10/07/2019 à 11:46, Jérôme Härri a écrit :
> *From:*Nabil Benamar [mailto:[email-masked]]
> On Wed, Jul 10, 2019 at 10:09 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>      > Well, I do not fully remember the details, but it might depend on
>     where
>      > the OCB is being used.
>      >
>      > *From:*its [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Nabil Benamar
>      > *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>