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

[Brian E Carpenter <[e-mail]>]

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:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, December 5, 2018 11:49 AM
> To: Alexandre Petrescu; Dorothy Stanley
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; John Kenney;
> lorenzo=[e-mail]
> Subject: Re: [ipwave] ND an link-layer acks - text
> 
> 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
> 
> 
> On 2018-12-06 04:13, Alexandre Petrescu wrote:
>> 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
>>>
>>
> 
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
> 
>