RE: [RAM] The mapping problem: rendezvous points?

Tony Li writes:
> > I agree there are hybrid cases possible, but what I was saying is
> > not a
> > hybrid at all.
> >
> > In hybrid schemes it comes down to whether there is any case of
"slow"
> > or not.
> >
> > For example, in one class of hybrid schemes:
> >
> > PUSH is used to get log(N) information such that any packet can be
> > immedidately forwarded upon arrival, and PULL is used in parallel to
> > forwarding to obtain a more optimal destination for future traffic.
> > This one is not problematic.
> 
> 
> Since the first packet is forwarded with suboptimal information,
> there will be a certain amount of additional stretch.  In addition,
> when the optimal information arrives, the change in path can
> potentially cause packet reordering, which is definitely problematic
> for a variety of applications, as well as triggering slow start.

Absolutely agree.  Of course reordering is less problematic than loss.

> > PUSH is used to get some information, but there remain cases where
> > a packet can arrive and PULL must be used before the packet can be
> > forwarded (i.e. encapsulated) somewhere.  This one is problematic
> > for the same reason as PULL.
> >
> > So as long as a hybrid is PUSH (not everything) with PULL _as an
> > optimization_, I claim it's better than where PULL is _a necessity_
> > and
> > PUSH is just an optimization.
> 
> I think that your claim is equivalent to saying that you prefer
> initial sub-optimality to initial latency.  I'm not yet convinced by
> this.  If the mapping client is in fact the host, it would seem that
> we could mask any initial latency.

The host is not incented to change to deal with routing scalability.
That's why I like the LISP approach, as the changes are done in places
(and by people) who actually experience the pain.

-Dave

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram