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

[Alexandre Petrescu <[e-mail]>]

Hello Dorothy,

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

NEW:
 > The Neighbor Discovery protocol (ND) [RFC4861] is used over
 > 802.11-OCB links.

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.

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."
> 
> 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,
> [e-mail] <mailto:[e-mail]> Hewlett Packard
> Enterprise [e-mail]
> <mailto:[e-mail]> [e-mail]
> <mailto:[e-mail]> [phone] <tel:[phone]>
> 
> 
> 
> On Wed, Dec 5, 2018 at 2:52 AM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>>
> 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:[e-mail]
> <mailto:[e-mail]>] *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 
>> <[e-mail]
> <mailto:[e-mail]> 
> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>> wrote:
>> 
>> 
>> 
>> Le 04/12/2018 à 16:04, Dorothy Stanley a écrit :
>>> Hello Alexandre, all,
>>> 
>>> I am sharing the following information from John Kenny ( 
>>> [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> <mailto:[e-mail]
>> <mailto:[e-mail]> 
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>), 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, 
>>> [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>> Hewlett
>> Packard
>>> Enterprise [e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>>> <mailto:[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>> [e-mail] 
> <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>
>>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>
>> [phone] <tel:[phone]>
>>> 
>>> 
>>> 
>>> On Mon, Nov 19, 2018 at 10:07 AM Alexandre Petrescu 
>>> <[e-mail]
>>> <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> <mailto:[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>>
>>> 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 :
>>> [e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail]
>> <mailto:[e-mail]>>
>>> <mailto:[e-mail]
>>> <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>> Pour : Jerome Haerri
>>> <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]> 
>> <mailto:Jerome.Haerri@eurecom.
>> <mailto:Jerome.Haerri@eurecom.>.fr>>>,
>>> [e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>,
>> Jerome Haerri
>>> <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]> 
>> <mailto:jerome.haerri@eurecom.
>> <mailto:jerome.haerri@eurecom.>.fr>>>,
>>> Alexandre Petrescu <[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail]
>> <mailto:[e-mail]>>
>>> <mailto:[e-mail]
>>> <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>>, Alexandre Petrescu
>>> <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> <mailto:[e-mail]
>> <mailto:[e-mail]> 
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>>, Nabil
>>> Benamar <[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>>,
>>> Thierry Ernst <[e-mail]
> <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>
>>> <mailto:[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail]
> <mailto:[e-mail]>>>>, Jong-Hyouk Lee
>>> <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>
>> <mailto:[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>>>
>>> 
>>> 
>>> 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>
> <http://tools.ietf.org>.
>>> 
>>> The IETF Secretariat
>>> 
>>> _______________________________________________ its mailing list 
>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail] <mailto:[e-mail]>>>
>>> https://www.ietf.org/mailman/listinfo/its
>>> 
>> 
>> _______________________________________________ its mailing list 
>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> 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: [phone]. Mobile: [phone]
>> 
> 
> _______________________________________________ its mailing list 
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/its
>