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

[Robin Whittle <rw@firstpr.com.au>]

Hi Brian and Noel,

I understand you agree with my critique of ALT - that it would delay
initial traffic packets, due to it being a global query server
system and moreso due to its requirement for strong address
aggregation.  Both of you seem to regard this as unimportant, or at
least as being non-fatal:

BC > From an engineering viewpoint, #3 [Send them a long way round.]
BC > seems reasonable (i.e. this minor delay will be added to the
BC > other delays for starting an application-level session).

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

I think it is really important.  Even a half-second delay in session
establishment is an enormous burden on all users, since the new kind
of mapped address space will, ideally, be used at one or both ends
of most Internet communications.

Even a half-second delay would make this new kind of address space
suck so much that it would be much harder to convince people to use it.


Christian Vogt wrote about the slowdown in TCP due to delay or loss
of initial packets:

  http://psg.com/lists/rrg/2008/msg00162.html

I wrote in more detail about this:

  http://psg.com/lists/rrg/2007/msg00462.html


My critique of ALT's insistence on strong address aggregation
indicates that it will be common for initial packets to be delayed
much more than half a second.  Beyond a second or so, I think it is
fair to say the packet is useless - that the higher layers will have
given up and will be try to start another session, perhaps with
another destination host where the same trouble might reoccur.

The delayed packet may be worse than useless, since it is travelling
round the ALT network (and so encumbering the Internet), using
resources in ALT routers, eventually emerging at the ETR, using
resources there and then being sent to the destination host, which
will probably send a response back (more mapping lookups and delays,
if the original sender used an EID address too).  The response
packet will be worse than useless too, since by the time it arrives,
the upper layers will be trying to establish another session.


I doubt that there could be consensus in the RRG that such delays in
initial packet delivery and session establishment would be
acceptable unless there was also consensus that all other schemes
which do not delay packets (NERD, APT and Ivip) were completely
unworkable.

Even if ALT could be tweaked to improve its meshiness so as to
generally reduce the path length (but meshiness is unlikely to help
in every ITR-ETR case), it is still a global query server network -
meaning it is slow and unreliable.  I think it would probably be
more expensive and harder to manage than the push systems it is
intended to avoid the need for.

  - Robin

--
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