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

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

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
>>
>