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 protected]> wrote: >> From: Ronald Bonica <[email protected]> > >> 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 > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
