Subject: [MBONED] MBONE Deployment (mboned) WG Virtual Meeting: 2020-04-21

From: IESG Secretary <[email-masked]>
Date: Mon, 23 Mar 2020 10:26:00 -0700

The MBONE Deployment (mboned) Working Group will hold
a virtual interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles.

Agenda:
Would like to meet jointly with PIM WG.

Information about remote participation:
Remote participation information will be obtained at the time of approval

---

From: Randy Bush <[email-masked]>
Date: Mon, 23 Mar 2020 19:20:03 -0700

> The MBONE Deployment (mboned) Working Group will hold a virtual
> interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles.

and what technology will it use for this meeting?  maybe that will tell
us something.

randy

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 26 Mar 2020 11:37:41 -0700

Webex, as it appears to be the tool of choice for the virtual interims.  
We will share the same webex session with PIM.

Was this supposed to be a trick question, Randy?  If so, not quite 
following.

On Mon, 23 Mar 2020, Randy Bush wrote:

| > The MBONE Deployment (mboned) Working Group will hold a virtual
| > interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles.
| 
| and what technology will it use for this meeting?  maybe that will tell
| us something.
| 
| randy
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!RVFp88OAvt-kyfeTJn4raI0K19Ozji1Yn-rORvbRZmjgDQPkhjcOGbknPE691JA$ 
|

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Mar 2020 11:48:08 -0700

[ ietf list removed from cc: ]

>> and what technology will it use for this meeting?  maybe that will tell

twenty years ago, we used multicast to participate remotely in ietf
meetings.  i used it to participate in a conference remotely while
i was incapacitated.  for the time, it worked.

now mboned does not even eat its own dogfood.

we learned a lot when v6ops used the nat64 ssid at a (f2f) meeting.

the world seems to have gone to zoom.  the ietf is using webex (no shock
there, considering).

resources will become more and more scarce.  multicast should think
about stepping up or stepping out.

randy

---

From: Ole Jacobsen <[email-masked]>
Date: Thu, 26 Mar 2020 11:54:16 -0700

A long, long time ago in an IETF far away, we used the actual MBONE
as our remote participation tool (vic, vat, anyone?). I suspect Randy
is just musing about the Good Old Days.

> On 26 Mar 2020, at 11:37, Leonard Giuliano <lenny=[email-masked]> wrote:
> 
> 

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Web: protocoljournal.org
E-mail: [email-masked]
E-mail: [email-masked]
Skype: organdemo

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 12:44:00 -0700

Some of us have been working on overlay solutions to bring multicast right to your desktop without you needing native multicast. In fact, we could even bring IPv6 multicast to your desktop.

Lenny et al, I think we should try this out either for the next interim, or for the next IETF, or for anything else. We can do this over the top from the WG and participant perspective and don’t need to get IETF IT involved. 

That is kinda the spirit of overlays.

The first order of business is to decide what apps are convienent for folks to use.

I am available to help, offer services, and whatever is necessary to get this done.

Who is interested?

Dino

> On Mar 26, 2020, at 11:48 AM, Randy Bush <[email-masked]> wrote:
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Mar 2020 12:45:36 -0700

i volunteer to be a victim, as usual.

not sure if there are vic, vat, ... for a mac :)

randy

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 12:55:39 -0700

> i volunteer to be a victim, as usual.

Ah, that would be great. Thanks. 

> not sure if there are vic, vat, ... for a mac :)

That’s a great idea. We can start with the multicast apps and run them from a WG participant’s laptop and have others join from where-ever and get the audio and video feed. But I’d like it to work on phones too.

Maybe we go with VLC because you can get it on all platforms. Especially in receiver mode.

But I’ll look into vic and vat. I want to consider Zoom as well. I’ll talk to the Zoom guys to see if they have multicast support or are close to having it.

Dino

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 26 Mar 2020 12:59:08 -0700

> now mboned does not even eat its own dogfood.

Randy,

I don't remember the last time you came to an MBONED WG meeting. You're
welcome anytime.

Cheers,
Shep

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 26 Mar 2020 13:00:09 -0700

[re-combining threads]

Ahh yes, the disappointment of having IETF go backwards on this technology 
occurred so long ago that I missed the irony...

Indeed, would be nice to go back to the future when IETF meetings used the 
MBONE.  In fact, you may recall we approached the IETF network and 
Meetecho teams last year about this.  The network support is there on the 
Internet today- we have several public AMT relays deployed to deliver 
multicast streams from the MBONE to Internet users on unicast-only 
networks.  VLC now has AMT GW support.  Multicast capabilities in other 
apps doesn't appear to be available, and support/encouragement from the 
IETF (as it has for v6 over the years) would certainly help.  Any 
suggestions for how to accomplish that would be welcome, as last year's 
attempt didn't get very far.

The current global situation is pushing the need for solutions that enable 
people to gather virtually (distance learning, worship services, movie 
watch parties, drinks with friends, WG meetings, etc), which illustrates 
the value and role to play for multicast.

In MBONED, we've adopted work to bring multicast to the browser, which 
will help with app layer support.  We have deprecated the use of 
interdomain ASM to mandate SSM and eliminate most of the complexity of 
deploying multicast.  We'd love more folks to deploy AMT relays.  

We welcome others to join us and share ideas they have to help the effort.

On Thu, 26 Mar 2020, Randy Bush wrote:

|
| [ ietf list removed from cc: ]
|
| > Webex, as it appears to be the tool of choice for the virtual 
interims.
| > We will share the same webex session with PIM.
| >
| > Was this supposed to be a trick question, Randy?  If so, not quite
| > following.
| >
| >>> The MBONE Deployment (mboned) Working Group will hold a virtual
| >>> interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles.
| >> and what technology will it use for this meeting?  maybe that will tell
| >> us something.
|
| twenty years ago, we used multicast to participate remotely in ietf 
| meetings.  i used it to participate in a conference remotely while i was 
| incapacitated.  for the time, it worked.
|
| now mboned does not even eat its own dogfood.
|
| we learned a lot when v6ops used the nat64 ssid at a (f2f) meeting.
|
| the world seems to have gone to zoom.  the ietf is using webex (no shock 
| there, considering).
|
| resources will become more and more scarce.  multicast should think 
| about stepping up or stepping out.
|
| randy
|

On Thu, 26 Mar 2020, Ole Jacobsen wrote:

| 
| 
| A long, long time ago in an IETF far away, we used the actual MBONE
| as our remote participation tool (vic, vat, anyone?). I suspect Randy
| is just musing about the Good Old Days.
| 
| 
| > On 26 Mar 2020, at 11:37, Leonard Giuliano <lenny=[email-masked]> wrote:
| >
| >
| > Webex, as it appears to be the tool of choice for the virtual interims.
| > We will share the same webex session with PIM.
| >
| > Was this supposed to be a trick question, Randy?  If so, not quite
| > following.
| >
| >
| > On Mon, 23 Mar 2020, Randy Bush wrote:
| >
| > | > The MBONE Deployment (mboned) Working Group will hold a virtual
| > | > interim meeting on 2020-04-21 from 09:00 to 11:00 America/Los_Angeles.
| > |
| > | and what technology will it use for this meeting?  maybe that will tell
| > | us something.
| > |
| > | randy
| > |
| > | _______________________________________________
| > | MBONED mailing list
| > | [email-masked]
| 
| Ole J. Jacobsen
| Editor and Publisher
| The Internet Protocol Journal
| Office: +1 415-550-9433
| Cell:   +1 415-370-4628
| Web: protocoljournal.org
| E-mail: [email-masked]
| E-mail: [email-masked]
| Skype: organdemo
|

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Mar 2020 13:05:54 -0700

> I don't remember the last time you came to an MBONED WG
> meeting. You're welcome anytime.

shep

i love you guys, but i see mboned as one of many demonstrations that
multicast is not an operationally realistic approach.

i am willing to be shown to be wrong, i.e. test as a user.  but i am not
likely to spend time trying to make the protocols and apps work.  i have
two full time day jobs.

randy

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 13:18:06 -0700

> multicast is not an operationally realistic approach.

It will scale better from an application point of view, and it has shown how the app cloud providers (Zoom and Webex have to capacity plan at the app and resource level) to handle the current load on the Internet.

The problem now, and which has already been the case, the inter-domain network layer is hard to upgrade and maintain. Not just technology wise (enabling multicast) but maintaining router infrastructure in general.

We have all seen the days where “its easier to upgrade routers than hosts” has turned on its head.

> likely to spend time trying to make the protocols and apps work.  i have

Its not a question of right or wrong. And you can’t argue against an app sending one packet for n receivers scales better than sending n packets. So the fundamental idea works. The intellectual (and pragmatic) question to ask is where should replication happen.

I think we NOW live in a world where we need a combination of replication at the network layer, overlay layer, and app layer. And deployment teaches us where it is more cost effective.

Zoom, Webex, Google Meetings, Skype replicate at the app layer in the cloud because THEY CAN CONTROL THE ENTIRE user experience.

Dino

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Mar 2020 13:21:14 -0700

> support/encouragement from the IETF (as it has for v6 over the years)
> would certainly help.

after all, it has so wonderfully helped ipv6 deployment.

screw the ietf.  get a set of usable tools actually working, in the
hands of ops and users, and push until they are really usable and
scalable.  think about how zoom just wiped webex, teams, and hangouts
off the playing field.  low barrier to user entry, user simplicity, and
it just works.

first, eat your own dogfood.  then get a set of test users.  i am in a
number of research groups, and academia is hitting scaling problems with
zoom etc.  speaking of which, how is (S, G) gonna scale if you were to
haev to support many thousands of users, meetings, ...?

> The current global situation is pushing the need for solutions that
> enable people to gather virtually (distance learning, worship
> services, movie watch parties, drinks with friends, WG meetings, etc),
> which illustrates the value and role to play for multicast.

oh, there's a hole.  the skill will be in filling it.

randy

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 13:24:46 -0700

> haev to support many thousands of users, meetings, ...?

An (S,G) entry is a route. You know modern routers can support many orders of magnitude of 1000 routes. I am answering your question of scale in terms of number of routes. If you mean something else, than just say so.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 13:26:57 -0700

> deploying multicast.  We'd love more folks to deploy AMT relays.  

So can you right now give us a URL, where we can paste into our browser to see some content?

This is not a technology problem. This is a lack of product problem.

Din

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 26 Mar 2020 13:40:53 -0700

> This is not a technology problem. This is a lack of product problem.

..or a reasonable assumption of a workable timeframe. 'Adopted' in the WG
as you know is early in the process. Fortunately the effort behind all or
this has come from Jake Holland at Akamai, and he has been developing the
solution components, and demonstrating code at IETF Hack-a-thon for more
than a year now.

Start here:
https://datatracker.ietf.org/meeting/106/materials/slides-106-mboned-multicast-to-the-browser-00.pdf

Cheers,
Shep

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 13:46:44 -0700

> ..or a reasonable assumption of a workable timeframe. 'Adopted' in the WG as you know is early in the process. Fortunately the effort behind all or this has come from Jake Holland at Akamai, and he has been developing the solution components, and demonstrating code at IETF Hack-a-thon for more than a year now. 
> 
> Start here:

I have said it multiple times, and even to Jake himself, he is doing a great job. And I am encouraging and reviewing his designs.

But he is creating new technology more than a product. And an effort that needs to get done. He is solving hard problems at the network layer like congestion control and authentication. Even more kudos.

Maybe Akamai may want to productize this and that would be wonderful!

Dino

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 26 Mar 2020 20:55:09 +0000

We tried. Given lockdown moves people to a lot more few-to-many sessions,
some multicast in the mix would sure match supply to demand a bit better ..

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 14:16:26 -0700

> We tried. Given lockdown moves people to a lot more few-to-many sessions, some multicast in the mix would sure match supply to demand a bit better ..

Can you say more about what you tried?

Dino

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 26 Mar 2020 21:25:26 +0000

Dino Farinacci wrote on 26/03/2020 20:24:
> An (S,G) entry is a route. You know modern routers can support many
> orders of magnitude of 1000 routes. I am answering your question of
> scale in terms of number of routes. If you mean something else, than
> just say so.

this is kinda the problem though: multicast resource usage on 
intermediate routers scales according to the number of sessions going 
through those routers.  The more sessions, the more state that the 
routers need to maintain.  This is fundamentally different from unicast 
where it doesn't matter to the router how many sessions or data flows 
are passing through it.

We tried session based routing years ago.  It was an interesting idea at 
the time but it didn't work at scale.

Nick

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 14:30:25 -0700

> this is kinda the problem though: multicast resource usage on intermediate routers scales according to the number of sessions going through those routers.  The more sessions, the more state that the routers need to maintain.  

I don’t see it that way. If there are 100,000 sessions going on that is 100,000 in a subset of all core routers. A BGP router has 100,000 in every core router. Just to compare. So with multicast routing, you have an opportunity to have less state.

But we are only talking about one dimension of scaling.

> This is fundamentally different from unicast where it doesn't matter to the router how many sessions or data flows are passing through it.

State is state, doesn’t matter how it is created.

> We tried session based routing years ago.  It was an interesting idea at the time but it didn't work at scale.
> 
> Nick

And with overlays you can reduce the state even more at the expense of 'non-perfect replication”.

What is the definition of “non-perfect replication”. When a device has to replicate packets that may traverse over the same outgoing interface. 

What is the definition of “perfect replication”. When a device, typically a high-speed router, replicates packets where it is guaranteed that packet doesn’t go multiple times over that interface. And total perfection, the packet doesn’t traverse over its internal backplane more than once.

Dino

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 26 Mar 2020 14:30:44 -0700

> the time but it didn't work at scale.

Yes, and your IGP won't scale globally either. Fortunately solutions evolve
so we don't need to just bash the past.

https://datatracker.ietf.org/doc/rfc8279/

- Shep

> ____________________________________________
> MBONED mailing list
> [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Mar 2020 14:31:20 -0700

> through those routers.

churn due to 1.3 jillion sessions starting and stopping at arbitrary
times.  but on the top of the hour is a concentration.

would love some analytics from zoom, which seems to be the conference
system of coice this season of the plague

randy

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 14:35:56 -0700

> times.  but on the top of the hour is a concentration.

You either keep the state there so there is no malloc()/free() churn (like BGP), or your opportunistic to let that memory be used for other parts of the system (lower level tasks in the router) which needs memory.

> system of coice this season of the plague

They make it scale with people, continuous monitoring, and management tools. Just like Google, Facebook, and Amazon do behind the scenes.

Let’s face it Zoom uses IPv4 unicast with their great video/audio compression technologies with a great user interface. They got it right because it was their second time building the same product.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Mar 2020 14:37:50 -0700

> Let’s face it Zoom uses IPv4 unicast with their great video/audio compression technologies with a great user interface. They got it right because it was their second time building the same product.

And I left out one more kudos. They made their UI look relatively the same and supported on 5 platforms: web, MacOS, Windows, Andrioid, and iOS.

Dino

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 26 Mar 2020 22:14:07 +0000

> Maybe Akamai may want to productize this and that would be wonderful!

Yes, Akamai wants to productize multicast-based delivery for video and
downloads, at least.  There's a few hurdles left before I can just give
you a link though, still working thru them...

And thanks for the helpful reviews, Dino :)

-Jake

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 26 Mar 2020 23:08:03 +0000

someone port jit.si to multicast, and get a multicast prefix for "ironic" assigned
and our work here is done...

> That’s a great idea. We can start with the multicast apps and run them 
> from a WG participant’s laptop and have others join from where-ever and 
> get the audio and video feed. But I’d like it to work on phones too.
> 
> But I’ll look into vic and vat. I want to consider Zoom as well. I’ll 
> talk to the Zoom guys to see if they have multicast support or are close 
> to having it.
> 
> Dino
>