Re: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-31.txt

Le 04/12/2018 à 16:37, John Kenney a écrit :
> Hi,
> 
> Caveat: I know nothing about Neighbor Discovery protocol.

I can tell how it works: you send a request to learn the MAC address of 
a computer keyed on its IP address.  And the computer responds.  For it 
to work there are many needs of understandings between MAC and IP.

Another thing that ND does is that it times out its entries in its data 
structures if some reply is expected for too long.  So one can expect 
reliability added by ND, where OCB misses it.

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

John,

In some implementations I have seen there are indeed link-layer acks in
OCB mode (notably _some_ Road-Side Units, not all).

In other implementations (notably in some V2V communications without
RSU, not all) there are no link-layer acks in OCB mode.

Packet dumps available upon request.

The paragraph you are confronted with is a suggestion from 6MAN WG,
which does have a certain level of authority to consider, before
modifying any of their text.

Given that, would it be sufficient to not think about link-layer acks at
all.

I propose this text:
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.

Do you agree with this text?

Alex

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