Repository : ssh://git@open-mesh.org/doc

On branches: backup-redmine/2019-09-17,master

commit c873f1b8046992f0ab500963247e26d1c223aabf Author: Sven Eckelmann sven@narfation.org Date: Tue Sep 17 10:24:48 2019 +0000

doc: batman-adv/Multicast-ideas-updated

c873f1b8046992f0ab500963247e26d1c223aabf batman-adv/Multicast-ideas-updated.textile | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/batman-adv/Multicast-ideas-updated.textile b/batman-adv/Multicast-ideas-updated.textile index ae536f1..26fad8e 100644 --- a/batman-adv/Multicast-ideas-updated.textile +++ b/batman-adv/Multicast-ideas-updated.textile @@ -463,12 +463,12 @@ Update (2012-12-xx):

Current status / Todo:

- * there is a working, "feature complete", but not much tested "patchset based on v2013.0.0":https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/linus/multicast... which should work for any IP multicast data (no more code changes other than bug, comment or commit message fixes intended) - * More issues with the Linux bridge got fixed upstream (recent kernel recommended) - * Multicast video streaming still does not work reliably due to packet loss (anyone knowing a robust video codec? or the old FEC ideas could help) - * What about compatibility? Should we break it? Or should we wait for TLV support? How should multicast-optimizating nodes interact with others (should they drop it? should we monitor MLD/IGMP messages coming from the mesh to find multicast listeners behind non-multicast-optimizing batman nodes?) Or should it be part of BATMAN V instead of being a stand-alone (optional?) feature? UPDATE: There is a suggestion at the bottom now. - * Does the proactive, redundant attching of MLA information to an OGM hinder the development of BATMAN V (bc. the idea of BATMAN V was to allow drastically increasing the proactive, periodic OGM interval to increase scalability - what impact would a very high OGM interval have on the usability of this multicast optimization feature? - * What about the Bridge Loop Avoidance? If a batman-adv client sending multicast data is attached to two or more batman-adv nodes, will they all, redundantly send the multicast data to any multicast listener resulting in duplicate multicast data packets on the upper mesh layer? (though it at least shouldn't cause any loops, I think) +* there is a working, "feature complete", but not much tested "patchset based on v2013.0.0":https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/linus/multicast... which should work for any IP multicast data (no more code changes other than bug, comment or commit message fixes intended) +** More issues with the Linux bridge got fixed upstream (recent kernel recommended) +** Multicast video streaming still does not work reliably due to packet loss (anyone knowing a robust video codec? or the old FEC ideas could help) +** What about compatibility? Should we break it? Or should we wait for TLV support? How should multicast-optimizating nodes interact with others (should they drop it? should we monitor MLD/IGMP messages coming from the mesh to find multicast listeners behind non-multicast-optimizing batman nodes?) Or should it be part of BATMAN V instead of being a stand-alone (optional?) feature? UPDATE: There is a suggestion at the bottom now. +** Does the proactive, redundant attching of MLA information to an OGM hinder the development of BATMAN V (bc. the idea of BATMAN V was to allow drastically increasing the proactive, periodic OGM interval to increase scalability - what impact would a very high OGM interval have on the usability of this multicast optimization feature? +** What about the Bridge Loop Avoidance? If a batman-adv client sending multicast data is attached to two or more batman-adv nodes, will they all, redundantly send the multicast data to any multicast listener resulting in duplicate multicast data packets on the upper mesh layer? (though it at least shouldn't cause any loops, I think) * Multicast Router Discovery (RFC4286): For multicast traffic with a link-local address scope MLD snooping should be sufficient. However, for potentially routed multicast traffic we need to send any multicast traffic to any multicast router, too. For that we need to snoop for multicast router announcements, too and should perform the multicast router solicitation part. The same needs to be implemented for the Linux bridge code * The Linux bridge lacks proper querier protocol support. Meaning if there is a multicast router with a proper querier protocol implementation on the linux, administrators would need to manually disable the rudimentary querier implemantion on all bridges. If there is no multicast router, then the querier should be enabled on at least one bridge. See: https://lkml.kernel.org/r/loom.20130403T154347-81@post.gmane.org * If the bridge snooping works reliably then, then the application of snooping for IPv6 transient addresses only should probably be removed. Instead only ff00::/15, ff01::/15 and ff02::1/128 should be excluded.