Sorry about the glitches at the beginning. Jitsi was giving us problems (frozen or long-delayed video, etc) so I made the call to switch to Zoom. We regularly use zoom internally within ARDC for Board and Grant Advisory Committee meetings and it has performed well; it also seemed to work well today.
I am a bit disappointed that, as a group of radio amateurs active in IP networking, supposedly the people who know all about how to setup a communication system all by themselves, we have to resort to a system like zoom.us to hold a conference.
Rob
To be fair, even giant international organizations that own and operate fiber runs like Southern Cross need to “resort” to systems like Zoom.
On Sun, Oct 11, 2020 at 5:12 AM Rob Janssen via 44Net < 44net@mailman.ampr.org> wrote:
Sorry about the glitches at the beginning. Jitsi was giving us problems (frozen or long-delayed video, etc) so I made the call to switch to Zoom. We regularly use zoom internally within ARDC for Board and Grant Advisory Committee meetings and it has performed well; it also seemed to work well today.
I am a bit disappointed that, as a group of radio amateurs active in IP networking, supposedly the people who know all about how to setup a communication system all by themselves, we have to resort to a system like zoom.us to hold a conference.
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 10/11/20 02:11, Rob Janssen via 44Net wrote:
Sorry about the glitches at the beginning. Jitsi was giving us problems (frozen or long-delayed video, etc) so I made the call to switch to Zoom. We regularly use zoom internally within ARDC for Board and Grant Advisory Committee meetings and it has performed well; it also seemed to work well today.
I am a bit disappointed that, as a group of radio amateurs active in IP networking, supposedly the people who know all about how to setup a communication system all by themselves, we have to resort to a system like zoom.us to hold a conference.
If you're offering to organize, create and open-source a conferencing system that does what Zoom does AND SCALES UP, be my guest! You could even apply to us for a grant...
Seriously, this touches on one of my pet topics: IP multicasting. A huge amount of work went into the development of IP multicast protocols in the 1980s and 1990s, yet nearly all of it has been stillborn. It sees use only in walled gardens like AT&T Uverse (an IPTV over VDSL service in the US) and in degenerate form for intra-net resource discovery on LANs.
Most (if not nearly all) of the Internet's traffic is fundamentally multicast in nature. Even this mailing list is a many-to-many communication. I'm continually appalled by the willingness of commercial services to simply throw money, computers and fiber at replicating and sending unicast packets on a petabyte scale while ignoring the technology and protocols invented to solve this exact problem in a scalable and cost-effective way.
Clearly there's an opportunity here for any group motivated by the desire to do it right. It's something I could certainly support within ARDC.
Phil
Phil Karn via 44Net je 11. 10. 20 ob 14:37 napisal:
Seriously, this touches on one of my pet topics: IP multicasting. A huge amount of work went into the development of IP multicast protocols in the 1980s and 1990s, yet nearly all of it has been stillborn. It sees use only in walled gardens like AT&T Uverse (an IPTV over VDSL service in the US) and in degenerate form for intra-net resource discovery on LANs.
I agree and IP Multicast is something we can afford on our 44net based networks, which are without NAT and other limits for IPv4 Multicast.
For connecting DMR repeaters between themselves directly, in zero-cong fashion, for instance. Without need for a central DMR master server, which itself is a single point of failure. Its sole role can be to coordinate traffic on talkgroups but the repeater network can learn and communicate directly afterwards. Specially in case of master server failure or network split of any kind.
This is an idea behind a DMR-Multicast project which is already written and I hope I will start testing to release this winter.
73, Janko S57NK
Most (if not nearly all) of the Internet's traffic is fundamentally multicast in nature. Even this mailing list is a many-to-many communication. I'm continually appalled by the willingness of commercial services to simply throw money, computers and fiber at replicating and sending unicast packets on a petabyte scale while ignoring the technology and protocols invented to solve this exact problem in a scalable and cost-effective way.
Clearly there's an opportunity here for any group motivated by the desire to do it right. It's something I could certainly support within ARDC.
Phil
On 10/11/20 07:36, Janko Mivšek via 44Net wrote:
I agree and IP Multicast is something we can afford on our 44net based networks, which are without NAT and other limits for IPv4 Multicast.
For connecting DMR repeaters between themselves directly, in zero-cong fashion, for instance. Without need for a central DMR master server, which itself is a single point of failure. Its sole role can be to coordinate traffic on talkgroups but the repeater network can learn and communicate directly afterwards. Specially in case of master server failure or network split of any kind.
I am especially interested in repeater linking via amateur IP facilities. As I understand it, most repeater linking is over commercial Internet connections, which is great except that you can't count on them being there in emergencies. Besides, we're hams.
I don't know DMR's IP-level protocols, but if they can be multicast, and the 44-net can support general multicast, that would be a perfect combination.
This is an idea behind a DMR-Multicast project which is already written and I hope I will start testing to release this winter.
Great!
Phil
Hi everyone,
I feel the urge on chiming in on this topic regarding multicast.
While multicast works on a flat network (e.g. 44.0.0.0/8, or our current /9 + /10), there are some issues on this solution for 44net: the fact that is is subnetted and edge routers will not pass this traffic unless a PIM or a IGMP proxy is set up on each of them.
Now, while advanced routers are quite capable of doing it (e.g. Mikrotik gear), I am not so sure about other devices used as gateways. And BGP announced subnets are out of the question AFAIK, since there are actual independent networks. But anyhow, there is a configuration effort be done on each gateway or edge router.
Of course, experimenting would be nice, but I would not get my hopes up high for a globally working multicast solution at this moment.
Marius, YO2LOJ
On 11.10.2020 20:31, Phil Karn via 44Net wrote:
On 10/11/20 07:36, Janko Mivšek via 44Net wrote:
I agree and IP Multicast is something we can afford on our 44net based networks, which are without NAT and other limits for IPv4 Multicast.
For connecting DMR repeaters between themselves directly, in zero-cong fashion, for instance. Without need for a central DMR master server, which itself is a single point of failure. Its sole role can be to coordinate traffic on talkgroups but the repeater network can learn and communicate directly afterwards. Specially in case of master server failure or network split of any kind.
I am especially interested in repeater linking via amateur IP facilities. As I understand it, most repeater linking is over commercial Internet connections, which is great except that you can't count on them being there in emergencies. Besides, we're hams.
I don't know DMR's IP-level protocols, but if they can be multicast, and the 44-net can support general multicast, that would be a perfect combination.
This is an idea behind a DMR-Multicast project which is already written and I hope I will start testing to release this winter.
Great!
Phil
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On 10/11/20 17:01, Marius Petrescu wrote:
Of course, experimenting would be nice, but I would not get my hopes up high for a globally working multicast solution at this moment.
I didn't say it would necessarily be easy in every case. :-)
Phil
Multicast traffic to/from BGP announced subnets with a transit provider that does not support multicast should be possible to tunnel mbone style (rfc7450), right? Mbone did work globally and may not be totally dead.
On 2020-10-12 02:01, Marius Petrescu via 44Net wrote:
Hi everyone,
I feel the urge on chiming in on this topic regarding multicast.
While multicast works on a flat network (e.g. 44.0.0.0/8, or our current /9 + /10), there are some issues on this solution for 44net: the fact that is is subnetted and edge routers will not pass this traffic unless a PIM or a IGMP proxy is set up on each of them.
Now, while advanced routers are quite capable of doing it (e.g. Mikrotik gear), I am not so sure about other devices used as gateways. And BGP announced subnets are out of the question AFAIK, since there are actual independent networks. But anyhow, there is a configuration effort be done on each gateway or edge router.
Of course, experimenting would be nice, but I would not get my hopes up high for a globally working multicast solution at this moment.
Marius, YO2LOJ
On 11.10.2020 20:31, Phil Karn via 44Net wrote:
On 10/11/20 07:36, Janko Mivšek via 44Net wrote:
I agree and IP Multicast is something we can afford on our 44net based networks, which are without NAT and other limits for IPv4 Multicast.
For connecting DMR repeaters between themselves directly, in zero-cong fashion, for instance. Without need for a central DMR master server, which itself is a single point of failure. Its sole role can be to coordinate traffic on talkgroups but the repeater network can learn and communicate directly afterwards. Specially in case of master server failure or network split of any kind.
I am especially interested in repeater linking via amateur IP facilities. As I understand it, most repeater linking is over commercial Internet connections, which is great except that you can't count on them being there in emergencies. Besides, we're hams.
I don't know DMR's IP-level protocols, but if they can be multicast, and the 44-net can support general multicast, that would be a perfect combination.
This is an idea behind a DMR-Multicast project which is already written and I hope I will start testing to release this winter.
Great!
Phil
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Bjorn Pehrson via 44Net 44net@mailman.ampr.org writes:
Multicast traffic to/from BGP announced subnets with a transit provider that does not support multicast should be possible to tunnel mbone style (rfc7450), right? Mbone did work globally and may not be totally dead.
Yes, this ought to be possible. Once upon a time I operated a portion of the mbone on CA*Net II and I'm sad that it has fallen into disuse. As I recall, it was a combination of dense-mode in the over-provisioned core where you could simply carry all of the sessions and sparse-mode closer to the edge where that would have been impractical. This general structure seems similar to what is described in RFC7450: that's concerned with the interface between the native part (perhaps dense) and the isolated part (definitely sparse).
How can the native part scale (beyoned 44Net)? We can't have zillions of join/leave messages percolating all the way up the tree because the load resulting from processing these would become unmanageable. In the limit, each multicast group containing two participants, we've just recreated unicast with a far more expensive routing protocol. But neither can we have all sessions carried in the core (or can we? are we able to overprovision like that? maybe if we reengineer the content distribution networks to do this... perhaps they do it themselves already). Anyways, that's the basic trade-off (regardless of protocol choice or acronym flavour). A partial solution is to also have a notion of geographic scope.
Anyways, just some thoughts.
73s VE0HAK
William Waites via 44Net je 12. 10. 20 ob 10:04 napisal:
How can the native part scale (beyoned 44Net)? We can't have zillions of join/leave messages percolating all the way up the tree because the load resulting from processing these would become unmanageable. In the limit, each multicast group containing two participants, we've just recreated unicast with a far more expensive routing protocol. But neither can we have all sessions carried in the core (or can we? are we able to overprovision like that? maybe if we reengineer the content distribution networks to do this... perhaps they do it themselves already). Anyways, that's the basic trade-off (regardless of protocol choice or acronym flavour). A partial solution is to also have a notion of geographic scope.
Multicast happens only on local subnet. But it can be extended to other subnets via unicast by help of PIM protocol (Protocol Independent Multicast).
PIM supports two modes: dense and sparse mode. In dense mode a sender floods the whole network until receivers explicitly say no (prune). In sparse mode there is one Rendezvous Point (RP) where receivers ask to join the sender stream.
RP does a coordination so that sender streams via unicast directly to the receiver's subnet router, which finally multicasts to that subnet. This way the multicast traffic is reduced on the whole network to a minimum.
RP router is a single point of failure, so there are more candidate RP routers. And to complicate matter a bit more, there are also Bootstrap routers (BR) to help discovering the RP.
Mikrotik is the only one among cheaper gear to have a PIM (only Sparse mode) implementation. It is a bit clumsy but with a few tweaks it is (from my experience so far) manageable.
73, Janko S57NK
Anyways, just some thoughts.
73s VE0HAK
Phil Karn via 44Net je 11. 10. 20 ob 19:31 napisal:
On 10/11/20 07:36, Janko Mivšek via 44Net wrote:
I agree and IP Multicast is something we can afford on our 44net based networks, which are without NAT and other limits for IPv4 Multicast.
For connecting DMR repeaters between themselves directly, in zero-cong fashion, for instance. Without need for a central DMR master server, which itself is a single point of failure. Its sole role can be to coordinate traffic on talkgroups but the repeater network can learn and communicate directly afterwards. Specially in case of master server failure or network split of any kind.
I am especially interested in repeater linking via amateur IP facilities. As I understand it, most repeater linking is over commercial Internet connections, which is great except that you can't count on them being there in emergencies. Besides, we're hams.
There was a rush installing DMR repeaters two years ago, that's why everyone setup a plain WiFi link into public internet to became online as soon as possible. Now at least in my country we started adding cross-hill links to achieve redundancy. These are still mostly WiFi but also homebrew NBP by S53MV. We also started using 44 IPs to harmonize different networks into a nation-wide one.
I don't know DMR's IP-level protocols, but if they can be multicast, and the 44-net can support general multicast, that would be a perfect combination.
All are using unicast UDP. DMR-Multicast protocol is converting them into its own multicast-aware format.
Janko S57NK
This is an idea behind a DMR-Multicast project which is already written and I hope I will start testing to release this winter.
Great!
Phil
Phil Karn via 44Net je 11. 10. 20 ob 14:37 napisal:
Seriously, this touches on one of my pet topics: IP multicasting. A huge amount of work went into the development of IP multicast protocols in the 1980s and 1990s, yet nearly all of it has been stillborn. It sees use only in walled gardens like AT&T Uverse (an IPTV over VDSL service in the US) and in degenerate form for intra-net resource discovery on LANs.
I agree and IP Multicast is something we can afford on our 44net based networks, which are without NAT and other limits for IPv4 Multicast.
For connecting DMR repeaters between themselves directly, in zero-cong fashion, for instance. Without need for a central DMR master server, which itself is a single point of failure. Its sole role can be to coordinate traffic on talkgroups but the repeater network can learn and communicate directly afterwards. Specially in case of master server failure or network split of any kind.
This is an idea behind a DMR-Multicast project which is already written and I hope I will start testing to release this winter.
73, Janko S57NK
Most (if not nearly all) of the Internet's traffic is fundamentally multicast in nature. Even this mailing list is a many-to-many communication. I'm continually appalled by the willingness of commercial services to simply throw money, computers and fiber at replicating and sending unicast packets on a petabyte scale while ignoring the technology and protocols invented to solve this exact problem in a scalable and cost-effective way.
Clearly there's an opportunity here for any group motivated by the desire to do it right. It's something I could certainly support within ARDC.
Phil
-
Bjorn Pehrson -
Cryptographrix -
Janko Mivšek -
Marius Petrescu -
Phil Karn -
Rob Janssen -
Stuart Longland (VK4MSL) -
William Waites