Subject: [MBONED] I-D Action: draft-ietf-mboned-ieee802-mcast-problems-03.txt

From: [email-masked]
Date: Tue, 23 Oct 2018 15:16:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MBONE Deployment WG of the IETF.

        Title           : Multicast Considerations over IEEE 802 Wireless Media
        Authors         : Charles E. Perkins
                          Mike McBride
                          Dorothy Stanley
                          Warren Kumari
                          Juan Carlos Zuniga
	Filename        : draft-ietf-mboned-ieee802-mcast-problems-03.txt
	Pages           : 21
	Date            : 2018-10-23

Abstract:
   Well-known issues with multicast have prevented the deployment of
   multicast in 802.11 [dot11], [mc-props], [mc-prob-stmt], and other
   local-area wireless environments.  IETF multicast experts have been
   meeting together to discuss these issues and provide IEEE updates.
   The mboned working group is chartered to receive regular reports on
   the current state of the deployment of multicast technology, create
   "practice and experience" documents that capture the experience of
   those who have deployed and are deploying various multicast
   technologies, and provide feedback to other relevant working groups.
   This document offers guidance on known limitations and problems with
   wireless multicast.  Also described are various multicast enhancement
   features that have been specified at IETF and IEEE 802 for wireless
   media, as well as some operational chioces that can be taken to
   improve the performace of the network.  Finally, some recommendations
   are provided about the usage and combination of these features and
   operational choices.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03
https://datatracker.ietf.org/doc/html/draft-ietf-mboned-ieee802-mcast-problems-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-ieee802-mcast-problems-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Oct 2018 08:29:12 +0200 (CEST)

There is a very heated debate in 6man regarding 
https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag-03

One of the use-cases is that turning off the IPv4 stack in a device will 
stop it from emitting IPv4 service discovery traffic, DHCPv4 server 
solicitation etc, which are typically broadcast or multicast.

Can someone who knows a lot more about wifi please comment on whether this 
is a real problem on wifi deployments and actually affects battery powered 
devices, or if this is just a suboptimization? Would large wifi 
deployments benefit from hosts turning off their IPv4 stacks if the wifi 
is IPv6 only, instead of the hosts running their IPv4 stacks in IPv4 
link-local mode and still emitting service discovery packets and trying to 
configure their IPv4 stack with DHCP (which is typically default)?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Oct 2018 11:40:04 +0200

As i said on that heated debate, in the absence of anyone having analyzed the
problem in more detail, one may want to start looking at the
battery cost assessment for multicast/broadcast from RFC7772
and then check from spec or implementation knowledge how much
broadcast/multicast RFC3927 generates and extrapolate.

In any case, not seeing either of the two RFCs mentioned in
mcast-problems-03 looks like gaps to be closed. 

The recommendations section of the draft should certainly mention
RFC7772, and i think also that using just a single IP version
instead of dual-stack should be a good option to reduce multicast
(see above for quantification), and that there is little to be
won running RFC3927 when you already have IPv6 routed connectivity.
Just a local heuristic of not running RFC3927 ower infra-wifi if
there i IPv6 sounds like a useful local optimization.

But don't believe just me. I am a card-carrying member of the rfc3927 hater club.
Which is not the fault of rfc3927, but of IPv4 or at least all the
OS i know that can't have both IPv4 link-local and routed on the
same interface.

Toerless

On Wed, Oct 24, 2018 at 08:29:12AM +0200, Mikael Abrahamsson wrote:
> devices, or if this is just a suboptimization? Would large wifi deployments
> benefit from hosts turning off their IPv4 stacks if the wifi is IPv6 only,
> instead of the hosts running their IPv4 stacks in IPv4 link-local mode and
> still emitting service discovery packets and trying to configure their IPv4
> stack with DHCP (which is typically default)?
> 
> -- 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
[email-masked]