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

[Alexandre Petrescu <[e-mail]>]

Le 06/12/2018 à 14:36, Dick Roy a écrit :
> " In WiFi networks there is no such variability because there is
> Association, there is an Access Point and the Hosts are relatively
> stable (WiFi range is 50m, smartphones cant move that fast in there), so
> the IP multicast groups like 'all-nodes' are stable."
> 
> Actually, not so anymore.  WiFi range can be 100's of meters (Xfinity WiFi
> on street poles) and I can associate with those BSSes while driving my car
> down the street.

YEs, it is possible to associate to BSSes while in car, and maybe while 
driving a little bit, slowly.  But certainly not while driving full 
speed on highway.

E.g.: a car at gas station can associate to WiFi, while filling in gas; 
a car near one's home can associate to that home WiFi while driver is 
sleeping.

One should not extend this to a situation where a car drives around and 
associates to WiFi RSUs along the road and maintains an IP connection 
open while doing skype.  That does not work.  And it's not because of IP.

> It doesn't work so well yet, if I'm doing 50kph down the
> street however:^)) 

I agree.

> Once FIPS gets deployed that may improve:^))

What means FIPS?  (Federal... something Standards?)

Or FMIP?  Fast Mobile IP is good solution for fast IP mobility, but it 
was experimented only on WiFi (not on OCB).  It was still slow because 
WiFi Associations were there.  There is no FMIP experiment on OCB.

Alex

> 
> -----Original Message-----
> From: its [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, December 6, 2018 2:26 AM
> To: Brian E Carpenter; Dorothy Stanley
> Cc: [e-mail]; [e-mail]; [e-mail]; John Kenney;
> [e-mail];
> lorenzo=[e-mail]
> Subject: Re: [ipwave] ND an link-layer acks - text
> 
> 
> 
> Le 05/12/2018 à 20:40, Brian E Carpenter a écrit :
>> 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.
> 
> Brian,
> 
> Sorry if there was confusion.
> 
> 802.11-OCB is significantly less reliable than Ethernet, just like
> 802.11 BSS is.  Both link-layer unicast and link-layer multicast in
> 802.11-OCB and in BSS are significantly less reliable than Ethernet.
> 
> The earlier text may have been misleading, because it's hard to write
> excellently clear text agreed by many.
> 
> It is also true that sending IP packets to IP link-local scoped
> multicast groups in OCB mode, and expecting receivers to get them may
> not be straightforward.  Forming link-scoped IP multicast groups
> (including the 'all-nodes' group) involves the use of MLDv2 protocol;
> this protocol forms the 'all-nodes' group by sending a REPORT message to
> IP all-nodes address which is mapped on MAC all-nodes. This group MAC
> all-nodes is very variable from one moment to another (cars come and go
> at high speed).  As such it's almost impossible to be sure the groups
> are stable and their members receive packets addressed to group at some
> moment.
> 
> That's my IP explanation of Dick's idea of variability in OCB networks.
> 
> In WiFi networks there is no such variability because there is
> Association, there is an Access Point and the Hosts are relatively
> stable (WiFi range is 50m, smartphones cant move that fast in there), so
> the IP multicast groups like 'all-nodes' are stable.
> 
>>
>> 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?
> 
> I didnt know that draft.  It's good to see.
> 
> When they talk about multicast unreliability in section 3.1.1 I think
> they mean like in video stream: send an UDP packet to multicast group
> but there is no Ack like TCP, so there is no reliability in multicast.
> 
> To give a solution to that problem (make multicast reliable) there would
> be a need of a reverse multicast concept: send packets from multicast
> group to unicast address and ask for an Ack from that unicast address,
> which would be sent back to all members of the group.
> 
> But probably the reverse multicast concept is impossible simply because
> 'cast' in multicast comes from 'broadcast' which means to cast broadly.
> One casts a shadow of a small object over a much wider area, or one
> 'broadcasts' TV waves to people.  So instead of 'reverse multicast'
> maybe one can talk about 'focus' multiple sources to one destination.
> Or something else.
> 
> Alex
> 
>>
>> 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
> 
>