Re: [ipwave] ND an link-layer acks

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
IEEE 802.11 WG Chair, dstanley@ieee.org
Hewlett Packard Enterprise
dorothy.stanley@hpe.com <dstanley@arubanetworks.com>
dstanley1389@gmail.com
+1 630-363-1389 <630-363-1389>

On Wed, Dec 5, 2018 at 2:52 AM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

> 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
> >
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>

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