11 Oct
2020
11 Oct
'20
5:11 a.m.
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
11 Oct
11 Oct
7 a.m.
New subject: Thanks to everyone for a good 44net community call!
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(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
8:37 a.m.
New subject: Thanks to everyone for a good 44net community call!
On 10/11/20 02:11, Rob Janssen via 44Net wrote:
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
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. 
10:36 a.m.
New subject: Thanks to everyone for a good 44net community call!
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
1:31 p.m.
New subject: Thanks to everyone for a good 44net community call!
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
8:01 p.m.
New subject: Thanks to everyone for a good 44net community call!
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
8:27 p.m.
New subject: Thanks to everyone for a good 44net community call!
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
12 Oct
12 Oct
3 a.m.
New subject: Thanks to everyone for a good 44net community call!
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:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net 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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net 
4:04 a.m.
New subject: Thanks to everyone for a good 44net community call!
Bjorn Pehrson via 44Net <44net(a)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
1:41 p.m.
New subject: Thanks to everyone for a good 44net community call!
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
6:05 a.m.
New subject: Thanks to everyone for a good 44net community call!
Phil Karn via 44Net je 11. 10. 20 ob 19:31 napisal:
On 10/11/20 07:36, Janko Mivšek via 44Net wrote:
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 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.
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
11 Oct
11 Oct
10:37 a.m.
New subject: Thanks to everyone for a good 44net community call!
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
1502
days inactive
1503
days old
12 comments
8 participants
participants (8)
-
Bjorn Pehrson -
Cryptographrix -
Janko Mivšek -
Marius Petrescu -
Phil Karn -
Rob Janssen -
Stuart Longland (VK4MSL) -
William Waites