Re: [icnrg] Discussions at mboned

Join and leave a multicast group is available in chrome since a lot of
time,
at least five years. The challenge is not reaching the browser for multicast
per se. There are though several outstanding challenges both at the network
and application layer. The former are the well known problems for multicast
for in terms of data plane and control plane, including scaling and
management.

The latter are more complex in my opinion. Mapping rate adaption, multiple
quality layers, both for ABR but also simulcast for real-time is not simple
and AFAIK an ill defined problem. Multiple multicast trees? How do you jump
from one tree to another? Is it stable? Is it unstable? Can it be
stabilized?
These solutions manage losses using FEC and do not really manage congestion
otherwise you have to fall back to unicast to recover losses.

How do you go through WiFi as 80% of the desktops are using WiFi? The answer
cannot be to continue on the wireless hop using multicast in 802.11 as it
is
ever more complex than the previous problem. So multicast is not e2e.

Akamai has done HTTP over IP multicast since several years ago from the
Akamai
Telco CDN product to the setup box. The Telco CDN product was called Aura
Lumen
and the HTTP mapping (request/reply)is proprietary
and patented by Akamai. Last time I checked this what I was at Orange only
HTTP
replies where send in multicast. Non multicast enabled clients could use
AMT to
a GW, the Home GW to receive unicast.

When we have mapped HTTP over hICN we had to solve a similar problem but
in a different way.

In the thread you shared Matthias, they discussed about real-time as well
for on-line meetings.
I'm sure old farts in this list may remember VIC, VAT and WB on MBONE, the
first
video-conference tool with audio/video and a white board, developed at
Berkeley
by Van Jacobson. https://ee.lbl.gov/vat

We have shown a demo of Jitsi over hICN at one ICNRG meeting, both media
bridge
and stand alone client. It fits very well to simulcast and rate adaptation
as
again most clients connect via WiFi. Bonus, if the client is multi-homed
(WiFi + Cellular)
it continues to work. I do not see this coming with multicast.

Compared to multicast, in hICN there is no need to tunnel multicast to
unicast as
the distribution adapts to the workload. Network-wise no need to have a
different
control plane unicast/multicast and no need to maintain an independent
multicast
network, because a single hICN node can be transparelty installed in a
place where
there is congestion to alleviate: GW, PoPs, transit, colo, branches in
addition to
the end-points.

Congestion control also looks better as flow-balance to the hICN box is
simpler
to manage.

BTW it is open source https://wiki.fd.io/view/HICN

Luca

On Fri, Mar 27, 2020 at 9:58 AM Matthias Waehlisch <m.waehlisch@fu-berlin.de>
wrote:

>
> Interesting discussions at MBONE Deployment WG:
> https://mailarchive.ietf.org/arch/msg/mboned/G13mUJTyG7TQ_tSnscB1SWEsOjw/
>
> not surprising, some relate to challenges in ICN, e.g., dynamic state
> management.
>
> .... didn't know that Akamai is working on multicast to the browser. why
> not ICN to the browser ;).
>
>
>
> cheers
>   matthias
>
>
> --
> Matthias Waehlisch
> ..  Freie Universitaet Berlin, Computer Science
> ... http://www.cs.fu-berlin.de/~waehl
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
>