Re: [ipwave] ND an link-layer acks

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

So, how about this text proposal?

NEW:
> The Neighbor Discovery protocol (ND) [RFC4861] is used over 
> 802.11-OCB links.  Due to lack of association operations in
> 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 'lack of association operations' instead of 'lack of link-layer
acks')

OLD:
> 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.
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:its-bounces@ietf.org] *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,
> 
> 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
> 
> On Tue, Dec 4, 2018 at 7:11 AM Alexandre Petrescu 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
> wrote:
> 
> 
> 
> Le 04/12/2018 à 16:04, Dorothy Stanley a écrit :
>> Hello Alexandre, all,
>> 
>> I am sharing the following information from John Kenny ( 
>> jkenney@us.toyota-itc.com <mailto:jkenney@us.toyota-itc.com>
> <mailto:jkenney@us.toyota-itc.com 
> <mailto:jkenney@us.toyota-itc.com>>), 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:
>> The Neighbor Discovery protocol (ND) [RFC4861] is used over 
>> 802.11-OCB links.  Due to lack of link-layer acknowledgements in 
>> 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:
>> 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.
> 
> Would this be agreed by John Kenney.
> 
> Alex
> 
>> 
>> Thanks,
>> 
>> Dorothy
>> 
>> ---------------------- Dorothy Stanley IEEE 802.11 WG Chair, 
>> dstanley@ieee.org <mailto:dstanley@ieee.org>
> <mailto:dstanley@ieee.org <mailto:dstanley@ieee.org>> Hewlett 
> Packard
>> Enterprise dorothy.stanley@hpe.com <mailto:dorothy.stanley@hpe.com>
>>  <mailto:dstanley@arubanetworks.com
> <mailto:dstanley@arubanetworks.com>> dstanley1389@gmail.com 
> <mailto:dstanley1389@gmail.com>
>> <mailto:dstanley1389@gmail.com <mailto:dstanley1389@gmail.com>>
> +1 630-363-1389 <tel:630-363-1389>
>> 
>> 
>> 
>> On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu 
>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com> 
> <mailto:alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>>>
>> 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 : internet-drafts@ietf.org
> <mailto:internet-drafts@ietf.org>
>> <mailto:internet-drafts@ietf.org
> <mailto:internet-drafts@ietf.org>> Pour : Jerome Haerri
>> <Jerome.Haerri@eurecom.fr <mailto:Jerome.Haerri@eurecom.fr>
> <mailto:Jerome.Haerri@eurecom.fr 
> <mailto:Jerome.Haerri@eurecom..fr>>>,
>> ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>
> <mailto:ipwave-chairs@ietf.org <mailto:ipwave-chairs@ietf.org>>, 
> Jerome Haerri
>> <jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>
> <mailto:jerome.haerri@eurecom.fr 
> <mailto:jerome.haerri@eurecom..fr>>>,
>> Alexandre Petrescu <Alexandre.Petrescu@cea.fr
> <mailto:Alexandre.Petrescu@cea.fr>
>> <mailto:Alexandre.Petrescu@cea.fr
> <mailto:Alexandre.Petrescu@cea.fr>>>, Alexandre Petrescu
>> <alexandre.petrescu@cea.fr <mailto:alexandre.petrescu@cea.fr>
> <mailto:alexandre.petrescu@cea.fr 
> <mailto:alexandre.petrescu@cea.fr>>>, Nabil
>> Benamar <n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>
> <mailto:n.benamar@est.umi.ac.ma <mailto:n.benamar@est.umi.ac.ma>>>,
>> Thierry Ernst <thierry.ernst@yogoko.fr
> <mailto:thierry.ernst@yogoko.fr>
>> <mailto:thierry.ernst@yogoko.fr
> <mailto:thierry.ernst@yogoko.fr>>>, Jong-Hyouk Lee
>> <jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>
> <mailto:jonghyouk@smu.ac.kr <mailto:jonghyouk@smu.ac.kr>>>
>> 
>> 
>> 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 <http://tools.ietf.org> <http://tools.ietf.org>.
>> 
>> The IETF Secretariat
>> 
>> _______________________________________________ its mailing list 
>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>>
>> https://www.ietf.org/mailman/listinfo/its
>> 
> 
> _______________________________________________ its mailing list 
> its@ietf.org <mailto:its@ietf.org> 
> https://www.ietf.org/mailman/listinfo/its
> 
> 
> --
> 
> John Kenney
> 
> Director and Principal Researcher
> 
> Toyota InfoTechnology Center, USA
> 
> 465 Bernardo Avenue
> 
> Mountain View, CA 94043
> 
> Tel: 650-694-4160. Mobile: 650-224-6644
> 

Re: [ipwave] ND an link-layer acks - text