Subject: Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of Mappings

From: [email-masked] (Noel Chiappa)
Date: Fri, 1 Mar 2013 17:19:28 -0500 (EST)

> From: Ronald Bonica <[email-masked]>

    > Would you agree with the following statements:
    > ...
    > So, at best, we have an architectural trade off.

I want to go away and think about this, but...

My initial reaction is that you're only considering _pieces_ of the overall
system, and saying 'this part is better in this approach, and worse in that
approach', so that's one side of a tradeoff; and in some other approach, the
inverse is true. But there are more places than just those two where one way
is better or worse than the other, so looking at just those two doesn't give
you the true, complete tradeoff.

Which is why I think that if you want to talk about complexity, I think you
have to think about the _overall_ complexity, not just the complexity of one
part, which can give an incomplete view.

Maybe the problem is that the term 'tradeoff' is being used too loosely?

When I talked about the 'tradeoff' between push and pull being between delay
and overhead, what I had in mind was that one fundamentally could not reduce
one partiular aspect of _performance_ without increasing another, and vice
versa.

You're getting into a greyer area, where 'complexity' gets dragged in as one
side of the tradeoff, which is more complicated because we're now no longer
purely in the 'performance' domain - and comparing performance versus
complexity is a very complex value judgement.

Yes, you may be able to directly couple one particular piece of the overall
_complexity_ to one particular _performance_ aspect, but I'm not sure what
good that does you, because there are other performance aspects, and many
other complexity aspects, and why are we singling out one particular
complexity/performance tradeoff to look at, when there is a whole long list of
them?

At least with the delay/overhead tradefoff, we're talking about a tradeoff
that is performance on both sides - which is something people probably care
more about.

But let me go away and ponder...

	Noel

---

From: Sharon Barkai <[email-masked]>
Date: Fri, 1 Mar 2013 23:32:54 +0000

2cents .. in most compute task pull is by far the preferred method for distributing information.
specifically in networking pull has 2 issues:
1. latency - this can be mitigated by pull per flow rather then per packet, its app aware caching
2. bootstrap - you have to be able to reach the element you pull from, this ability has to be pushed, this bootstrap is addressed by the overlay ..

On Mar 1, 2013, at 14:19, "Noel Chiappa" <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 1 Mar 2013 16:01:35 -0800

> 2. bootstrap - you have to be able to reach the element you pull from, this ability has to be pushed, this bootstrap is addressed by the overlay ..

Or configured, or hard-coded in name form as an anycast name or address.

Dino