Subject: [icnrg] MAP-Me and pointer to old mobile multicast time

From: Matthias Waehlisch <[email-masked]>
Date: Sun, 18 Mar 2018 12:33:20 +0000

Hi Jordan et al.,

  first a clarification question: The basic idea of your approach is to 
extend the previous distribution tree and replace existing FIB states, 
by sending Interest Updates to the previous location of the producer. 
Right?

  This idea reminds me very much to a proposal we published more than 
ten yeas ago: "Morphing distribution trees---On the evolution of 
multicast states under mobility and an adaptive routing scheme for 
mobile SSM sources", 
http://ilab-pub.imp.fu-berlin.de/papers/sw-mdtem-06.pdf. Are you aware 
of this work?

  Key performance characteristics of such approaches depend on the delay 
to the intersection of the old and new tree, which heavily depends on 
the underlying topology.

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: Luca Muscariello <[email-masked]>
Date: Sun, 18 Mar 2018 13:20:19 +0000

The updated nodes are the following.

1) Say the producer moves  to a new PoA, 2)
Say that the routing plane is using shortest path routing,
3) then  take the shortest path between the new PoA and wherever the
routing plane points for this producer prefix

In this shortest path you have a series of nodes.
We update these nodes only.

Very different to the reference you have provided. MapMe is location
independent as it patches the current status of the routing plane to reach
the producer prefix.

Of course routing plane can do something different to shortest path. It is
an example.
The point is that we take the series of nodes in the path that the routing
plane provides autonomously.

On Sun 18 Mar 2018 at 12:33, Matthias Waehlisch <[email-masked]>
wrote:

> ..  Freie Universitaet Berlin, Computer Science
> ... http://www.cs.fu-berlin.de/~waehl
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 18 Mar 2018 14:26:46 +0000

Hi Luca,

> We update these nodes only.

Yep, this is an exact match of the "Phase1—Tree elongation" of the 
reference Matthias provided.

> independent as it patches the current status of the routing plane to 
> reach the producer prefix.
> 

Well, the difference between the Tree Morphing Protocol and Map-Me is 
that Tree Morphing has an additional convergences phase.

This is actually very important as routing in the wild cannot adequately 
handle mobility - an insight well known from the IP mobility days.

The problem of Map-Me is that it lacks this convergence phase - and 
actually cannot inherit from the Tree Morphing, as the 
Reverse-Path-Forwarding-Check does not work in ICN (no source addresses).

So convergence is outsourced to routing, which never converges once 
rapid mobility is in place.

Cheers,
  Thomas

> Of course routing plane can do something different to shortest path. It 
> is an example.
> The point is that we take the series of nodes in the path that the 
> routing plane provides autonomously.
> 
> On Sun 18 Mar 2018 at 12:33, Matthias Waehlisch 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Jordan et al.,
> 
>     ...  Freie Universitaet Berlin, Computer Science
>     .... http://www.cs.fu-berlin.de/~waehl
> 
>     [email-masked] <mailto:[email-masked]>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                  Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
° http://inet.haw-hamburg.de/members/schmidt      Fon: +49-40-42875-8452 °

---

From: "Giovanna Carofiglio (gcarofig)" <[email-masked]>
Date: Sun, 18 Mar 2018 14:30:08 +0000

Hi Thomas, 

MapMe does not re-compute paths, so there is no convergence here.
(it is acting on forwarding, not on routing.) 

Hope it helps.

Best,
Giovanna
________________________________________
From: icnrg <[email-masked]> on behalf of Thomas C. Schmidt <[email-masked]>
Sent: Sunday, March 18, 2018 3:26 PM
To: [email-masked]
Subject: Re: [icnrg] MAP-Me and pointer to old mobile multicast time

Hi Luca,

Cheers,
  Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 18 Mar 2018 14:39:30 +0000

Hi Giovanna,

> (it is acting on forwarding, not on routing.)

Yes, we perfectly agree.

However, if you want to manage (rapid) mobility well, then you need to 
recompute paths and fix the routing states. This is pretty obvious from 
observing that after mobility handover the links on a new (SP) 
distribution tree may be quite different from the links of the previous 
distribution tree.

More precisely: A link that has never been considered for forwarding 
before the movement may become central after the movement. This is 
basically the old problem of "Evolution of Multicast Trees under 
Mobility" - it has been thoroughly studied in the early two-thousands.

For a further reference, I would like to point you to RFC 5757 which 
explains a lot of the problems and features that seemed missing in 
Jordan's talk.

Cheers,
  Thomas

--

---

From: Jordan Augé <[email-masked]>
Date: Sun, 18 Mar 2018 14:40:55 +0000

Hi,

Let me jump into the conversation too since I think there are a few 
misconceptions about what MAP-Me is doing.

First, unlink i think the "tree elongation", we do not exactly aim at sending 
a message to the previous location, but instead we send a message with the 
producer's prefix name, which is routed using the FIB, and will eventually 
reach one of the previous locations. We do not target a locator. The 
difference is clear when you consider the case I illustrated about concurrent 
updates.

Then we have a very different objective wrt SSM mobility, as we do not want an 
optimal new tree. Instead, we are flipping edges on the existing tree for 
quick full reconnectivity. Or more generally, existing DAG in case of 
multipath. The fact that we use the existing tree for propagating 
signalization is what guarantees our stretch properties.

As you mentioned, what tree elongation is doing is not feasible (or at least 
not straightforward) in the present context, and that's the limit of the 
comparison. We instead do reverse path repair. This is usually done in IP for 
link failures, and has never been applied to mobility for the simple reason 
that in IP, the same IP does not pop up in another part of the network (or at 
least it is not advertised).

I think the confusion originates from the fact that you consider routing has 
to reconverge everytime the producer moves. In our proposal, router is not 
changed after mobility. Instead of triggering a routing update, we decide 
through some heuristic to send an Update, a Notification or a Routing update. 
Updates are thus used in between routing updates.

I hope this clarifies things a bit.

Cheers,
-- Jordan

> >        Key performance characteristics of such approaches depend on the
> >     
> >     delay

---

From: Matthias Waehlisch <[email-masked]>
Date: Sun, 18 Mar 2018 14:48:01 +0000

I don't know what you mean with "location independent". Obviously, the 
interest update is "forwarded according to the information stored in the 
FIBs of traversed routers towards previous locations" (see your paper). 

  Note that nobody is saying that the location is fixed, in the sense of 
a (MIP) home address. Sending an interest update towards the previous 
location is quite similar to sending a tree morphing update to the 
previous care of address.

Cheers
  matthias

On Sun, 18 Mar 2018, Luca Muscariello wrote:

> 3) then  take the shortest path between the new PoA and wherever the routing plane points for this
> producer prefix
> 
> Very different to the reference you have provided. MapMe is location independent as it patches the
> current status of the routing plane to reach the producer prefix.
> 
> Of course routing plane can do something different to shortest path. It is an example.
> The point is that we take the series of nodes in the path that the routing plane provides
> autonomously.
> 
> On Sun 18 Mar 2018 at 12:33, Matthias Waehlisch <[email-masked]> wrote:
>       Hi Jordan et al.,
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 18 Mar 2018 14:50:25 +0000

Hi Jordan,

the "producer prefix" plays the role of an "IP multicast address" (a 
multicast address is just a group application name).

Given this analogy, the objectives of "MAP-ME" and "Tree Morphing" are 
identical: Manage producer/sender mobility well by quickly adopting the 
distribution trees.

Cheers,
  thomas

--

---

From: Luca Muscariello <[email-masked]>
Date: Sun, 18 Mar 2018 15:50:39 +0100

I'm saying something very precise.
The update is sent using a location independent name.
It is not the locator of the previous point of attachement.

The update follows a name based FIB.
That's what it is meant with location independent.

CCN is about how you use the FIB not how you compute the RIB.
In MapMe we don't touch the RIB. There is not location information in the
update.

On Sun, Mar 18, 2018 at 3:48 PM, Matthias Waehlisch <
[email-masked]> wrote:

> independent as it patches the

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 18 Mar 2018 14:53:54 +0000

Luca,

"IP Multicast Addresses" are as location-independent as ICN prefixes.

ICN FIBs correspond to MFIBs.

So there is not much new in ICN here, when viewed from the 
producer/source mobility perspective.

Cheers,
  Thomas

On 18/03/2018 14:50, Luca Muscariello wrote:
> In MapMe we don't touch the RIB. There is not location information in 
> the update.
> 
> 
> 
> 
> 
> 
> On Sun, Mar 18, 2018 at 3:48 PM, Matthias Waehlisch 
>        I don't know what you mean with "location independent"..
>     Obviously, the
>     FIBs of traversed routers towards previous locations" (see your paper)..
> 
>      > http://ilab-pub.imp.fu-berlin.de/papers/sw-mdtem-06.pdf
>     <http://ilab-pub.imp.fu-berlin.de/papers/sw-mdtem-06.pdf>. Are you aware
>      >       of this work?
>      >
>     <http://www.cs.fu-berlin.de/~waehl>
>      >
>      > icnrg@irtf..org <mailto:[email-masked]>
>     <https://www.irtf.org/mailman/listinfo/icnrg>
>      >
>      >
>      >
> 
> 
>     --
>     Matthias Waehlisch
>     <http://www.cs.fu-berlin.de/~waehl>
> 
> 

--

---

From: Jordan Augé <[email-masked]>
Date: Sun, 18 Mar 2018 14:55:40 +0000

Hi,

> identical: Manage producer/sender mobility well by quickly adopting the

For sure we share this same objective (to the extent the analogy holds), but 
we have very different approaches in that you compute a new optimal tree, 
while we preserve the existing tree structure (don't include new edges for 
instance) for fast reconnectivity, at the price of small stretch. However we 
show that the way we do it keeps stretch bounded and very low.

-- Jordan

> > First, unlink i think the "tree elongation", we do not exactly aim at
> > sending a message to the previous location, but instead we send a message
> > with the producer's prefix name, which is routed using the FIB, and will
> > eventually reach one of the previous locations. We do not target a
> > locator. The difference is clear when you consider the case I illustrated
> > about concurrent updates.
> > 
> > Then we have a very different objective wrt SSM mobility, as we do not
> > want an optimal new tree. Instead, we are flipping edges on the existing
> > tree for quick full reconnectivity. Or more generally, existing DAG in
> > case of multipath. The fact that we use the existing tree for propagating
> > As you mentioned, what tree elongation is doing is not feasible (or at
> > least not straightforward) in the present context, and that's the limit
> > of the comparison. We instead do reverse path repair. This is usually
> > done in IP for link failures, and has never been applied to mobility for
> > the simple reason that in IP, the same IP does not pop up in another part
> > of the network (or at least it is not advertised).
> > 
> > I think the confusion originates from the fact that you consider routing
> > has to reconverge everytime the producer moves. In our proposal, router
> > is not changed after mobility. Instead of triggering a routing update, we
> > decide through some heuristic to send an Update, a Notification or a
> > Routing update. Updates are thus used in between routing updates.
> > 
> >>>         first a clarification question: The basic idea of your approach
> >>>         is
> >>>       
> >>>       to
> >>>

---

From: "Giovanna Carofiglio (gcarofig)" <[email-masked]>
Date: Sun, 18 Mar 2018 14:59:51 +0000

Thomas, 

there is a fundamental difference between our approach and all labelled as trace-based in 
http://web.cs.ucla.edu/~lixia/papers/1604NOM.pdf
(you can also look at the classification of approaches in our paper): 

- we do not recompute paths, we use name-based forwarding for updating the FIB info (or PIT info for other approaches) of a subset of routers in order to avoid loss or delay of in-flow packets in-between two routing updates. 

Nothing in common with the routing re-computation in the reference you mention.
No-recomputation of paths, no routing re-convergence.

Cheers,
Giovanna
________________________________________
From: icnrg <[email-masked]> on behalf of Thomas C. Schmidt <[email-masked]>
Sent: Sunday, March 18, 2018 3:53 PM
To: [email-masked]
Subject: Re: [icnrg] MAP-Me and pointer to old mobile multicast time

Luca,

Cheers,
  Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 18 Mar 2018 15:02:03 +0000

Hi Jordan,

> we have very different approaches in that you compute a new optimal tree,

Computing trees we do only in the convergence phase. This phase is very 
important, but missing in Map-Me.

MAP-ME does the same as the "Tree Elongation Phase" - it just adds the 
"mobility step" to the distribution system.

> show that the way we do it keeps stretch bounded and very low.

But you need to adopt (otherwise your topology blows up from state 
accumulation and wild detours). Its mandatory home-work!

As said earlier: You push this home-work into regular routing, which I 
don't believe routing can accomplish. Routing is usually slow.

Cheers,
  Thomas

--

---

From: Jordan Augé <[email-masked]>
Date: Sun, 18 Mar 2018 15:07:06 +0000

Hi,

> accumulation and wild detours). Its mandatory home-work!

That's exactly the point of the paper: show that stretch does not build up but 
is bounded. So no detour, no state explosion.

The state is just an additional sequence number in the FIB entry, which is 
negligible wrt to the size of a name. And the TFIB part, it just stores 
temporary information until the neighbour acks the update. So it is empty most 
of the time.

> don't believe routing can accomplish. Routing is usually slow.

I don't see why you persist in taking about routing as we act independently of 
routing. Our only interaction is to play well with routing so as it does not 
overwrite a more up to date entry in the FIB. In no way we rely on routing.

We only require the FIBs to be intially populated, then we could get the 
routing completely off and the scheme would work.

Jordan

> >>>>>          This idea reminds me very much to a proposal we published
> >>>>>          more
> >>>>>          than
> >>>>>       
> >>>>>       to the intersection of the old and new tree, which heavily
> >>>>>       depends
> >>>>>       on
> >>>>>       the underlying topology.
> >>>>>       
> >>>>>       
> >>>>>       Cheers
> >>>>>       
> >>>>>          matthias
> >>>>>       
> >>>>>       --
> >>>>>       Matthias Waehlisch

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 18 Mar 2018 15:11:46 +0000

Hi Jordan,

> is bounded. So no detour, no state explosion.

But this cannot be: either you converge routing, means re-compute 
desired paths (e.g., SPTs), or you need to maintain 'provisional' state 
which you do in your additional FIBs.

If you don't see stretch and table explosion, then you have examined the 
wrong scenarios ... just re-consider what the IP mobility people have 
done. This actually was a pretty good job (and IPv6 mobility is much 
more efficient and elegant than you claimed).

Cheers,
  thomas

--

---

From: Luca Muscariello <[email-masked]>
Date: Sun, 18 Mar 2018 16:15:23 +0100

Routing is usually slow, is more an opinion than a precise number.
There are opinions in the opposite sense BTW.

At Cisco we have been told several times that today routing updates can be
very fast.

Is routing fast or slow?

There are people that want to do mobility management using LISP or similar
things like ILA
which are isomorphically using a mapping system.

Is LISP fast or slow?

The point here is, not matter if routing is fast or slow, Map-Me provides
the path repair technology between routing updates.
Map-Me provides that with bounded path stretch so that it provides delay
guarantees to applications and minimises packet losses.

Map-Me is routing plane agnostic by design, but the assumption is that
routing is based on today Internet routing and not
20 years ago routing.

On Sun, Mar 18, 2018 at 4:02 PM, Thomas C. Schmidt <[email-masked]

>>>>>>             extend the previous distribution tree and replace
>>>>>> existing FIB
>>>>>>       states,
>>>>>>                This idea reminds me very much to a proposal we
>>>>>> published more
>>>>>>          than
>>>>>>       http://ilab-pub.imp.fu-berlin.de/papers/sw-mdtem-06.pdf. Are
>>>>>> you
>>>>>>       aware
>>>>>>       of this work?

---

From: Matthias Waehlisch <[email-masked]>
Date: Sun, 18 Mar 2018 15:18:00 +0000

On Sun, 18 Mar 2018, Jordan Augé wrote:

> That's exactly the point of the paper: show that stretch does not 
> build up but is bounded. So no detour, no state explosion.
> 
  it's bound based on your topology. And complexity in terms of topology 
is obviously much lower in intra-domain scenarios compared to the global 
Internet. ... this discussion of connecting new branches (or 
transforming existing branches) is not new.

  Anyhow, limiting intra-domain knowledge, did you think about other 
approaches? For example, placing virtual anchors based on consumer 
demands (e.g., similar to BIDIR-PIM)?

Cheers
  matthias

---

From: Luca Muscariello <[email-masked]>
Date: Sun, 18 Mar 2018 16:20:27 +0100

This is a discussion about the current draft or about how many other
approaches there can be in out in the wild?
Map-Me does not bring you coffee and cookies, it is one precise mechanism
to achieve a specific goal.

If you try to apply that to something it is not designed for, I would
discourage that.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 18 Mar 2018 15:20:38 +0000

Hi Luca,

> There are opinions in the opposite sense BTW.

There are very many very precise analyses and measurements which I 
cannot retell right now.

The complexity and speed of routing depends largely on the topology.

With Map-Me, we only consider intra-domain scenarios which are on the 
easy side. Normally, the intra-domain works well with an anchor (PMIPv6: 
LMA, PIM-SM: Rendezvous Point) and routing is not the biggest challenge ...

Cheers,
  thomas

> At Cisco we have been told several times that today routing updates can 
> be very fast.
> 
> Is routing fast or slow?
> 
> There are people that want to do mobility management using LISP or 
> similar things like ILA
> The point here is, not matter if routing is fast or slow, Map-Me 
> provides the path repair technology between routing updates.
> On Sun, Mar 18, 2018 at 4:02 PM, Thomas C. Schmidt 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Jordan,
> 
>     Computing trees we do only in the convergence phase. This phase is
>     very important, but missing in Map-Me.
> 
>     MAP-ME does the same as the "Tree Elongation Phase" - it just adds
>     the "mobility step" to the distribution system.
> 
>     As said earlier: You push this home-work into regular routing, which
>     I don't believe routing can accomplish. Routing is usually slow.
> 
>     Cheers,
>       Thomas
> 
> 
> 
>                         <[email-masked]
>                         <mailto:[email-masked]>
>                         <mailto:[email-masked]
>                         <mailto:[email-masked]>>> wrote:
>                                Hi Jordan et al.,
>                                      extend the previous distribution
>                         tree and replace existing FIB
>                                states,
>                                by sending Interest Updates to the
>                         previous location of the
>                                producer.
>                                Right?
>                                         This idea reminds me very much
>                         to a proposal we published more
>                                   than
>                                      ten yeas ago: "Morphing
>                         <http://ilab-pub.imp.fu-berlin.de/papers/sw-mdtem-06.pdf>.
>                         Are you
>                                aware
>                                of this work?
>                                to the intersection of the old and new
>                         tree, which heavily depends
>                                on
>                                the underlying topology.
>                                            Cheers
>                                         matthias
>                                      --
>                                Matthias Waehlisch
>                         <mailto:[email-masked] <mailto:[email-masked]>>
>     ° http://inet.haw-hamburg.de/members/schmidt
>     <http://inet.haw-hamburg.de/members/schmidt>      Fon:
>     +49-40-42875-8452 <tel:%2B49-40-42875-8452> °
> 

--

---

From: Matthias Waehlisch <[email-masked]>
Date: Sun, 18 Mar 2018 15:35:17 +0000

On Sun, 18 Mar 2018, Luca Muscariello wrote:

> approaches there can be in out in the wild?Map-Me does not bring you 
> coffee and cookies, it is one precise mechanism to achieve a specific 
> goal.
> 
  haha ... it's a discussion about the current draft! And still, I don't 
see much difference of your precise mechanism compared to previous 
concepts.

  It was a side comment: when you consider intra-domain scenarios, you 
probably may come up with more interesting solutions. But indeed, that's 
a different discussion.

  Btw, coffee and cookies can always be improved ;), based on my 
experiences.

Cheers
  matthias

---

From: Paulo Mendes <[email-masked]>
Date: Sun, 18 Mar 2018 17:13:56 +0000

For some time I expect a large discussion and ICN taking us back 10 years :). In what concerns the problem of the moment of sources in multicast trees, I can also point to some work that I did in 2007, with a Patent submitted in 2008 (owner: NTT Docomo) and a paper published in 2009.

Here is a link to the paper: https://drive.google.com/file/d/0ByVQEMg0Iu-ObnFwM1d2SzFiVlU/view

Our solutions, called SEMSE, aimed to support the seamless seamless movement of a PIM-SSM source by a kind go hybrid PIM-SM approach :), by buffering mechanisms responsible to assist the transmitting mobile nodes on changing the attachment point between different access routers (also within the same access network), without or with reduced packet losses. This is achieved through the combination of a buffer in the mobile node referred as Holder, and buffers in the access network called Virtual Multicast Roots (VMR). Since at the time we didn’t have ICN, the VMR emulated a in-network cache… 

The way to avoid recomputing SSM trees, was to root the tree at the VMR and having the sources sending data to the VMR based on TCP tunnels. So, when the source moves the major tree does not change.

I would like to discuss more about the full ICN approach to source mobility.

Melhores Cumprimentos / Best Regards / Mit freundlichen Grüßen
------------------------------------------------
Paulo Mendes, Ph.D
Coordinator SITI group @ COPELABS (http://siti.ulusofona.pt)
Director of NEMPS PhD program (http://nemps.ulusofona.pt <http://nemps.ulusofona.pt/>)
Associated Professor at University Lusofona, Portugal

http://www.paulomilheiromendes.com <http://www.paulomilheiromendes.com/>
Tel: +351 217 50 50 22

> On 18 Mar 2018, at 14:59, Giovanna Carofiglio (gcarofig) <[email-masked]> wrote:
> 
> Thomas, 
> 
>>    more than
>>    depends on