Re: [Int-area] review of draft-perkins-intarea-multicast-ieee802-03 draft-mcbride-mboned-wifi-mcast-problem-statement-01
Hello Joel, The [mboned] WG has adopted draft-ietf-mboned-ieee802-mcast-problems. I have just posted an update that includes the relevant material from the earlier [intarea] individual submission, draft-perkins-intarea-multicast-ieee802, which you also reviewed. I have some follow-up to your review comments below. On 11/14/2017 6:36 PM, joel jaeggli wrote: Greetings, I have chosen to review both of these documents at this time as they appear to me to be attempts to address the same problem space from the vantage point of slightly different but overlapping communities (evidenced by the authors) both of which have a vested interest in IP multicast operation on ieee 802.xx wireless networks. This review is seperated into the observations common to both followed by (limited) commentary on each document. While both documents address the challenges of arp / ND and aperiodic multicast transmission, draft-mcbride-mboned-wifi-mcast-problem-statement-01 has more focus on application use of multicast above and beyond basic subnet/adjacency/resource discovery applications. draft-perkins-intarea-multicast-ieee802-03 takes a more technical and nuanced look at the underlying 802.xx implementation of multicast/broadcast packet transmission. It is oddly specific in some areas to experiences gleaned from the IETF network, which while it may be a product of our experience, is by no means a unique environment, and these challenges are to a great degree common or in fact worse in other wireless environments (where there might be more low powered devices, less spectrum or radio coordination, a diversity of management domains and so on. The contents of that draft were pretty much contributed text from the co-authors, and there were a number of empty holes for future work. But the future work kept not getting done. it's not clear to me from the outset what the audience for an eventually published document might be. Advice to implementors? Yes. Feedback to the IEEE? Not specifically, but the IEEE folks would definitely notice any work that we do. Operational advice? Yes. Go from problem statment towards work on conclusions? I am not sure about this. For now I would put it as a lower priority, except insofar as bits of advice to implementers and operators would count as conclusions. draft-perkins-intarea-multicast-ieee802-03 is the slightly more mature document of the two, I don't think that there is much justification for advancing both given that they have fairly high overlap without being complimentary, so I would encourage consolidation and coordination between the int interests and those of the mbone/multicast community towards something that is more than the union of the two. Check. >From my vantage-point the best outcome is one where the IETF provides advice to vendors (becaue there are implementation specific tweaks and optimation that can make many situations better) an the IEEE that results in the employment of multicast being less disruptive and costly and potentially to devices on wireless lans. work on ietf protocols associated with arp/nd resource discovery to make them generally less costly on the wire and more sensitive to power / cpu usage is a desirable property as well pariticularly of there are situations where they can be avoided entirely (for example not having to defend addresses via DAD because of something like https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13). I very much agree with this. Some comments specific to each document - draft-perkins-intarea-multicast-ieee802-03 - 3.1.2. Lower Data Rate this rate might be as low as 6 Mbps, when some unicast links in the same cell can be operating at rates up to 600 Mbps. In fact backward compatibility and multi-stream implementations mean that the maximum unicast rates are currently up to a few Gb/s so there can be a more than 3 order of magnitude difference in the transmission rate from the basic rates to optimal unicast forwarding. some techinues employed to increase spectral efficiency such a spatial multiplexing in mimo systems are literally unavailable with more then one intended reciever so it's not simply the case that nominal transmission rates available are limited by backwards compatibility. We could incorporate a version of your text into section 3.1.2 of the new revision. 3.2.2. IPv6 issues Respecting some of the cost of multicast on wireless networks these are not strictly wireless problems reductions in the amount of signaling required is better for the control-planes of routers, and for all hosts ultimately, whether that is unicast RAs, prefix per host, or simply rate limits on layer 2 learning e.g. https://tools.ietf.org/html/rfc6583 problems. 3.2.4 and 3.2.2 therefore are very much problems that extend beyond the wireless domain. Specifically with 3.2.4 the arp problem
[Int-area] review of draft-perkins-intarea-multicast-ieee802-03 draft-mcbride-mboned-wifi-mcast-problem-statement-01
Greetings, I have chosen to review both of these documents at this time as they appear to me to be attempts to address the same problem space from the vantage point of slightly different but overlapping communities (evidenced by the authors) both of which have a vested interest in IP multicast operation on ieee 802.xx wireless networks. This review is seperated into the observations common to both followed by (limited) commentary on each document. While both documents address the challenges of arp / ND and aperiodic multicast transmission, draft-mcbride-mboned-wifi-mcast-problem-statement-01 has more focus on application use of multicast above and beyond basic subnet/adjacency/resource discovery applications. draft-perkins-intarea-multicast-ieee802-03 takes a more technical and nuanced look at the underlying 802.xx implementation of multicast/broadcast packet transmission. It is oddly specific in some areas to experiences gleaned from the IETF network, which while it may be a product of our experience, is by no means a unique environment, and these challenges are to a great degree common or in fact worse in other wireless environments (where there might be more low powered devices, less spectrum or radio coordination, a diversity of management domains and so on. it's not clear to me from the outset what the audience for an eventually published document might be. Advice to implementors? Feedback to the IEEE? Operational advice? Go from problem statment towards work on conclusions? draft-perkins-intarea-multicast-ieee802-03 is the slightly more mature document of the two, I don't think that there is much justification for advancing both given that they have fairly high overlap without being complimentary, so I would encourage consolidation and coordination between the int interests and those of the mbone/multicast community towards something that is more than the union of the two. >From my vantage-point the best outcome is one where the IETF provides advice to vendors (becaue there are implementation specific tweaks and optimation that can make many situations better) an the IEEE that results in the employment of multicast being less disruptive and costly and potentially to devices on wireless lans. work on ietf protocols associated with arp/nd resource discovery to make them generally less costly on the wire and more sensitive to power / cpu usage is a desirable property as well pariticularly of there are situations where they can be avoided entirely (for example not having to defend addresses via DAD because of something like https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13). Some comments specific to each document - draft-perkins-intarea-multicast-ieee802-03 - 3.1.2. Lower Data Rate this rate might be as low as 6 Mbps, when some unicast links in the same cell can be operating at rates up to 600 Mbps. In fact backward compatibility and multi-stream implementations mean that the maximum unicast rates are currently up to a few Gb/s so there can be a more than 3 order of magnitude difference in the transmission rate from the basic rates to optimal unicast forwarding. some techinues employed to increase spectral efficiency such a spatial multiplexing in mimo systems are literally unavailable with more then one intended reciever so it's not simply the case that nominal transmission rates available are limited by backwards compatibility. 3.2.2. IPv6 issues Respecting some of the cost of multicast on wireless networks these are not strictly wireless problems reductions in the amount of signaling required is better for the control-planes of routers, and for all hosts ultimately, whether that is unicast RAs, prefix per host, or simply rate limits on layer 2 learning e.g. https://tools.ietf.org/html/rfc6583 problems. 3.2.4 and 3.2.2 therefore are very much problems that extend beyond the wireless domain. Specifically with 3.2.4 the arp problem also applies to ND, in both cases non-standard counter-measures (arp sponging unlearned entries as in 5.1 for v4) various forms of off-net vs on-net driven ND suppression. On a wired network, there is not a huge difference amongst unicast, multicast and broadcast traffic; Inadvertent flooded traffic or high amounts of ethernet multicast on wired networks can be quite a bit less costly due to nic filtering, then in cases where devices have to wake up effectively to process packets. also the fact that these networks tend to be switched futher reduces impact (there is effectively no collision / scheduling problem until you get to extremely high port utilization) 4.3 not clear how this directly impacts multicast / except that a unicast optimization ight seperately send to different STAs at different times. optimization around long DTIM intervals to allow clients to sleep longer clearly has impacts on performance, convergence