Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt

From: Dorothy Stanley <[email-masked]>
Date: Tue, 4 Dec 2018 07:04:39 -0800

Hello Alexandre, all,

I am sharing the following information from John Kenny (
[email-masked]), who is actively involved in 802.11p
implementation and deployments:
"OCB can use unicast in the same way as other flavors of 802.11 (
individually addressed 802.11 MAC PDU that is ACKed using 802.11 procedures
).
I find this is a common misunderstanding (indeed, I am in a meeting right
now where this very point came up about 20 minutes ago).
Probably the confusion is partly due to the fact that a great deal of DSRC
attention is focused on the broadcast Basic Safety Message.
Some people think that DSRC is only BSMs, or only broadcast messages. But,
there are some important unicast applications as well."

Thus a change is needed in 4.7, either delete the second sentence or modify
to reflect that unicast is acknowledged.:

The Neighbor Discovery protocol (ND) [RFC4861] is used over
   802.11-OCB links.  Due to lack of link-layer acknowledgements in
   802.11-OCB for both unicast and multicast, we can expect higher
   unicast loss than for 802.11 BSS.  The ND retransmissions are
   supposed to handle loss of unicast and/or multicast just as it does
   for other link types.

Thanks,

Dorothy

----------------------
Dorothy Stanley
IEEE 802.11 WG Chair, [email-masked]
Hewlett Packard Enterprise
[email-masked] <[email-masked]>
[email-masked]
+1 630-363-1389 <630-363-1389>

On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu <
[email-masked]> wrote:

> Hi IPWAVErs,
>
> Following the discussion during presentation of the IPv6/OCB slides by
> Nabil during IPWAVE WG meeting, I have updated the IPv6/OCB draft.
>
> This is the ChangeLog:
>
> - filled in the section titled "Pseudonym Handling";
> - removed a 'MAY NOT' phrase about possibility of having other
>    prefix than the LL on the link between cars;
> - shortened and improved the paragraph about Mobile IPv6, now with
>    DNAv6;
> - improved the ND text about ND retransmissions with relationship to
>    packet loss;
> - changed the title of an appendix from 'EPD' to 'Protocol Layering';
> - improved the 'Aspects introduced by OCB' appendix with a few phrases
>    about the channel use and references.
>
> This fixes all issues about ND and pseudonym handling.
>
> Alex
>
> -------- Message transféré --------
> Sujet : New Version Notification for
> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
> Date : Mon, 19 Nov 2018 10:01:52 -0800
> De : [email-masked]
> Pour : Jerome Haerri <[email-masked]>, [email-masked],
> Jerome Haerri <[email-masked]>, Alexandre Petrescu
> <[email-masked]>, Alexandre Petrescu
> <[email-masked]>, Nabil Benamar <[email-masked]>,
> Thierry Ernst <[email-masked]>, Jong-Hyouk Lee
> <[email-masked]>
>
>
> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
> has been successfully submitted by Alexandre Petrescu and posted to the
> IETF repository.
>
> Name:           draft-ietf-ipwave-ipv6-over-80211ocb
> Revision:       31
> Title:          Transmission of IPv6 Packets over IEEE 802.11 Networks
> operating
> in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
> Document date:  2018-11-19
> Group:          ipwave
> Pages:          41
> URL:
>
> https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-31
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-31
>
> Abstract:
>     In order to transmit IPv6 packets on IEEE 802.11 networks running
>     outside the context of a basic service set (OCB, earlier "802.11p")
>     there is a need to define a few parameters such as the supported
>     Maximum Transmission Unit size on the 802.11-OCB link, the header
>     format preceding the IPv6 header, the Type value within it, and
>     others.  This document describes these parameters for IPv6 and IEEE
>     802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
>     similarly to other known 802.11 and Ethernet layers - by using an
>     Ethernet Adaptation Layer.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 16:11:35 +0100

Le 04/12/2018 à 16:04, Dorothy Stanley a écrit :
> [email-masked] <mailto:[email-masked]>), who is
> actively involved in 802.11p implementation and deployments: "OCB can
> use unicast in the same way as other flavors of 802.11 ( individually
> addressed 802.11 MAC PDU that is ACKed using 802.11 procedures ). I
> find this is a common misunderstanding (indeed, I am in a meeting
> right now where this very point came up about 20 minutes ago).
> Probably the confusion is partly due to the fact that a great deal of
> DSRC attention is focused on the broadcast Basic Safety Message. Some
> people think that DSRC is only BSMs, or only broadcast messages. But,
> Thus a change is needed in 4.7, either delete the second sentence or
>  modify to reflect that unicast is acknowledged.

I propose

NEW:
> 802.11-OCB, we can expect higher packet loss than for 802.11 BSS. The
> ND retransmissions are supposed to handle loss of IP unicast and/or 
> IP multicast just as it does for other link types.

(remark disappeared 'unicast' and 'multicast' from 2nd phrase, and added 
'IP' in front of unicast and multicast in 3rd phrase).

> supposed to handle loss of unicast and/or multicast just as it does 

Would this be agreed by John Kenney.

Alex

> 
> Thanks,
> 
> Dorothy
> 
> ---------------------- Dorothy Stanley IEEE 802.11 WG Chair, 
> [email-masked] <mailto:[email-masked]> Hewlett Packard 
> Enterprise [email-masked] 
> <mailto:[email-masked]> [email-masked] 
> <mailto:[email-masked]> +1 630-363-1389 <tel:630-363-1389>
> 
> 
> 
> On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
>  wrote:
> 
> Hi IPWAVErs,
> 
> Following the discussion during presentation of the IPv6/OCB slides 
> by Nabil during IPWAVE WG meeting, I have updated the IPv6/OCB 
> draft.
> 
> This is the ChangeLog:
> 
> - filled in the section titled "Pseudonym Handling"; - removed a 'MAY
> NOT' phrase about possibility of having other prefix than the LL on
> the link between cars; - shortened and improved the paragraph about
> Mobile IPv6, now with DNAv6; - improved the ND text about ND 
> retransmissions with relationship to packet loss; - changed the title
> of an appendix from 'EPD' to 'Protocol Layering'; - improved the
> 'Aspects introduced by OCB' appendix with a few phrases about the
> channel use and references.
> 
> -------- Message transféré -------- Sujet : New Version Notification
>  for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt Date : Mon, 19 Nov 
> 2018 10:01:52 -0800 De : [email-masked] 
> <mailto:[email-masked]> Pour : Jerome Haerri 
> <[email-masked] <mailto:[email-masked]>>, 
> [email-masked] <mailto:[email-masked]>, Jerome Haerri
> <[email-masked] <mailto:[email-masked]>>, 
> Alexandre Petrescu <[email-masked] 
> <mailto:[email-masked]>>, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>, Nabil
> Benamar <[email-masked] <mailto:[email-masked]>>,
> Thierry Ernst <[email-masked]
> <mailto:[email-masked]>>, Jong-Hyouk Lee
> <[email-masked] <mailto:[email-masked]>>
> 
> 
> A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-31.txt has
> been successfully submitted by Alexandre Petrescu and posted to the
> IETF repository.
> 
> Name:           draft-ietf-ipwave-ipv6-over-80211ocb Revision: 31 
> Title:          Transmission of IPv6 Packets over IEEE 802.11 
> Networks operating in mode Outside the Context of a Basic Service Set
> (IPv6-over-80211-OCB) Document date:  2018-11-19 Group: ipwave Pages:
> 41 URL: 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-31
Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks
> running outside the context of a basic service set (OCB, earlier 
> "802.11p") there is a need to define a few parameters such as the 
> supported Maximum Transmission Unit size on the 802.11-OCB link, the
>  header format preceding the IPv6 header, the Type value within it, 
> and others.  This document describes these parameters for IPv6 and 
> IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 
> 802.11-OCB similarly to other known 802.11 and Ethernet layers - by 
> using an Ethernet Adaptation Layer.
> 
> 
> 
> 
> submission until the htmlized version and diff are available at 
> tools.ietf.org <http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> _______________________________________________ its mailing list 
> [email-masked] <mailto:[email-masked]>

---

From: Dorothy Stanley <[email-masked]>
Date: Tue, 4 Dec 2018 07:36:51 -0800

The statement below is not correct:
"   Due to lack of link-layer acknowledgements in
802.11-OCB, we can expect higher packet loss than for 802.11 BSS."

Link Layer acknowledgements are present for unicast traffic in 802.11 and
802.11 OCB mode.

Dorothy

----------------------
Dorothy Stanley

---

From: John Kenney <[email-masked]>
Date: Tue, 4 Dec 2018 07:37:56 -0800

Hi,

Caveat: I know nothing about Neighbor Discovery protocol.

I see this in the proposed new text:

Due to lack of link-layer acknowledgements in 802.11-OCB, we can expect
higher packet loss than for 802.11 BSS.

I don't understand why it is expected that OCB has a lack of link-layer
acknowledgments.  OCB uses link layer acks the same way as 802.11 BSS uses
them.   If I send a unicast 802.11 packet outside the context of a BSS, I
expect an 802.11 ACK. If I don't get the 802.11 ACK, I go through
exponential backoff and retransmit.  Just like normal 802.11.  Maybe I'm
missing something.

Best Regards,
John

-- 
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: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 16:50:27 +0100

> Caveat: I know nothing about Neighbor Discovery protocol.

I can tell how it works: you send a request to learn the MAC address of 
a computer keyed on its IP address.  And the computer responds.  For it 
to work there are many needs of understandings between MAC and IP.

Another thing that ND does is that it times out its entries in its data 
structures if some reply is expected for too long.  So one can expect 
reliability added by ND, where OCB misses it.

> Due to lack of link-layer acknowledgements in 802.11-OCB, we can 
> expect higher packet loss than for 802.11 BSS.
> 
> 
> I don't understand why it is expected that OCB has a lack of 
> link-layer acknowledgments.  OCB uses link layer acks the same way
> as 802.11 BSS uses them.   If I send a unicast 802.11 packet outside
> the context of a BSS, I expect an 802.11 ACK. If I don't get the
> 802.11 ACK, I go through exponential backoff and retransmit.  Just
> like normal 802.11.  Maybe I'm missing something.

John,

In some implementations I have seen there are indeed link-layer acks in
OCB mode (notably _some_ Road-Side Units, not all).

In other implementations (notably in some V2V communications without
RSU, not all) there are no link-layer acks in OCB mode.

Packet dumps available upon request.

The paragraph you are confronted with is a suggestion from 6MAN WG,
which does have a certain level of authority to consider, before
modifying any of their text.

Given that, would it be sufficient to not think about link-layer acks at
all.

I propose this text:
NEW:
> 802.11-OCB links.  Due to lack of association operations in 

(remark 'lack of association operations' instead of 'lack of link-layer 
acks')

> supposed to handle loss of unicast and/or multicast just as it does

Do you agree with this text?

Alex

> 
> Best Regards, John
> 
> 
> On Tue, Dec 4, 2018 at 7:11 AM Alexandre Petrescu 
>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] 
> <mailto:[email-masked]>>), who is
>> actively involved in 802.11p implementation and deployments: "OCB 
>> can use unicast in the same way as other flavors of 802.11 ( 
>> individually addressed 802.11 MAC PDU that is ACKed using 802.11 
>> procedures ). I find this is a common misunderstanding (indeed, I 
>> am in a meeting right now where this very point came up about 20 
>> minutes ago). Probably the confusion is partly due to the fact
>> that a great deal of DSRC attention is focused on the broadcast
>> Basic Safety Message. Some people think that DSRC is only BSMs, or
>> only broadcast messages. But, there are some important unicast 
>> applications as well."
>> 
>> Thus a change is needed in 4.7, either delete the second sentence 
>> or modify to reflect that unicast is acknowledged.
> 
> I propose
> 
> NEW:
>> 802.11-OCB, we can expect higher packet loss than for 802.11 BSS. 
>> The ND retransmissions are supposed to handle loss of IP unicast 
>> and/or IP multicast just as it does for other link types.
> 
> (remark disappeared 'unicast' and 'multicast' from 2nd phrase, and 
> added 'IP' in front of unicast and multicast in 3rd phrase).
> 
> OLD:
>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>> Hewlett 
> Packard
>> Enterprise [email-masked] <mailto:[email-masked]>
>>  <mailto:[email-masked]
> <mailto:[email-masked]>> [email-masked] 
> <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>
> +1 630-363-1389 <tel:630-363-1389>
>> 
>> 
>> 
>> <[email-masked]
> <mailto:[email-masked]> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>> wrote:
>> 
>> Hi IPWAVErs,
>> 
>> - filled in the section titled "Pseudonym Handling"; - removed a 
>> 'MAY NOT' phrase about possibility of having other prefix than the 
>> LL on the link between cars; - shortened and improved the
>> paragraph about Mobile IPv6, now with DNAv6; - improved the ND text
>> about ND retransmissions with relationship to packet loss; -
>> changed the title of an appendix from 'EPD' to 'Protocol Layering';
>> - improved the 'Aspects introduced by OCB' appendix with a few
>> phrases about the channel use and references.
>> 
>> -------- Message transféré -------- Sujet : New Version 
>> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt Date
>> : Mon, 19 Nov 2018 10:01:52 -0800 De : [email-masked]
> <mailto:[email-masked]>
>> <mailto:[email-masked]
> <mailto:[email-masked]>> Pour : Jerome Haerri
>> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>,
>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>, 
> Jerome Haerri
>> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>,
> <mailto:[email-masked]>
>> <mailto:[email-masked]
> <mailto:[email-masked]>>>, Alexandre Petrescu
>> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] 
> <mailto:[email-masked]>>>, Nabil
>> Benamar <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>,
> <mailto:[email-masked]>
>> <mailto:[email-masked]
> <mailto:[email-masked]>>>, Jong-Hyouk Lee
>> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
>> 
>> 
>> has been successfully submitted by Alexandre Petrescu and posted
>> to the IETF repository.
>> 
>> Networks operating in mode Outside the Context of a Basic Service 
>> Set (IPv6-over-80211-OCB) Document date:  2018-11-19 Group: ipwave 
>> Pages: 41 URL:
>> 
>> supported Maximum Transmission Unit size on the 802.11-OCB link, 
>> the header format preceding the IPv6 header, the Type value within 
>> it, and others.  This document describes these parameters for IPv6 
>> and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 
>> tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>.
>> 
>> The IETF Secretariat
>> 
>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
> -- John Kenney Director and Principal Researcher Toyota 
> InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 
> 94043 Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 5 Dec 2018 03:09:54 +0100

Hi All,

I support John’s comment. ITS-G5/DSRC/OCB can fully do unicast with acks. It is the application that chose not to use this but rather broadcast. And even considering broadcast, I do not think we have higher packet losses. Just that we do not retransmit, as it is broadcast. Maybe we should mention reduced ‘application-layer reliability’ so something in that direction..

BR,

Jérôme 

From: its [mailto:[email-masked]] On Behalf Of John Kenney
Sent: Tuesday 04 December 2018 16:38
To: Alexandre Petrescu
Cc: its; Dorothy Stanley
Subject: Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt

Hi,

Due to lack of link-layer acknowledgements in 802.11-OCB, we can expect higher packet loss than for 802.11 BSS. 

I don't understand why it is expected that OCB has a lack of link-layer acknowledgments.  OCB uses link layer acks the same way as 802.11 BSS uses them.   If I send a unicast 802.11 packet outside the context of a BSS, I expect an 802.11 ACK. If I don't get the 802.11 ACK, I go through exponential backoff and retransmit.  Just like normal 802.11.  Maybe I'm missing something.

Best Regards,

John

On Tue, Dec 4, 2018 at 7:11 AM Alexandre Petrescu <[email-masked]> wrote:

I propose

Alex

> <[email-masked] <mailto:[email-masked] <mailto:Jerome.Haerri@eurecom..fr> >>, 
> <[email-masked] <mailto:[email-masked] <mailto:jerome.haerri@eurecom..fr> >>, 

 

-- 

John Kenney

465 Bernardo Avenue

Mountain View, CA 94043

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Dec 2018 11:51:52 +0100

John, Jérôme :  you seem to be agreeing.

So, how about this text proposal?

> supposed to handle loss of unicast and/or multicast just as it does 
I will not modify this text until I dont have agreements and from you 
and from a representative of 6MAN WG.  It's a text that has been crafted 
in fine detail.

Alex

Le 05/12/2018 à 03:09, Jérôme Härri a écrit :
> Hi All,
> 
> I support John’s comment. ITS-G5/DSRC/OCB can fully do unicast with 
> acks. It is the application that chose not to use this but rather 
> broadcast. And even considering broadcast, I do not think we have 
> higher packet losses. Just that we do not retransmit, as it is 
> broadcast. Maybe we should mention reduced ‘application-layer 
> reliability’ so something in that direction..
> 
> 
> BR,
> 
> Jérôme
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *John Kenney 
> *Sent:* Tuesday 04 December 2018 16:38 *To:* Alexandre Petrescu
> *Cc:* its; Dorothy Stanley *Subject:* Re: [ipwave] Fwd: New Version 
> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt
> 
> Hi,
> 
> <mailto:Jerome.Haerri@eurecom..fr>>>,
> <mailto:jerome.haerri@eurecom..fr>>>,

---

From: Dorothy Stanley <[email-masked]>
Date: Wed, 5 Dec 2018 06:24:20 -0800

Hello Alexandre,

The sentence " Due to lack of association operations in
802.11-OCB, we can expect higher packet loss than for 802.11 BSS."

is not correct.  The lack of acknowledgements for broadcast/multicast
traffic
is the same in OCB and BSS operation. The presence of acknowledgements for
unicast trafic is the same in OCB and BSS operation.
The lack of asssociation operation is irrelevant.

If the intent is to say that unacknowledged broadcast traffic is heavily
used in DSRC applications, then just say that.

I suggest deleting the current sentence.

Dorothy

----------------------
Dorothy Stanley

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Dec 2018 16:13:29 +0100

Hello Dorothy,

I thus suggest the following text.  Do you agree with this text?

NEW:
 > 802.11-OCB links.

Alex

-------------------------ignore-------------------------------------------
Because:
Yous suggest one might mention DSRC apps rarely rely on Acks: I think 
it's hard to talk about DSRC applications in a network-layer document; 
but I tend to agree with you about the presence of Acks in OCB 
implementations, some times (not always); for the broadcast/multicast 
term: I find the term ambiguous: IPv6 does not know about 'broadcast' at 
all (and that's an IPv6-over-WiFi matter, not OCB in particular).

Le 05/12/2018 à 15:24, Dorothy Stanley a écrit :
> Hello Alexandre,
> 
> The sentence " Due to lack of association operations in 802.11-OCB,
> we can expect higher packet loss than for 802.11 BSS."
> 
>  traffic is the same in OCB and BSS operation. The presence of
> acknowledgements for unicast trafic is the same in OCB and BSS
> operation. The lack of asssociation operation is irrelevant.
> 
> If the intent is to say that unacknowledged broadcast traffic is
> heavily used in DSRC applications, then just say that.
> 
> On Wed, Dec 5, 2018 at 2:52 AM Alexandre Petrescu 
> (remark 'lack of association operations' instead of 'lack of
> link-layer acks')
> 
> OLD:
>> supposed to handle loss of unicast and/or multicast just as it
>> does for other link types.
> I will not modify this text until I dont have agreements and from
> you and from a representative of 6MAN WG.  It's a text that has been 
> crafted in fine detail.
> 
> Alex
> 
>> I support John’s comment. ITS-G5/DSRC/OCB can fully do unicast
>> with acks. It is the application that chose not to use this but
>> rather broadcast. And even considering broadcast, I do not think we
>> have higher packet losses. Just that we do not retransmit, as it
>> is broadcast. Maybe we should mention reduced ‘application-layer 
>> *From:*its [mailto:[email-masked]
> <mailto:[email-masked]>] *On Behalf Of *John Kenney
>> *Cc:* its; Dorothy Stanley *Subject:* Re: [ipwave] Fwd: New
>> Version Notification for
>> as 802.11 BSS uses them.   If I send a unicast 802.11 packet
>> outside the context of a BSS, I expect an 802.11 ACK. If I don't
>> get the 802.11 ACK, I go through exponential backoff and
>> retransmit.  Just like normal 802.11.  Maybe I'm missing
>> something.
>> 
>> Best Regards,
>> 
>> John
>> 
> <mailto:[email-masked]>>
>> <mailto:[email-masked]> 
> <mailto:[email-masked]>>>), who is
>>> actively involved in 802.11p implementation and deployments:
>>> "OCB can use unicast in the same way as other flavors of 802.11
>>> ( individually addressed 802.11 MAC PDU that is ACKed using
>>> 802.11 procedures ). I find this is a common misunderstanding
>>> (indeed, I am in a meeting right now where this very point came
>>> up about 20 minutes ago). Probably the confusion is partly due to
>>> the fact that a great deal of DSRC attention is focused on the
>>> broadcast Basic Safety Message. Some people think that DSRC is
>>> only BSMs, or only broadcast messages. But, there are some
>>> important unicast applications as well."
>>> 
>>> Thus a change is needed in 4.7, either delete the second
>>> sentence or modify to reflect that unicast is acknowledged.
>> 
>> I propose
>> 
>> NEW:
>>> 802.11-OCB, we can expect higher packet loss than for 802.11
>>> BSS. The ND retransmissions are supposed to handle loss of IP
>>> unicast and/or IP multicast just as it does for other link
>>> types.
>> 
>>> supposed to handle loss of unicast and/or multicast just as it
>>> does for other link types.
>> 
> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> Hewlett
>> Packard
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]>
> <mailto:[email-masked]>>> [email-masked] 
>>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>
>>> wrote:
>>> 
>>> Hi IPWAVErs,
>>> 
>>> Following the discussion during presentation of the IPv6/OCB
>>> slides by Nabil during IPWAVE WG meeting, I have updated the
>>> IPv6/OCB draft.
>>> 
>>> This is the ChangeLog:
>>> 
>>> 'MAY NOT' phrase about possibility of having other prefix than
>>> the LL on the link between cars; - shortened and improved the 
>>> paragraph about Mobile IPv6, now with DNAv6; - improved the ND
>>> text about ND retransmissions with relationship to packet loss;
>>> - changed the title of an appendix from 'EPD' to 'Protocol
>>> Layering'; - improved the 'Aspects introduced by OCB' appendix
>>> with a few phrases about the channel use and references.
>>> 
>>> Date : Mon, 19 Nov 2018 10:01:52 -0800 De :
>>> [email-masked]
>> <mailto:[email-masked]>>
> <mailto:[email-masked]>>> Pour : Jerome Haerri
> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]> 
>> <mailto:Jerome.Haerri@eurecom.
>> <mailto:Jerome.Haerri@eurecom.>.fr>>>,
> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>,
>> Jerome Haerri
> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]> 
>> <mailto:jerome.haerri@eurecom.
>> <mailto:jerome.haerri@eurecom.>.fr>>>,
>> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>, Alexandre Petrescu
> <mailto:[email-masked]>>
>> <mailto:[email-masked]> 
> <mailto:[email-masked]>>>>, Nabil
>>> Benamar <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>,
>> <mailto:[email-masked] <mailto:[email-masked]>>
>>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>>>>, Jong-Hyouk Lee
> <mailto:[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
>>> 
>>> 
>>> A new version of I-D,
>>> draft-ietf-ipwave-ipv6-over-80211ocb-31.txt has been successfully
>>> submitted by Alexandre Petrescu and posted to the IETF
>>> repository.
>>> 
>>> Name:           draft-ietf-ipwave-ipv6-over-80211ocb Revision:
>>> 31 Title:          Transmission of IPv6 Packets over IEEE 802.11 
>>> Networks operating in mode Outside the Context of a Basic
>>> Service Set (IPv6-over-80211-OCB) Document date:  2018-11-19
>>> Group: ipwave Pages: 41 URL:
>>> 
>> 
>>> "802.11p") there is a need to define a few parameters such as
>>> the supported Maximum Transmission Unit size on the 802.11-OCB
>>> link, the header format preceding the IPv6 header, the Type value
>>> within it, and others.  This document describes these parameters
>>> for IPv6 and IEEE 802.11-OCB networks; it portrays the layering
>>> of IPv6 on 802.11-OCB similarly to other known 802.11 and
>>> Ethernet layers - by using an Ethernet Adaptation Layer.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time
>>> of submission until the htmlized version and diff are available
>>> at tools.ietf.org <http://tools.ietf.org>
>>> <http://tools.ietf.org>
> <http://tools.ietf.org>.
>>> 
>>> The IETF Secretariat
>>> 
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 08:40:26 +1300

Alexandre,

Now I am totally confused. I got into this topic because the earlier
text in draft-ietf-ipwave-ipv6-over-80211ocb seemed to make it clear
that OCB was significantly less reliable than BSS for the delivery of
multicast packets. If that is true, ND (and presumably DAD) will work
significantly less reliably and quickly for OCB. Is that true or not?
If it's true, surely it needs to be documented.

I also just discovered this draft:
https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems

It says nothing about OCB. Perhaps it should. Do the 802 mitigations
for multicast unreliability that are described there also apply to OCB?

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 08:49:14 +1300

Alexandre,

Regards
   Brian

---

From: Dorothy Stanley <[email-masked]>
Date: Wed, 5 Dec 2018 12:41:38 -0800

Alexandre,

I am fine with the proposed new text.

Dorothy

----------------------
Dorothy Stanley

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 16:02:42 +1300

Yes, that helps, thanks.

Regards
   Brian Carpenter

On 2018-12-06 14:32, Dick Roy wrote:
> OCB operation simply means no time sync, no authentication, no association.
> None of these impact operation after the initial setup (aka "joining a
> BSS").  What makes OCB operation trickier is that it is the "mode of
> operation" in rapidly varying RF environments in the ITS space.  Put another
> way, allow OCB operation in 5.9GHz along side standard ISM operation in
> 5.4GHz (allowing/using WiFi direct if you prefer) in an office environment
> and there will no appreciable difference in ND performance between the two
> systems.  
> 
> Hope this helps.
> 
> RR
> 
> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, December 5, 2018 11:49 AM
> To: Alexandre Petrescu; Dorothy Stanley
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; John Kenney;
> lorenzo=[email-masked]
> Subject: Re: [ipwave] ND an link-layer acks - text
> 
> Alexandre,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 08:39:04 +0100

Why dont you agree with 'is used'?

Le 06/12/2018 à 02:21, Dick Roy a écrit :
> I’d suggest:
> 
> “The Neighbor Discovery protocol (ND) [RFC4861] can be used over IEEE 
> 802.11-OCB links.”
> 
> ------------------------------------------------------------------------
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Dorothy Stanley
> *Sent:* Wednesday, December 5, 2018 12:42 PM
> *To:* Alexandre Petrescu
> *Cc:* [email-masked]; [email-masked]; [email-masked]; John 
> Kenney; lorenzo=[email-masked]; [email-masked]
> *Subject:* Re: [ipwave] ND an link-layer acks - text
> 
> Alexandre,
> 
> IEEE 802.11 WG Chair, [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> On Wed, Dec 5, 2018 at 7:13 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello Dorothy,
> 
>       > The Neighbor Discovery protocol (ND) [RFC4861] is used over
>       > 802.11-OCB links.
> 
>     OLD:
>     <mailto:[email-masked] <mailto:[email-masked]>> Hewlett Packard
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>> +1
>     630-363-1389 <tel:630-363-1389>
>     > 
>     > 
>     > 
>     > <[email-masked] <mailto:[email-masked]>
>     >> *From:*its [mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>] *On Behalf Of
>     *John Kenney
>     >> <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     > <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >> wrote:
>     >> 
>     >> 
>     >> 
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     > <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>>), who is
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> Hewlett
>     >> Packard
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>>
>     [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:dstanley1389@gmail..com>>>>
>     >>> <[email-masked] <mailto:[email-masked]>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     >>> wrote:
>     >>> 
>     >>> Hi IPWAVErs,
>     >>> 
>     >>> [email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>> Pour :
>     Jerome Haerri
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> <mailto:Jerome.Haerri@eurecom <mailto:Jerome.Haerri@eurecom>.
>     >> <mailto:Jerome.Haerri@eurecom <mailto:Jerome.Haerri@eurecom>.>.fr>>>,
>     <mailto:[email-masked] <mailto:ipwave-chairs@ietf..org>>>
>     <mailto:[email-masked] <mailto:ipwave-chairs@ietf..org>>>>,
>     >> Jerome Haerri
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> <mailto:jerome.haerri@eurecom <mailto:jerome.haerri@eurecom>.
>     >> <mailto:jerome.haerri@eurecom <mailto:jerome.haerri@eurecom>.>.fr>>>,
>     >>> Alexandre Petrescu <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>>>,
>     Alexandre Petrescu
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     > <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>>>, Nabil
>     > <mailto:[email-masked] <mailto:[email-masked]>>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>,
>     >>> Thierry Ernst <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > <mailto:[email-masked] <mailto:[email-masked]>>>>>,
>     Jong-Hyouk Lee
>     <mailto:[email-masked] <mailto:[email-masked]>>>>>
>     >>> 
>     >>> 
>     >>> A new version of I-D,
>     >>> at tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>
>     >>> <http://tools.ietf.org>
>     > <http://tools.ietf.org>.
>     >>> 
>     >>> The IETF Secretariat
>     >>> 
>     > <mailto:[email-masked] <mailto:[email-masked]>>> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 11:25:39 +0100

> If it's true, surely it needs to be documented.

Brian,

Sorry if there was confusion.

802.11-OCB is significantly less reliable than Ethernet, just like 
802.11 BSS is.  Both link-layer unicast and link-layer multicast in 
802.11-OCB and in BSS are significantly less reliable than Ethernet.

The earlier text may have been misleading, because it's hard to write 
excellently clear text agreed by many.

It is also true that sending IP packets to IP link-local scoped 
multicast groups in OCB mode, and expecting receivers to get them may 
not be straightforward.  Forming link-scoped IP multicast groups 
(including the 'all-nodes' group) involves the use of MLDv2 protocol; 
this protocol forms the 'all-nodes' group by sending a REPORT message to 
IP all-nodes address which is mapped on MAC all-nodes. This group MAC 
all-nodes is very variable from one moment to another (cars come and go 
at high speed).  As such it's almost impossible to be sure the groups 
are stable and their members receive packets addressed to group at some 
moment.

That's my IP explanation of Dick's idea of variability in OCB networks.

In WiFi networks there is no such variability because there is 
Association, there is an Access Point and the Hosts are relatively 
stable (WiFi range is 50m, smartphones cant move that fast in there), so 
the IP multicast groups like 'all-nodes' are stable.

> for multicast unreliability that are described there also apply to OCB?

I didnt know that draft.  It's good to see.

When they talk about multicast unreliability in section 3.1.1 I think 
they mean like in video stream: send an UDP packet to multicast group 
but there is no Ack like TCP, so there is no reliability in multicast.

To give a solution to that problem (make multicast reliable) there would 
be a need of a reverse multicast concept: send packets from multicast 
group to unicast address and ask for an Ack from that unicast address, 
which would be sent back to all members of the group.

But probably the reverse multicast concept is impossible simply because 
'cast' in multicast comes from 'broadcast' which means to cast broadly. 
One casts a shadow of a small object over a much wider area, or one 
'broadcasts' TV waves to people.  So instead of 'reverse multicast' 
maybe one can talk about 'focus' multiple sources to one destination. 
Or something else.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 17:11:55 +0100

Le 06/12/2018 à 14:39, Dick Roy a écrit :
> Because there will be many situations in OCB operation where IPv6 is either
> NOT deployed (and therefore not used), or is simply unavailable for a
> variety of reasons, all well-known.  In such situations, ND can NOT be used.
> That's why I suggest "can be" rather than "is".  Now that you see the point,
> feel free to change the text to make this point if you like.

I see the point.

I propose the following: the IETF Internet Draft says "ND is used" and 
another SDO says "WSMP is used".

Do you disagree with this proposal?

Alex

> From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Wednesday, December 5, 2018 11:39 PM
> To: [email-masked]; 'Dorothy Stanley'
> Cc: [email-masked]; [email-masked]; 'John Kenney';
> [email-masked]; lorenzo=[email-masked];
> [email-masked]
>> I'd suggest:
>> "The Neighbor Discovery protocol (ND) [RFC4861] can be used over IEEE
>> 802.11-OCB links."
>>
> <mailto:[email-masked]>>
>>      >> I support John's comment. ITS-G5/DSRC/OCB can fully do unicast
>>      >> is broadcast. Maybe we should mention reduced 'application-layer
>>      >> reliability' so something in that direction..
>>      >>
>>      >>
>>      >> BR,
>>      >>
>>      >> Jérôme
>>      >>
> <mailto:[email-masked]>
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>>), who is
> <mailto:[email-masked]>
> <mailto:dstanley@arubanetworks..com>
> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>
> <mailto:[email-masked]>>>>>
>>      >>> wrote:
>>      >>>
>>      >>> Hi IPWAVErs,
>>      >>>
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>> Pour :
>>      Jerome Haerri
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>>>,
>>      Alexandre Petrescu
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>>>, Nabil
> <mailto:[email-masked]>>>>>,
>>      Jong-Hyouk Lee

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 17:22:28 +0100

Le 06/12/2018 à 14:36, Dick Roy a écrit :
> " In WiFi networks there is no such variability because there is
> the IP multicast groups like 'all-nodes' are stable."
> 
> Actually, not so anymore.  WiFi range can be 100's of meters (Xfinity WiFi
> on street poles) and I can associate with those BSSes while driving my car
> down the street.

YEs, it is possible to associate to BSSes while in car, and maybe while 
driving a little bit, slowly.  But certainly not while driving full 
speed on highway.

E.g.: a car at gas station can associate to WiFi, while filling in gas; 
a car near one's home can associate to that home WiFi while driver is 
sleeping.

One should not extend this to a situation where a car drives around and 
associates to WiFi RSUs along the road and maintains an IP connection 
open while doing skype.  That does not work.  And it's not because of IP.

> It doesn't work so well yet, if I'm doing 50kph down the
> street however:^)) 

I agree.

> Once FIPS gets deployed that may improve:^))

What means FIPS?  (Federal... something Standards?)

Or FMIP?  Fast Mobile IP is good solution for fast IP mobility, but it 
was experimented only on WiFi (not on OCB).  It was still slow because 
WiFi Associations were there.  There is no FMIP experiment on OCB.

Alex

> Sent: Thursday, December 6, 2018 2:26 AM
> To: Brian E Carpenter; Dorothy Stanley
> Cc: [email-masked]; [email-masked]; [email-masked]; John Kenney;
> [email-masked];

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 18:02:14 +0100

Until 802.11ai Fast Initial Link Setup implementations become readily 
available on off-the-shelf cheap wifi cards at 5.9GHz we will continue 
to rather use OCB for IP.

(2.4GHz and 5.4GHz is restricted to indoor use, and I suppose 802.11ai 
does not work on 5.9GHz)

Alex

Le 06/12/2018 à 17:46, Dick Roy a écrit :
> All true :^))) As for "what is FIPS?  ANSWER: a TYPO!  I meant FILS, Fast
> Initial Link Setup (IEEE 802.11 TGai) :^))) I didn't mean:
> 
> " FIPS (Federal Information Processing Standards) are a set of standards
> that describe document processing, encryption algorithms and other
> information technology standards for use within non-military government
> agencies and by government contractors and vendors who work with the
> agencies."
> 
> :^)))
> 
> 
> 
> Sent: Thursday, December 6, 2018 8:22 AM
> To: [email-masked]; 'Brian E Carpenter'; 'Dorothy Stanley'
> [email-masked]; [email-masked];

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 19:58:50 +0100

Never saw something else than OCB at 5.9GHz (no FILS messages)

Le 06/12/2018 à 19:10, Dick Roy a écrit :
> FILS is frequency band agnostic.  It's really a session layer functionality.
> 
> 
> 
> Sent: Thursday, December 6, 2018 9:02 AM
> Cc: [email-masked]; [email-masked]; [email-masked]; 'John
> Kenney'; [email-masked];
>> [email-masked];