Re: [RRG] ALT's strong aggregation often leads to *very* long paths

[ksriram@nist.gov]

Noel:

Many thanks to you and Robin for detailed comments/responses to my question
(motivated by Robin's original email on this topic).
I have updated the diagram to replace "ITR2" through "ITR8" with
"ALT-rtr2" through "ALT-rtr8" (new PNG link below):
http://www.antd.nist.gov/~ksriram/strong_aggregation.png

With this, let me restate my question/suggestion slightly differently.

Quoting Noel Chiappa <jnc@mercury.lcs.mit.edu>:
> The aggregation hierarchy is only there for the *resolution* phase (like
> DNS); there is no hierarchy associated with the handling of user data
> packets.

Yes, but as you have also acknowledged in your more recent email -- 
query/response messages and first-few (or perhaps first-several) "data
packets will be sent (inefficiently) along the server hierarchy".  

> In both ALT (I think - perhaps I'm confused about this detail of ALT, if so
> someone please enlighten me) and LISP+CONS, only the first/first-few data
> packets (i.e. until the EID->RLOC mapping gets propogated back to the ITR)
> will be sent (inefficiently) along the server hierarchy; after that, they
> go direct. Is this slight temporary inefficiency really that important?

So my question is: Can we not make an enhancement to the way the
query/response messages and first data packets are handled in ALT routers to 
take advantage of any available shorter paths (bypassing the hierarchy as and
when feasible)? In the example in the diagram, the topological (pink) link 
from ALT-rtr4 to ALT-rtr8 can be exploited to obtain a much shorter path 
and reduce the delays substantially. Robin had some interesting thoughts 
about how this was doable in principle but will add some complexity.
http://psg.com/lists/rrg/2008/msg00237.html
I would like to hear your thoughts on this and from others who may be 
interested in these details of LISP-ALT.

Modeling needs to be done to quantify the delays due to potentially
very long paths along the ALT-rtr hierarchy and their performance impacts.
Meanwhile, I think it is worth exploring some enhancements that can 
potentially improve performance under these circumstances.
 
Sriram
http://www.antd.nist.gov/~ksriram/

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg