[MBONED] FW: [multicast-discuss] Multicast discusssion

["Holland, Jake" <[e-mail]>]

Hi mboned,

Lenny reminded me that I should forward my hackathon report to the
mboned list also.  The hackathon project I worked on was AMT interop
including IPv6 with the FreeRTR AMT implementation.  Report is below.

tl;dr: the grumpyoldtroll/amtgw docker container got updated with v6
support and we played music with v{4|6} data over v{4|6} tunnels.  I
put commands in the readme to try it (links below).

We did also later get the interop with the Freertr implementation,
tho in my initial report below we hadn't got there yet:
https://lists.geant.org/sympa/arc/multicast-discuss/2022-03/msg00030.html

HTH.

-Jake

On 03-20, 12:34 PM, "Holland, Jake" <[e-mail]> wrote:

Hi guys,

I wanted to report I got IPv6 working.

I was on the irc but it didn't work very well for reaching the
freertr team during the hackathon.  However, I had plenty to do,
even though we never connected for the interop testing during the
weekend, and I think this should make it possible for people to
try some interop v4 and v6 testing when they can get to it.  So
here's my hackathon report.

I checked in an update to amtgw that got ipv6 working inside the
docker container, and put some instructions at the bottom of the
README here, adding commands showing how to run v4 in v6, v6 in
v4, and v6 in v6:
https://github.com/GrumpyOldTroll/amt

Hopefully this means going forward there's at least a few cases
where IPv6 isn't a second-class citizen.

As of now I've got an IPv4 and an IPv6 sender with some public
domain classical music playing, each reachable by both an IPv4 and
an IPv6 AMT tunnels.  I've gotten music playing locally with each
stream, and I've seen data transfer of each over both v4 and v6
tunnels (from my house I could only play the music over the v4
tunnel, but running a gateway from an aws instance with v6
connectivity I could see the data transfer over a v6 tunnel, tho I
didn't have a speaker to listen to the music from there). 

The streams are coming from the eu-central-1 AWS region in
Frankfurt, so they should hopefully be decent in Vienna.  When
there's loss they do get a bit flaky, and you might have to kill
and re-run vlc occasionally.  I'm running the sender like this:
ffmpeg -re -i "$v" -af aresample=async=1 -acodec aac -f mpegts udp://[ff3e::800a:a02]:12000?pkt_size=1316

(That's going to a veth pair interface on the sender with 2
instances of https://github.com/GrumpyOldTroll/amtrelayd running
in front, one with a v6 config and one with a v4 config for the
tunnel.)

To get your tunnels working, in theory any valid gateway should
work and I look forward to hearing more about the FreeRTR gateway
if anyone gets a chance to connect, or if they get a chance to try
this gateway image against the relays.  But what I've mostly run
had a grumpyoldtroll/amtgw gateway instance running on the same
device as the player, and looks like this:

<NB>
Make sure to "docker pull grumpyoldtroll/amtgw" if you have an
old amtgw image loaded, and as the README explains, make sure to
enable v6 for your container with something like:

~~~
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "ipv6": true,
  "fixed-cidr-v6": "$(python3 -c 'import os; import ipaddress; print(ipaddress.ip_network("fd%s:%s%s:%s%s::/64"%tuple("%02x"%b for b in os.urandom(5))))')"
}
EOF
sudo systemctl reload docker
~~~

And for v6 tunnels, you'll have to also map your external address
to the v6 addresses used for the AMT tunnel for the docker container,
which I've seen working with v6 nat:

~~~
DKRNET=$(grep fixed-cidr-v6 /etc/docker/daemon.json | awk '{print $2;}' | sed -e 's/"\([^"]*\)"/\1/')
sudo ip6tables -t nat -A POSTROUTING -s ${DKRNET} ! -o docker0 -j MASQUERADE
~~~

It also may be possible for some systems to get something to run
with --host networking, like Andrew tried, but I doubt it in general*.
</NB>

For v6 data:
sudo ip -6 route add ff3e::/16 dev docker0 table local

- In a v4 tunnel:
docker run -d --privileged --rm --name amt grumpyoldtroll/amtgw \
   -d 6 -t 4 $(python3 libmcrx/driad.py -f 4 2600:14e0::6)

- In a v6 tunnel:
docker run -d --privileged --rm --name amt grumpyoldtroll/amtgw \
   -d 6 -t 6 $(python3 libmcrx/driad.py -f 6 2600:14e0::6)

- Then to play the music:
vlc udp://[2600:14e0::6]@[ff3e::800a:a02]:12000


For v4 data:
sudo ip -4 route add 232.0.0.0/8 dev docker0

- In a v4 tunnel:
docker run -d --privileged --rm --name amt grumpyoldtroll/amtgw \
   -d 4 -t 4 $(python3 libmcrx/driad.py -f 4 23.212.185.6)

- In a v6 tunnel:
docker run -d --privileged --rm --name amt grumpyoldtroll/amtgw \
   -d 4 -t 6 $(python3 libmcrx/driad.py -f 6 23.212.185.6)

- Then to play the music:
vlc udp://23.212.185.6@232.10.10.2:12000


You can also do lower-rate (1pps, 1kbps) testing of your
connectivity with the mcrx-check program from libmcrx, over the
same tunnels.  Sometimes this is easier than vlc, to me, and
reports packets received which is nicer than hoping for music for
checking pure connectivity.  The way to build and run it is:

git clone https://github.com/GrumpyOldTroll/libmcrx
cd libmcrx; ./autogen.sh ; ./configure; make

~/libmcrx/mcrx-check -g 232.1.1.1 -p 5001 -s 23.212.185.6 -c 0 -d 0 -v
~/libmcrx/mcrx-check -g ff3e::8000:1 -p 5001 -s 2600:14e0::6 -c 0 -d 0 -v

Unlike vlc, these use a route to the source IP instead of the route
for the group IP to determine which interface the join should go on.
(You can also pass -i <interface> to override, which might be useful
if you need to check for routing troubles.)

Anyway, HTH, and that's my hackathon report.  If anyone has trouble
connecting to the senders or getting any of this stuff working,
please don't hesitate to reach out, and lmk if we should make some
time to do any interop together.  Maybe give another gateway a go and
send me a pcap if it's broken?  I'm also happy to get you server-side
pcaps and maybe some troubleshooting if that's helpful.

Cheers,
Jake

*: I think the container looks for interfaces named eth1 and eth0
and makes assumptions about them, with eth0 being always used for the
tunnel and eth1 being used for the native multicast if it's present,
otherwise eth0.  (The way it's designed to work is to connect an extra
interface to the container with a macvlan docker network that's
connected to a physical port, so that the native multicast traffic
hooks up there, and the name of the docker network can't be "amt"
because it has to be lexically later than "bridge" in order to get
tied to eth1.  But you might be able to get something working with
--host for your docker container as long as you have an eth0 interface.)

On 03-14, 6:43 AM, "Tim Chown" <[e-mail]> wrote:

Hi,

I’ll ping the GEANT Ops about the multicast ingest.  That was on my list before, apologies.  I’ll do it now.  If Jake is available to assist with advice, great.

It’s a real shame that IPv6 is a 2nd class citizen in this.

Regarding “isolation”, I don’t think GEANT is isolated by I2 dropping multicast support, it’s Internet 2 sites that are isolated. Connectivity from GEANt elsewhere should be fine.

BTW GEANT people ar eon this list, but I persistently see list bounce warnings for them.  I’ll remind GEANT IT about this; something I presume makes it thinks its own list email to its own staff is spam :)

Tim

> On 11 Mar 2022, at 19:54, Holland, Jake <[e-mail]> wrote:
> 
> Hi Lenny,
> 
> I could easily be talked into deploying a multicast receive platform
> in GEANT instead with the hackathon time, if that's on the table.
> 
> I was thinking in terms of advancing the state of the code/solutions
> rather than standing up devices, since that seemed to be more in the
> spirit of the proposed project.  And I do have a need to get IPv6
> support running, though I also agree with your point that getting
> wider multicast delivery would be a more important thing to achieve
> in the near term.
> 
> So I'm game for either.  I don't want to derail anyone's plans, so
> I'm not pushing one way or the other for the context of this hackathon.
> 
> (With that said: I still do want to get a multicast ingest platform
> based on DRIAD deployed in GEANT before long, whether or not it's
> what we work on during the hackathon, but this can be a separate
> discussion as far as I'm concerned.)
> 
> -Jake
> 
> On 03-11, 11:46 AM, "Leonard Giuliano" <[e-mail]> wrote:
> 
> 
> <Combining threads>
> 
> While IPv6 support would be nice to have, I'm not sure it really advances 
> the ball in terms of functionality, while there still are significant 
> barriers.  Namely, all the existing relays on Internet2 (CAAREN, KANREN 
> and TJHS) are v4 only (Junos/MX unfortunately doesn't support AMT v6).  
> Also, VLC, which is the predominant AMT GW implementation is also v4 only.
> 
> TBH, there are probably some bigger issues that would seem to be more 
> critical to address.  Namely, that there is no mcast connectivity since 
> the Internet2 upgrade to a "new network," so CAAREN, KANREN, TJHS and 
> GEANT are all isolated.  This could be solved with a few simple GRE 
> tunnels, but what fun would that be when we have DRIAD, which could enable 
> tunnel dynamically.
> 
> Also, @Frederic, just to clarify, the Multicast Menu was developed by 
> Lauren, while the translation server was developed by Janus.  And Lauren 
> is working on Multicast Menu 2.0, which could include using AMT relays in 
> other networks (for example, RARE/GEANT) as well as APIs that could 
> hopefully make building new source entries much better.
> 
> On Fri, 11 Mar 2022, mc36 wrote:
> 
> |
> | amt over v6 and/or v6 over amt, yeahhh, sounds interesting...
> |
> 
> On Fri, 11 Mar 2022, Andrew Gallo wrote:
> 
> |
> | Hi Jake--
> |
> | We have the capability to source content over v6 as well as add v6 to
> | our relay (at least I think we can!)
> |
> | We should be able to help with interop/v6 testing.
> |
> | Thanks.
> 
> On Fri, 11 Mar 2022, Fr?d?ric LOUI wrote:
> 
> |
> | The multicast-menu item was just the possibility to update Janus 
> multicast-menu whenever freeRtr uni2multi server is translating a new 
> media stream into multicast.
> | This stream can then made available from freeRtr AMT relay or Juniper 
> AMT relay residing into GEANT RARE P4 lab BIER network.
> |
> | So we can use an API and in order to create/delete new entry into Janus' 
> menu
> |
> 
> 
> | On 3/11/22 16:12, Holland, Jake wrote:
> | > Hi RARE/FreeRtr team,
> | > 
> | > Thanks for setting up that project.
> | > 
> | > I won't make it to Vienna unfortunately.  I was planning to be
> | > there, but then broke my knee and shoulder, and I'm still
> | > recovering from the knee surgery and can't really travel.
> | > 
> | > I'd like to do a bit of AMT interop work with you guys if you're
> | > up for it, especially some IPv6 stuff.  I've got a few relays up
> | > reachable via IPv6 addresses, but don't yet have v6 traffic sources
> | > running and haven't gotten much testing done vs. even my gateway
> | > yet, but I'd like to get those operational if I can.
> | > 
> | > Will you be setting up a slack or some kind of chat channel during
> | > the hackathon?
> | > 
> | > Cheers,
> | > Jake
> | > 
> | >    On 03-10, 3:58 AM, "Tim Chown" <[e-mail]> wrote:
> | > 
> | > Hi Lenny,
> | > 
> | > We do have a RARE/FreeRtr entry into the hackathon - see
> | > https://urldefense.com/v3/__https://trac.ietf.org/trac/ietf/meeting/wiki/113hackathon__;!!NEt6yMaO-gk!QC5JPJNclObMzdbQJ5_QvZMFZWx_5bIJVAv_DUUOQ1osjzzoNrPSKIgZV1xsyWk$
> | > where we have 6 people listed as    champions    and both BIER and AMT are
> | > listed in the    menu    of potential work.  I think you can edit that when
> | > signed in with a data tracker account.
> | > 
> | > I   m not in Vienna, and my weekend may be lost to other matters, but please
> | > do consider some collaboration.  I believe at least Simon and Csaba will be
> | > there in person.  Maybe the thing we do can mix o and off site functions, or
> | > rather it probably will have to.
> | > 
> | > Tim
> | > 
> | > > On 9 Mar 2022, at 03:02, Leonard Giuliano <[e-mail]> wrote:
> | > > 
> | > > 
> | > > Folks- back in Jan, I recall we came up with a plan for the next IETF
> | > > hackathon.  Well, the hackathon is coming up (Mar 19-20).  IIRC, the idea
> | > > was to inject sources into Janus' unicast-translator at GWU, have those
> | > > generate new source entries on the Multicast Menu, then use DRIAD to build
> | > > an AMT tunnel from an AMT GW in RARENet to the AMT Relay at GWU, transit
> | > > the RARE BIER network to another AMT Relay on RARE, and then have
> | > > receivers join via that relay.  That seemed to cover each of our pet
> | > > projects.
> | > > 
> | > > LMK if that sounds right and if anyone is up for trying it out at the
> | > > hackathon?
> | > > 
> | > > 
> | > > -Lenny
> | > > 
> | > > 
> | > > On Thu, 20 Jan 2022, Leonard Giuliano wrote:
> | > > 
> | > > |
> | > > | @Frederic- thanks for the excellent synopsis of your testbed.  I have
> | > > this
> | > > | email saved for anyone I run into who asks about this.
> | > > |
> | > > | @Janus- your idea about the privacy benefits of this "decentralized
> | > > | twitch" idea is a great one that I think can gain traction.  Thanks for
> | > > | sharing.
> | > > |
> | > > | Great conversation yesterday with everyone.
> | > > |
> | > > |
> | > > | -Lenny
> | > > |
> | > > |
> | > > | On Wed, 19 Jan 2022, Fr?d?ric LOUI wrote:
> | > > |
> | > > | |
> | > > | |
> | > > | | Well actually mc36 had this brilliant idea to implement this uni2multi
> | > > server based on Leny?s unicast 2 multicast translator demo.
> | > > | |
> | > > | | Basically, the hack was to recycle "nat translation" code and
> | > > translate the "Interesting / matching" traffic to a (S,G)
> | > > | |
> | > > | | Sample of confirmation in par0101:
> | > > | |
> | > > | | !
> | > > | | server uni2multi u2m
> | > > | |  access-log
> | > > | |  access-rate 10 1000
> | > > | |  access-total 256
> | > > | |  access-subnet 8
> | > > | |  source interface sdn1.666
> | > > | |  target ipv4 232.123.0.0/16
> | > > | |  target ipv6 ff39:232:123::/64
> | > > | |  logging
> | > > | |  interface sdn1.666
> | > > | |  vrf CLEARNET
> | > > | |  exit
> | > > | | !
> | > > | |
> | > > | | So basically embedding this translation function make the P4 lab a ?
> | > > broadcast yourself ? network:
> | > > | | 1- By providing a way to stream
> | > > | | 2- By letting receivers (within non native multicast) to receive the
> | > > stream via AMT relay.
> | > > | |
> | > > | | Now the main difficult part is to make application aware of that new
> | > > streams.
> | > > | | New streams can be found here:
> | > > | |
> | > > | |
> | > > https://urldefense.com/v3/__http://mcast-menu.par.geant.org/__;!!NEt6yMaO-gk!QNgkE2_OJnf1zXmD_cRkZ6thmItRtZmVbb9wLy7U0oHp91LgY_bVT1kbeonTqOw$
> | > > | |
> | > > https://urldefense.com/v3/__http://mcast-menu.pra.geant.org/__;!!NEt6yMaO-gk!QNgkE2_OJnf1zXmD_cRkZ6thmItRtZmVbb9wLy7U0oHp91LgY_bVT1kbUOOnSsA$
> | > > | |
> | > > | | The p4lab is here: (topology retrieved by BGP-LS)
> | > > | |
> | > > https://urldefense.com/v3/__http://gp4l.geant.org/__;!!NEt6yMaO-gk!QNgkE2_OJnf1zXmD_cRkZ6thmItRtZmVbb9wLy7U0oHp91LgY_bVT1kbDmLRBdc$
> | > > | |
> | > > | | PAR0101 has a public interface and can server as a unicast 2 multicast
> | > > translator but also as a amt-relay.
> | > > | |
> | > > | | You can try to use the translator using this alias:
> | > > mcast-menu.par.geant.org
> | > > | |
> | > > | | And it will be automatically translated to multicast visible at the
> | > > the same address:
> | > > | | mcast-menu.par.geant.org
> | > > | |
> | > > | | Then via
> | > > https://urldefense.com/v3/__http://amt-relay.geant.org/__;!!NEt6yMaO-gk!QNgkE2_OJnf1zXmD_cRkZ6thmItRtZmVbb9wLy7U0oHp91LgY_bVT1kbotWFj84$
> | > > you can check you are receiving the translated stream.
> | > > | | Of course you?ll spot that the amt-relay is also on the same node.
> | > > | |
> | > > | | An improvement would be:
> | > > | |
> | > > | | 1- Separate amt-relay and / uni2multi server
> | > > | | 2- Add junos AMT relay in p4lab so we check interoperability
> | > > | | 3- ingest traffic from external domain
> | > > | | 4- make multicast traffic ingested by external domain
> | > > | | 5- Notify external global menu whenever new stream is translated to
> | > > multicast.(and stream removal)
> | > > | | 6- Test IPv6 translation (is IPv4 unicast -> IPv6 (S,G) multicast is
> | > > interesting ans vice versa ?)
> | > > | |
> | > > | | Embedding the translator in the router can be seen as a network turn
> | > > key solution
> | > > | | So it would be a sort worldwide ? broadcast yourself decentralised ?
> | > > multicast network service.
> | > > | |
> | > > | | Then on top of this service, content application can leverage this
> | > > (from accounting/monetization KPI perspective)
> | > > | | but the good news is that traffic inside ISP will be kept low
> | > > | |
> | > > | | > Please excuse me if this is a silly question
> | > > | |
> | > > | | There is no silly question and yes the AMT and the translator is
> | > > globally reachable.
> | > > | |
> | > > | | Please test our uni2multi server and also teh AMT-relay. You will find
> | > > relevant information here:
> | > > | |
> | > > https://urldefense.com/v3/__http://mcast-menu.par.geant.org/__;!!NEt6yMaO-gk!QNgkE2_OJnf1zXmD_cRkZ6thmItRtZmVbb9wLy7U0oHp91LgY_bVT1kbeonTqOw$
> | > > | |
> | > > | |
> | > > | | > Le 19 janv. 2022 ? 19:01, Janus Varmarken <[e-mail]> a ?crit
> | > > :
> | > > | | >
> | > > | | > (replying here to not spam everyone on the mailing list)
> | > > | | >
> | > > | | > Hello everyone,
> | > > | | >
> | > > | | > Thanks for letting me sit in for your discussion today. It's some
> | > > really impressive work you're doing.
> | > > | | >
> | > > | | > @Frederic: Lenny and I weren't aware that you already had a
> | > > unicast-to-multicast translation service running, very cool! If you want,
> | > > you can use the code I wrote for our implementation to have yours submit
> | > > entries to Lauren Delwiche's Multicast Menu as well (whenever a new
> | > > unicast-to-multicast translation starts). Here's a permalink to that part
> | > > of the code (the _add_to_multicast_menu function):
> | > > https://urldefense.com/v3/__https://github.com/JNPRAutomate/unicast2multicast-translator/blob/d400d71745eec8f5ae7933be54a5505460173dea/translator.py*L239__;Iw!!NEt6yMaO-gk!QNgkE2_OJnf1zXmD_cRkZ6thmItRtZmVbb9wLy7U0oHp91LgY_bVT1kb0KzPM9k$
> | > > (AFAIK, Lauren will include an API in the next version of the Multicast
> | > > Menu s.t. you don't have to rely on this kind of form submission hack in
> | > > the future.)
> | > > | | > Please excuse me if this is a silly question, but one thing I didn't
> | > > catch from the discussion was whether the network where you run your
> | > > translator (P4?) is globally reachable, or if it is a private/closed/test
> | > > network, and if there's an AMT relay or not. I think Lenny would like to
> | > > limit listings on the Multicast Menu to only be streams that are globally
> | > > reachable through AMT, but I'll leave this to Lenny.
> | > > | | >
> | > > | | > @All: On the motivation/selling points for a "decentralized twitch":
> | > > I think you can also argue that such decentralization may (indirectly)
> | > > contribute positively to user privacy, as many of the centralized Internet
> | > > services (including twitch) that consumers enjoy are "paid for" by
> | > > consumers allowing the operator of said services to collect, analyze,
> | > > and/or sell data about their users.
> | > > | | >
> | > > | | > Best,
> | > > | | > Janus
> | > > | | >
> | > > | | > On Wed, Jan 12, 2022 at 1:24 AM Tim Chown <[e-mail]>
> | > > wrote:
> | > > | | > Hi,
> | > > | | >
> | > > | | > An invite for our ZOOM call on 17th Jan at 5pm CET / 4pm UTC:
> | > > | | >
> | > > | | >
> | > > https://urldefense.com/v3/__https://jisc.zoom.us/j/99563770580?pwd=K3Z5LzdNNWNrL2I0ZUw0Rm03dWkyUT09__;!!GjvTz_vk!HOAYNdW7lJF0cnqiJQWaxcnIXEd7vJwclmnqSRyJzrTzLdEl5BkR6kRXMin8XA0$
> | > > | | >
> | > > | | > I've invited those who responded to the doodle, but have also
> | > > forwarded the Zoom details to the multicast-discuss list.
> | > > | | >
> | > > | | > Tim
> | > > | | >
> | > > | | >
> | > > | | > --
> | > > | | > Janus Varmarken
> | > > | | > Ph.D. Student, Networked Systems
> | > > | | > University of California, Irvine
> | > > | | >
> | > > https://urldefense.com/v3/__https://varmarken.com__;!!NEt6yMaO-gk!QNgkE2_OJnf1zXmD_cRkZ6thmItRtZmVbb9wLy7U0oHp91LgY_bVT1kbuG6VRcg$
> | > > | |
> | > > | |
> | > > |
> | > 
> | > 
> | 
>