Subject: [icnrg] Discussions at mboned

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 27 Mar 2020 09:58:25 +0100

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

---

From: "Milheiro Mendes, Paulo Jorge" <[email-masked]>
Date: Fri, 27 Mar 2020 10:18:33 +0100

Hi Matthias,

That makes a lot of sense :)

Paulo

On Fri, Mar 27, 2020 at 9:58 AM Matthias Waehlisch <[email-masked]>
wrote:

> .... didn't know that Akamai is working on multicast to the browser. why
> ..  Freie Universitaet Berlin, Computer Science
> ... http://www.cs.fu-berlin.de/~waehl
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

-- 

*Paulo Mendes, Ph.D*

Senior Scientistic Wireless Communications

Central Research and Technology, XRC

*Airbus*
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

---

From: Luca Muscariello <[email-masked]>
Date: Fri, 27 Mar 2020 11:55:13 +0100

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